RICE scoring, without the false precision.
RICE turns four estimates into one number. That number is only as honest as the estimates behind it — and only useful if you know what it hides.
The formula
RICE ranks a backlog by dividing the value of an item by what it costs to build:
RICE = (Reach × Impact × Confidence) ÷ Effort
The framework comes from Intercom, which needed a way to compare features that different teams each believed were urgent. Its contribution isn't mathematical sophistication — it's forcing four separate judgements into the open, where they can be argued with individually.
What each input means
- Reach — how many people this affects in a set period. The most objective input, because you can usually go and measure it.
- Impact — how much it matters to each person it reaches. Classic RICE uses a fixed ladder (3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal) specifically to stop the endless argument between 7 and 8.
- Confidence — how much you trust the three numbers you just wrote down. This is the input that makes RICE honest, and the one people most often fake.
- Effort — total cost across everyone involved, not just engineering. It's the denominator, so underestimating it inflates the score faster than overstating any other input.
A worked example
Four candidates, scored on Tarazu's 1–100 scale. The arithmetic is shown so you can check it:
| Candidate | Reach | Impact | Confidence | Effort | Arithmetic | Score |
|---|---|---|---|---|---|---|
| Self-serve onboarding | 80 | 90 | 80 | 30 | 576,000 ÷ 30 | 19,200 |
| Usage-based billing | 60 | 85 | 70 | 65 | 357,000 ÷ 65 | 5,492 |
| SSO & SCIM | 35 | 70 | 90 | 50 | 220,500 ÷ 50 | 4,410 |
| Mobile companion app | 70 | 65 | 50 | 90 | 227,500 ÷ 90 | 2,528 |
The ranking falls out of the arithmetic: Self-serve onboarding wins at 19,200 because it reaches a lot of people, matters to them, and is cheap. Mobile companion app comes last at 2,528 — not because it's a bad idea, but because a low confidence estimate and the highest effort compound against it.
Notice the absolute values are large and meaningless on their own. A RICE score of 19,200 doesn't denote anything in the world. It's ordinal: the only question it answers is which item outranks which.
Normalized RICE: why Tarazu scores every input 1–100
Classic RICE mixes units. Reach is a count of people, impact is a multiplier from a fixed ladder, confidence is a percentage, and effort is person-months. Multiply and divide across four different units and the result is arithmetically valid but dimensionally meaningless — which is why two teams using “the same” framework routinely produce scores that cannot be compared.
score = round((reach × impact × confidence) ÷ max(effort, 1))
All four inputs sit on the same 1–100 scale. The max(effort, 1) guard exists so an effort of zero cannot divide by zero and produce an infinite score.
Normalizing buys comparability: scores mean the same thing across teams and across quarters, and a whole class of unit-mismatch bug disappears.
What it costs you is the literal reading. In classic RICE you can say “this reaches 4,000 users a quarter.” On a 1–100 scale you're saying “this reaches far more people than that one, about four-fifths of the most reach anything here has.” That's a real loss, and worth knowing you've accepted. If your team genuinely has trustworthy reach data in absolute units, classic RICE preserves information that normalization discards.
Where RICE breaks
Every framework has a domain where it stops helping. RICE has four, and knowing them is the difference between using the score and being used by it.
Confidence is the input people fake
Multiplying by a made-up 0.8 doesn't represent uncertainty — it launders a guess into something that looks quantified. If nobody can say what evidence moved confidence from 50 to 80, the number is decoration. The honest move when confidence is genuinely low is to stop scoring and go get evidence, not to score anyway with a discount applied.
Reach you cannot measure isn't reach
Reach is the one input you can usually verify, which makes it the one most worth verifying. A reach estimate produced in the same meeting as the score, by the same person advocating for the item, isn't an input — it's the conclusion wearing a number.
RICE ranks; it doesn't sequence
The formula has no concept of dependency, and a ranked list reads as an order of work even though it's not one. If the third item is a prerequisite for the first, RICE won't tell you — it will confidently hand you an ordering that cannot be executed.
The tie-break is where judgement actually lives
Real backlogs produce near-identical scores constantly, and the gap between two items is usually smaller than the error bars on the estimates that produced them. Treating a 12% difference as decisive is false precision. When scores are close, the framework has told you what it knows: these are comparable, and now someone has to choose.
RICE vs ICE vs weighted scoring
RICE isn't the only option and often not the right one. The useful question is what each framework chooses to ignore:
| Framework | Formula | What it's for | What it ignores |
|---|---|---|---|
| RICE | (Reach × Impact × Confidence) ÷ Effort | Comparing features that serve different audiences at different costs. | Dependencies, strategic fit, and anything that matters intensely to a small group. |
| ICE | Impact × Confidence × Ease | Fast triage when you need an order this afternoon. | Reach entirely — so it systematically overrates work that delights a handful of people. |
| Weighted scoring | Σ (criterion × weight) | When your real criteria aren't RICE's — strategic fit, compliance, revenue risk. | Nothing by design, which is the risk: the weights encode the answer you wanted. |
| WSJF | Cost of delay ÷ job size | Sequencing when timing dominates — deadlines, market windows. | Reach and confidence, and it needs a cost-of-delay estimate most teams can't produce. |
A reasonable default: ICE when you need speed and everything serves roughly the same audience, RICE when audience size genuinely varies between items, and weighted scoring when your organisation has real criteria RICE cannot express. Switching frameworks mid-quarter to get a different answer isn't prioritization; it's looking for permission.
Turning a RICE score into a decision
The score is an input to a decision, not the decision. Two things turn one into the other.
Look at the tradeoff, not just the rank
Plotting effort against impact separates items a single number collapses together. In Tarazu the quadrants are:
| Quadrant | Effort | Impact | What to do |
|---|---|---|---|
| QUICK WIN | ≤ 50 | > 50 | Do these first — cheap and consequential. |
| STRATEGIC | > 50 | > 50 | Worth it, but plan for the cost. |
| FILL-IN | ≤ 50 | ≤ 50 | Cheap but minor. Fill gaps; don't build a roadmap on them. |
| THANKLESS | > 50 | ≤ 50 | Expensive and minor. Say no, and record why. |
Rank and quadrant disagree more often than you would expect. In the example above, SSO & SCIM sits in the QUICK WIN quadrant — cheap to build and the most confident estimate on the board — yet ranks only third of 4, because its narrow reach drags the score down. That disagreement is information, not an error: it's exactly what a ranked list on its own will hide from you.
Write down why
The score explains the ordering. It doesn't explain the choice — the override you made, the dependency you sequenced around, the bet you took on low confidence anyway. Recording that's what makes a decision reviewable in six months, and it's precisely what a spreadsheet throws away. The numbers survive; the argument that produced them doesn't, which is why the same debate reopens every quarter.
That loop — score, decide, record, learn — is what Tarazu is built around.
Score your backlog, defensibly.
Free, and no account needed — guest mode runs entirely in your browser.