Priority: RICE/WSJF/ICE

RICE, ICE, and WSJF do not provide an objective answer; they make assumptions visible and help to compare initiatives using the same logic. First, define the type of decisions and the unit of evaluation, then discuss the discrepancies in Reach, Impact, Confidence and Cost of Delay, rather than arguing about the final score.

Why Prioritize Tasks in Delivery

Why can’t you just pull it all away?

When multiple teams are working on a product, there are always more wants than resources. If you do not choose what to do in the first place, there will be no deadlines and quality, the teams will start to stall.

How bad processes look like

A typical mistake is to take on a project, checking with personal opinions or the volume of the request. Bottom line: suffer really important features or cretes, unloading at night, delaying bugs and features for the sake of a “new beautiful screen”.

** Example:**
In ecommerce launched a block of new banners at the request of marketing, although a month later competitors came out with a quick delivery, which “put in the backlog”. In the end, they lost market share.

RICE: Evaluation of the effect through 4 parameters

What’s RICE?

RICE (Reach, Impact, Confidence, Effort) is a way to estimate the benefit of a task and select from a set of queries those that will give the maximum effect per unit of effort.
Formula:
RICE = (Reach × Impact × Confidence) ÷ Effort

• Reach: How many users will be affected.
• Impact: How much behavior or metric will change.
• Confidence: How confident are the estimates?
• Effort: How many resources will you spend?

How it works in practice

You take tasks from the backlog, evaluate them by 4 parameters, for example, new integration or reworking UX. Comparing scores: If a task can produce a noticeable metric gain with minimal risk and effort, it is more likely to land in Delivery in the next iteration.

** Example:**
In SaaS noticed the drawdown of onboarding, formulated hypotheses, estimated: Reach 2000 users/month Impact 0.3 (moderate)
Confidence 80%
Effort 5 days RICE: (2000×0.3×0.8)/5 = 96
For comparison, another task scored 40 — first take the one above.

Anti-pattern:
Overestimating Impact due to internal enthusiasm or underestimating Effort from optimism – the points become unshowable, Delivery stalls.

Source: Intercom about RICE

ICE: Easy, fast, but in Delivery, be careful.

What’s ICE?

ICE (Impact, Confidence, Ease) is a similar but simplified approach.
ICE = Impact × Confidence × Ease
Ease is the conventional equivalent of “lightness”, usually reminiscent of Effort, but mirror (more is easier).

In which cases can ICE drive?

ICE is suitable if there is nothing to waste time on deep analytics. But often there is an illusion of simplicity: the trap is that the inner feelings about Impact and Ease may not be accurate.

** Example:**
The team chooses from 10 ICE bugs to fix the top 3 before release. No data – rely on expertise and common sense. After the release, it turns out that some minor bugs strongly influenced the NPS - it was difficult to estimate in advance without data.

**ICE is suitable for prioritizing small increments and bugfixes in Delivery, where speed is more important than accuracy.

Source: GrowthHackers about ICE

WSJF: Make expensive quickly and profitably

How does WSJF work?

WSJF (Weighted Shortest Job First) is a basic technique from Lean and Scaled Agile (SAFe) for large teams and portfolios.
Formula:
WSJF = Cost of Delay / Duration Thus, tasks that have a delay will bring a lot of losses are given priority.

• Cost of Delay: How much will a company lose if it doesn’t do the job now?
• Job Duration: How long does it take?

Where WSJF is used in Delivery

When it’s important to quickly launch features that directly affect money, revenue, or SLA, WSJF helps you avoid falling through critical blocks.

** Example:**
The fintech team weighed bugfixes and new integrations. The transfer of users to a new platform brought drawdowns in NPS and money - calculated the Cost of Delay on lost revenue, assessed duration, the first to send integration for revision, then got to less urgent cravings.

Source: ProductPlan about WSJF

Advice and Mistakes: What to Remember

How not to turn prioritization into a pointless “point game”

• Do not evaluate tasks in a vacuum: agree to be evaluated by multiple roles (product, analyst, dev lead).
• Determine what Impact means for your product (e.g. retention vs revenue).
• Keep business goals and product metrics in the baseline so that ICE/RICE/WSJF is considered not for points, but for results.
• Once in a sprint review important tasks: when new introductory priorities quickly become obsolete.

Common Mistakes and What to Do Instead

• Ignore Cost of Delay – Small bugs can bite off reputation if you drag too long.
• Count Effort/Ease without a real team score (better discuss together).
• Confidence: Taking a task with a score of 0.3 is almost blind. Get the data first.

** Example:**
The team does not ask the developers about Effort - the drags seem easier, the burndown breaks down.

FAQ to prioritize Delivery tasks

**1. How to choose between RICE, ICE and WSJF? For urgent bugs and features, ICE is often used, for business metrics, RICE, and WSJF for multitasking and urgency.

**2. Do you need to evaluate all the tasks in detail? No, make a detailed assessment only for key tasks. Calculate the small ones by ICE or sort them straight into triage.

**3. What happens if the scores differ in the team? Discuss the reasons for the discrepancies. Check the basic logic and the data, better re-evaluate together.

**4. When do you rethink your priorities? Before each sprint or release, as well as when a critical external factor appears (for example, the exit of a new competitor).

**5. How to measure Impact and Effort objectively? Impact - through product metrics: retention, revenue, NPS. Effort – According to the team’s expert assessment, best in story points or man-days.

**6. Where to get good benchmarks for your calculations? **
Look at the analogs in your segment, read the reports (e.g.) and compare them with your team’s historical data.