“RICE Scoring: Formula, Example and Template”

What is the RICE scoring formula?

RICE scoring calculates a priority score by multiplying three value factors and dividing by the effort required: (Reach × Impact × Confidence) ÷ Effort. The result estimates weighted impact per person-month, so bigger numbers mean more value per unit of constrained capacity.

The four factors:

The units are odd on purpose. Reach × Impact × Confidence produces something like “weighted people per quarter,” and dividing by person-months gives “weighted impact per person-month.” Nobody says that out loud in a meeting. What matters is that every row uses the same definitions so the numbers can be compared to each other.

The model was developed at Intercom and published by Sean McBride, and it remains one of the few frameworks simple enough that a team keeps using it after the first quarter. For the facilitation and debate side of the method, see our guide to RICE scoring for feature prioritization; this article covers how to build and defend the sheet.

How do you build the RICE sheet?

Build eleven columns, lock the inputs that should not be free text, and let formulas do the arithmetic. A sheet that people can type arbitrary numbers into will produce arbitrary numbers.

The formulas, assuming the capacity figure sits in cell B1 and rows start at 2:

• Score: `=ROUND((C2*D2*E2)/F2,0)`
• Rank: `=RANK(G2,$G$2:$G$10)`
• Cumulative effort: `=SUM($F$2:F2)`
• Decision flag: `=IF(I2<=$B$1,"Fund","Backlog")`

Two details keep the sheet usable. Apply data validation to columns D and E so Impact only accepts 0.25, 0.5, 1, 2, or 3, and Confidence only accepts 0.3, 0.5, 0.8, or 1. Then put an evidence link in column K for every reach figure. When someone challenges a rank in week nine, the argument goes to a dashboard instead of a memory.

> Important note: fix the period before you score anything. If one row measures reach per month and another per quarter, the ranking is meaningless even though the arithmetic is correct.

What does a good scoring rubric look like?

A rubric is the difference between RICE and a number-shaped opinion. Write it once, agree it in the room, reuse it.

Reach: count affected people, not the user base

Reach is the number of distinct users or events that actually encounter the change in the period. Not total users, not addressable market, not “everyone benefits eventually.”

Three counting rules cover most cases:

1. Funnel features. If 500 customers hit a screen each month and 30% use the option, quarterly reach is 500 × 0.30 × 3 = 450.
2. Feature-wide changes. If every customer using a feature sees the change, reach is that feature’s quarterly active users.
3. One-time effects. A migration that touches 800 existing accounts once is 800 for that quarter, with no ongoing reach in later periods.

Exclude users who will not notice. A backend refactor that cuts page load by 200 milliseconds reaches everyone technically, but the honest figure is the sessions where that latency changes behaviour.

Impact: use anchors, not adjectives

Impact is a per-person multiplier. The standard scale is 3 for massive, 2 for high, 1 for medium, 0.5 for low, and 0.25 for minimal. Define what those words mean in your product so two raters land in the same place.

The most common failure is a team where every item scores 2. If more than a third of your rows carry the same impact value, the scale is not doing any work.

Confidence: tie the number to evidence

Confidence is where RICE absorbs uncertainty. Intercom’s original scale is 100% high, 80% medium, 50% low; a practical extension adds a tier for genuine bets:

One rule keeps this honest: confidence is set by the weakest input, not the average. Reach from a dashboard plus a guessed effort is not a 0.9.

Effort: count every function, not just engineering

Effort is total person-months across product, design, engineering, QA, documentation, and rollout support. One person-month is about 15-18 productive days once meetings and support are removed.

Round hard: whole numbers, and 0.5 for anything under a month. An estimate of 2.3 person-months signals rigour the data does not support and invites arguments about the decimal instead of the decision.

Include the hidden work: migration scripts, customer comms, support training, and the two weeks after launch answering tickets. Engineering at 2 person-months plus 0.5 design plus 0.5 support is a 3; pretending otherwise inflates the score by 50%.

Worked example: a nine-item portfolio

A full quarter of candidate work for a mid-market SaaS product team, scored with the rubric above. Capacity is 14 person-months.

Example 1: the arithmetic for one row

Take F-103, bulk CSV import. Reach is 1,800 users per quarter, from accounts that currently import manually. Impact is 1: it improves an existing workflow without changing behaviour. Confidence is 0.8 because reach comes from product data but the effort estimate is new. Effort is 2 person-months.

(1,800 × 1 × 0.8) ÷ 2 = 720

That is 720 units of weighted impact per person-month. F-102, the onboarding checklist, scores 1,920 with less than half the reach, because impact is 2 and effort is 1. It is the better use of a person-month even though fewer people touch it.

Example 2: applying the capacity cut line

Add cumulative effort in rank order and stop when the budget runs out.

The strict cut line funds six items and leaves 2.5 person-months stranded, because F-107 needs 4. This is where a spreadsheet stops being a decision.

You have three options, and each has a cost:

• Leave it idle. Safe, and sometimes correct: over-committed teams generate their own waste.
• Swap. Drop F-106 (420, 1.5 months), add F-107 (384, 4 months). You lose 36 points and use all 14 months. Justified if SSO unlocks enterprise deals, which the score cannot see.
• Split. Ship SSO without SCIM at about 2 person-months: (640 × 3 × 0.8) ÷ 2 = 768, which ranks third. Legitimate only if the slice delivers value alone; if SSO without provisioning is unusable, it is score inflation with extra steps.

Example 3: sensitivity, where ranks go to die

F-105, mobile offline mode, sits at rank 5 with an effort estimate of 6 months. If a technical spike revises that to 4, the score becomes (3,100 × 2 × 0.5) ÷ 4 = 775, moving it to rank 3 above bulk CSV import at 720.

Now test the top. F-101 leads at 2,400 because its effort is 0.5. If that turns out to be a month, the score drops to 1,200 and it falls behind the checklist. The quarter’s first priority was resting on a half-month estimate.

That is not a reason to abandon the method, but a reason to check which ranks are load-bearing. Rerun the sheet with every effort estimate up 50% and every reach figure down 20%, then compare the top five. Items that hold are robust; items that move five places are arguments, not conclusions.

Where does RICE scoring break down?

RICE has four specific blind spots. Knowing them separates a useful quarterly exercise from a spreadsheet that quietly overrides judgement.

Dependencies are invisible. If F-107 depends on an identity migration landing two quarters later, no score captures it. Keep a dependency map beside the sheet and let it override rank order explicitly.

Compliance scores badly. Certifications, accessibility fixes, and contractual obligations often have small reach and high effort, so they rank low. That is not permission to skip them: split the sheet into discretionary and obligatory work, score the first, reserve capacity for the second.

Reach inflates without anyone lying. Counting users who *could* see a change rather than those who will is the commonest manipulation, usually unintentional. A dashboard query in column K removes most of it.

Small work is systematically favoured. Dividing by effort rewards cheap items, which is the intent, but it can crowd out the large bet that changes the trajectory. Many teams reserve 20-30% of capacity for a strategic bet that is scored but not cut.

> Common mistake: scoring forty items in one sitting. Quality collapses after about fifteen rows, and the last twenty get whatever number unblocks the meeting. Score the top fifteen, ship, and rescore next quarter.

RICE vs WSJF, ICE, and weighted scoring

Different frameworks answer different questions; the honest comparison is about fit.

RICE wins with real usage data and comparable features. WSJF wins when delay has a calculable cost, which is rare outside large programmes. ICE is a looser version of the same instinct: fine for a workshop, weaker for a quarterly commitment.

How do you keep the sheet honest over time?

A RICE sheet decays in predictable ways, and governance is the maintenance schedule.

• One owner, one version. A named product person maintains the sheet, and the file lives in one place. Copies in three inboxes are how two teams end up building the same thing.
• Log every override. When a lower-scored item is funded for a dependency or strategic reason, write the reason and the date. Overrides are legitimate; undocumented overrides destroy trust in the scores.
• Rescore, do not preserve. Last quarter’s scores rest on last quarter’s assumptions. Keep the old sheet for the audit trail, but rescore the backlog each cycle.
• Audit your accuracy, and cap the ceremony. Six months later, compare predicted reach against actuals for three shipped items; if reach was consistently double the outcome, apply a correction factor. And keep the session to ninety minutes for fifteen items. If scoring takes longer than the work it prioritises, the process has become the product.

How does Doitify fit into this?

A RICE sheet is only useful if the decision reaches the people doing the work. That is usually where prioritisation dies: the ranking lives in a spreadsheet, the work lives in a task board, and nobody can tell which backlog item corresponds to F-107.

Doitify is our platform, and it is built for that handoff. A scored item becomes a task or sub-task with an owner, a due date, and a checklist; capacity lives in the workload views; dependencies are modelled as WBS links, so the item that cannot start yet is visible. Sprints and backlogs hold the funded set, and work reports show planned versus actual once delivery starts. We are not claiming the tool decides your priorities, and a team that prefers a bare spreadsheet plus judgement will not be worse off. The reason to bring scoring and execution into one workspace is that a ranking nobody can trace to real work is just a nice table.

Conclusion

RICE scoring is one division sum, and its value comes almost entirely from what happens around it: the definitions you agree before scoring, the evidence link in every reach figure, the capacity cut line, and the sensitivity pass that tells you which ranks are real.

Build the eleven columns, lock the dropdowns, score fifteen items rather than forty, and fund to capacity. Then look at what got stranded and decide deliberately whether to swap, split, or leave the month idle, and run one sensitivity pass before you defend the list. Next quarter’s argument becomes a twenty-minute review of assumptions instead of a six-week negotiation about whose idea matters more.

If this post on RICE scoring was helpful, you might also enjoy Project Management Software for Architecture Firms in 2026 and Workload Management: How to Balance Team Capacity.