“RICE Scoring: How to Prioritize Features”

What does RICE stand for?

rice scoring is a key topic in modern project management and teamwork. RICE stands for Reach, Impact, Confidence, and Effort. Intercom’s product team developed the model, and Sean McBride published the canonical explanation on the Intercom blog; the current page carries a January 2018 update date, and the method has been in circulation since 2016.

The formula is:

RICE score = (Reach × Impact × Confidence) ÷ Effort

The units are deliberately odd. Reach × Impact × Confidence produces something like “weighted people per quarter”, and dividing by person-months gives “weighted impact per person-month”. The number is only meaningful relative to other items scored with the same definitions.

How do you calculate a RICE score step by step?

Six steps, in order. Skipping the definitions step is the most common reason a RICE exercise produces nonsense.

Step 1: Fix the time period. Use one quarter for every item. If one feature is measured monthly and another quarterly, the scores are not comparable.

Step 2: Count reach. Count people who will encounter the change, not the entire user base. If 500 customers hit a screen each month and 30% choose an option, the quarterly reach is 500 × 30% × 3 = 450.

Step 3: Assign impact. Use the multiplier scale, not invented numbers. Massive = 3, high = 2, medium = 1, low = 0.5, minimal = 0.25. Write one sentence explaining the rating; it will be challenged later.

Step 4: Set confidence. 100% means you have data for reach, research for impact, and an engineering estimate for effort. 80% means one of those is an assumption. 50% means most of it is a guess. Below 50% is a bet, not a plan.

Step 5: Estimate effort in person-months. Include product, design, engineering, QA, and rollout. One person-month is what one team member does in a month; round to whole numbers and use 0.5 for anything clearly under a month.

Step 6: Divide and record the rationale. The score without the reasoning is unusable three months later, when the team has forgotten why reach was 3,000.

Worked example: scoring one feature

A feature that improves the checkout flow:

• Reach: 3,000 customers per quarter
• Impact: 2 (high)
• Confidence: 80%
• Effort: 3 person-months

Score = (3,000 × 2 × 0.8) ÷ 3 = 4,800 ÷ 3 = 1,600

Read it as 1,600 units of weighted impact per person-month. Alone it says nothing; next to four other features, it tells you where it ranks.

Worked example: five features, one ranked list

A realistic quarterly backlog: the numbers are illustrative, but the arithmetic is what your spreadsheet will do.

The CSV fix wins by a wide margin. It affects a lot of people, it is cheap, and confidence is high. International pricing has the largest reach by far, but low impact per user, low confidence, and high effort push it to last.

That ranking is not a verdict; it is a list of candidates with reasons attached, and the reasons drive discussion.

Why does the RICE ranking sometimes feel wrong?

Because the formula has three known distortions, all of which appear in real backlogs.

Reach dominates. Reach is unbounded while impact, confidence, and effort sit on narrow scales. Doubling reach doubles the score; doubling impact requires moving from “medium” to “massive”. A feature touching 50,000 users with minimal impact can beat one that transforms the experience for 2,000.

Dividing by effort rewards small fixes. A 0.5 person-month fix gets a 2× boost over a 1 person-month fix. Over several quarters, a team optimising purely for RICE ships a long list of small improvements and never makes a structural change.

The inputs are correlated. If reach, impact, and confidence all come from the same optimistic estimate, the formula multiplies the optimism three times. That is not a model problem; it is an estimation problem, and it needs a separate control.

> Common mistake: Re-scoring an item until it ranks where the team already wanted it. If the score changes after the decision, you are not prioritising; you are documenting a decision that was made elsewhere.

How sensitive is a RICE score?

More sensitive than most teams expect: a 20% change in one input can move an item several places.

Take the checkout feature: reach 3,000, impact 2, confidence 0.8, effort 3. Score = 1,600.

Now assume the confidence was optimistic (0.5 instead of 0.8) and the effort estimate missed the QA and rollout work (5 instead of 3):

(3,000 × 2 × 0.5) ÷ 5 = 3,000 ÷ 5 = 600

The feature falls from second to fifth, behind the audit log at 1,200. Nothing changed about the feature; only the honesty of two inputs did.

A simple sensitivity rule

For every item in the top five, do three checks:

1. Cut confidence by 20 percentage points.
2. Raise effort by 50%.
3. Halve reach.

If the item stays in the top five after all three, it is robust. If it collapses, the ranking is resting on an assumption worth testing before you commit a quarter of engineering time.

Worked example: the scaling trap

A feature’s reach grows from one region (4,000 users) to all regions (40,000). Impact is 1, confidence 80%, effort 4.

Regional: (4,000 × 1 × 0.8) ÷ 4 = 800 Global: (40,000 × 1 × 0.8) ÷ 4 = 8,000

A tenfold reach increase produces a tenfold score increase, pushing the item above everything else. That may be correct, or it may be an artefact of an unvalidated estimate. When reach jumps by an order of magnitude, it needs evidence, not a multiplier.

How do you set confidence honestly?

Confidence is the only input that explicitly encodes uncertainty, so it deserves a definition that everyone applies the same way.

Two rules keep the scale honest. First, confidence cannot exceed the weakest input: if effort is a guess, the item is not 100% confident. Second, confidence should be set before the score is calculated, not adjusted afterwards.

RICE vs ICE vs WSJF vs MoSCoW

RICE is one of several prioritisation models. The right choice depends on the decision you are making.

WSJF, used in the Scaled Agile Framework, is the closest competitor. It sequences work by relative cost of delay divided by relative job duration, where cost of delay combines user-business value, time criticality, and risk reduction. It answers “what is most expensive to delay?” rather than “what returns most per unit of effort?”, so a team can reasonably use RICE for the backlog and WSJF for a release train.

ICE is faster but easier to game, because every input is a subjective 1–10. MoSCoW is better for agreeing what is out of scope than for ranking what is in it. Kano tells you which features create delight; it does not tell you what to build first.

When should you not use RICE?

RICE is a tool for ranking comparable, independent feature ideas. It is a poor fit for five common situations.

Hard dependencies. If feature B cannot ship before feature A, the ranking is irrelevant. Sequence A first even if B scores higher.

Compliance and security work. A regulatory fix may have low reach and no visible impact, but the cost of not doing it is existential. Score it separately or treat it as a fixed allocation.

Table stakes. SSO may score poorly on impact because every user expects it. Losing two enterprise deals is not captured by the formula.

Strategic bets. A new market entry has low confidence by definition. RICE will always rank it last. If the strategy requires the bet, fund it outside the scoring process.

Maintenance and reliability. Reducing incident frequency has diffuse reach and delayed impact. It is usually better handled with an error budget or a fixed capacity allocation than with a feature score.

> Practical tip: Reserve a percentage of capacity for each category before scoring: for example, 60% roadmap features, 20% reliability and compliance, 20% strategic bets. Then use RICE to rank within the 60%. The formula stays useful without being asked to answer questions it cannot.

How do you run a RICE session that ends in a decision?

A 60–90 minute session with the people who hold the estimates. Product, engineering, design, and one commercial representative is enough; more people adds noise.

Before the session: circulate the list, the definitions, and the time period. Ask each participant to score independently. Independent scoring prevents the loudest person from anchoring the room.

During the session:

1. Confirm the list and remove duplicates.
2. Review the definitions of reach, impact, confidence, and effort.
3. Compare scores and discuss only the items where estimates differ by more than 2×.
4. Record the rationale for every input, not just the final score.
5. Run the sensitivity check on the top five.
6. Apply the capacity cut line and the dependency overlay.

After the session: publish the ranked list with the reasoning, the cut line, and the items deliberately deferred. A scored-and-deferred item should not resurface next week as if it were new.

The most useful rule is to argue about inputs, not scores. “I think reach is 800, not 3,000, because the feature only appears after onboarding” is a productive challenge. “I don’t like this ranking” is not.

How do you connect scores to actual capacity?

A ranked list is not a plan until it meets a capacity constraint. The step most teams skip is the cumulative effort calculation.

Worked example: the quarterly cut line

Assume the team has 24 person-months of capacity this quarter, and the ranked list from earlier:

The cut line falls after “Mobile offline mode” at 21.5 person-months. Custom dashboards does not fit and moves to next quarter’s list, where it competes with new items.

This is where RICE earns its keep. Without a cut line, the team argues about whether custom dashboards matters more than offline mode. With one, the question becomes whether dashboards can be made smaller, or something traded out.

What are the most common RICE mistakes?

• Using total users as reach. Reach is affected users per period, not the size of the customer base.
• Rating every impact as 2 or 3. If everything is high, the multiplier stops discriminating.
• Inflating confidence to push a favourite. Confidence is the easiest input to manipulate and the most damaging when wrong.
• Counting only engineering effort. Design, QA, documentation, and rollout are part of the cost.
• Treating the score as precise. A score of 1,600 versus 1,550 is a tie, not a ranking.
• Never re-scoring. Reach and effort change as you learn; refresh the list quarterly rather than freezing it.

What should you do after the score?

Overlay dependencies. Draw the arrows between items. If a low-scoring item unlocks two high-scoring ones, its effective value is higher than its score suggests.

Check the portfolio. Count how much capacity goes to small fixes, structural work, and strategic bets. A list that is 90% small fixes means the model is shaping strategy rather than serving it.

Set a review date. Re-score each quarter, or when a major assumption changes, and keep the old scores to track estimate accuracy.

Doitify supports this loop without a separate spreadsheet. Backlog items can carry custom fields for reach, impact, confidence, and effort; sprints and roadmaps show what the cut line actually funded; and work reports show whether the effort estimates held. Doitify Copilot can draft the scoring rationale from a feature description, which shortens the note-taking teams usually skip. We make the product, so treat the recommendation as biased; the method works in any tool that stores four numbers and a reason.

Conclusion

RICE scoring turns a room full of opinions into a ranked list with visible assumptions. The formula is simple; the discipline is in the definitions. Fix the time period, count affected people rather than total users, set confidence before you calculate, and include all the effort.

Then do the two things the spreadsheet cannot do: overlay dependencies and apply a capacity cut line. A score without a cut line is a wish list. A score with a cut line is a plan.

If the ranking still feels wrong after a sensitivity check, that is useful information: a strategic constraint is probably missing from the model. Name the constraint rather than bending the numbers.

If this post on rice scoring was helpful, you might also enjoy Employee Onboarding Project Template and Project Management Software for Research Teams: 2026 Guide.