The RICE formula

Overview

The previous lesson made the problem clear: without a criterion tied to value, any backlog order is defensible only in appearance. This lesson gives you the criterion. RICE is an acronym for its four inputs —Reach, Impact, Confidence, Effort— and the formula that combines them into a single number, the riceScore, is:

riceScore = (Reach x Impact x Confidence) / Effort

It was created at Intercom, by Sean McBride, specifically to solve the problem of deciding what to build with too many good ideas and limited capacity. The central idea, before going deep into each input (that's lessons 4 and 5): the numerator —Reach x Impact x Confidence— measures how much expected value the bet produces, and the denominator —Effort— measures how much it costs to produce it. The final score is, literally, expected value per unit of cost: not "which bet is bigger", but "which bet gives you more for what you invest".

How this connects to the module. This lesson builds the full scale the introduction previewed, with its four pans named and its exact formula. Lesson 4 fully opens up the first two pans (Reach and Impact): where those numbers come from and in what units. Lesson 5 opens the other two (Confidence and Effort) and, with all four complete, ranks Mercado's full backlog for the first time. Today we stay with the formula itself: what each input is, in what order they multiply, and how it looks calculated step by step over two real bets.

An analogy: a four-pan scale

Picture a market scale, the kind with several pans where you add weights until you find balance. The RICE scale has four pans, and the first three multiply together before anything gets weighed —they form, together, a single weight—: how many people the bet reaches (Reach), how much it moves each one (Impact), and how sure you are of those first two weights (Confidence). That combined weight is the expected value. The fourth pan, Effort, doesn't multiply: it's used to divide the expected value, because it measures cost, and the same expected value weighs less —in relative terms— if it costs more to get. A bet with a lot of expected value but a very high cost can end up weighing less, on the final scale, than a more modest but cheap bet. That's exactly what you're about to see in today's example.

Worked example: riceScore step by step over two bets

Let's build the function and run it over the introduction's two bets —fasterCheckout and recommendations—, showing each step of the calculation separately, so you see exactly where each input comes in:

// riceScore({reach, impact, confidence, effort}) = reach * impact * confidence / effort
//   reach:      people/events reached in the period (a number, e.g. users/quarter)
//   impact:     fixed scale 3 | 2 | 1 | 0.5 | 0.25  (massive -> minimal), NOT a percentage
//   confidence: fraction 0-1 (100%=high, 80%=medium, 50%=low) of how much you trust reach/impact
//   effort:     person-months the bet consumes (the "cost")
function riceScore({ reach, impact, confidence, effort }) {
  return (reach * impact * confidence) / effort;
}

const fasterCheckout = { reach: 8000, impact: 2, confidence: 0.8, effort: 2 };
const recommendations = { reach: 5000, impact: 1, confidence: 0.5, effort: 3 };

console.log('=== riceScore, step by step ===\n');
for (const [name, bet] of [['fasterCheckout', fasterCheckout], ['recommendations', recommendations]]) {
  const numerator = bet.reach * bet.impact * bet.confidence;
  const score = riceScore(bet);
  console.log(name + ':');
  console.log('  reach=' + bet.reach + '  impact=' + bet.impact + '  confidence=' + bet.confidence + '  effort=' + bet.effort);
  console.log('  ' + bet.reach + ' x ' + bet.impact + ' x ' + bet.confidence + ' = ' + numerator + '  (numerator: people x how much it moves them x how sure)');
  console.log('  ' + numerator + ' / ' + bet.effort + ' = ' + score + '  <- riceScore\n');
}

console.log('fasterCheckout (' + riceScore(fasterCheckout) + ') vs recommendations (' + riceScore(recommendations).toFixed(2) + ')');
console.log((riceScore(fasterCheckout) > riceScore(recommendations) ? 'fasterCheckout' : 'recommendations') + ' weighs more on the RICE scale.');

What to expect. When you run the file with Node, the output is exactly this:

=== riceScore, step by step ===

fasterCheckout:
  reach=8000  impact=2  confidence=0.8  effort=2
  8000 x 2 x 0.8 = 12800  (numerator: people x how much it moves them x how sure)
  12800 / 2 = 6400  <- riceScore

recommendations:
  reach=5000  impact=1  confidence=0.5  effort=3
  5000 x 1 x 0.5 = 2500  (numerator: people x how much it moves them x how sure)
  2500 / 3 = 833.3333333333334  <- riceScore

fasterCheckout (6400) vs recommendations (833.33)
fasterCheckout weighs more on the RICE scale.

Walk through the two calculations slowly. fasterCheckout reaches a numerator of 12800 (8,000 people, each moved with impact 2, with 0.8 confidence in that estimate), and since it costs 2 person-months, its final score is 6400. recommendations reaches a much smaller numerator, 2500 (fewer people, moved with half the impact, with half the confidence), and on top of that it costs more (3 person-months), so its score drops to just 833.33. The difference between the two doesn't come from a single input: it comes from all four of fasterCheckout's variables being better at once —more reach, more impact, more confidence, less effort—. When that happens, the comparison is easy. The interesting question —the one you'll face in lesson 4 with real data— is what happens when a bet wins on some variables and loses on others, as you saw with improvedSearch in the introduction.

Notice also the number 833.3333333333334: JavaScript doesn't round it on its own. In practice, when you compare scores in a table, you'll round to two decimals (833.33) for readability —we did that in the last line with .toFixed(2)—, but the internal calculation keeps full precision. That matters when you order many bets with close scores: rounding too early can make you lose the correct order.

Why the order of operations doesn't change the result

A reasonable question: does it matter whether you multiply reach x impact first and then x confidence, or divide by effort before multiplying? Mathematically, no —(a x b x c) / d gives the same result no matter what order you do the multiplications and division in, as long as you don't round halfway through—. What does matter, and is a real source of errors, is the unit of each input: if reach is in "users per quarter" for one bet and in "users per month" for another, you're no longer comparing the same thing, no matter how well-calculated the formula is. Fixing each input's unit —same time period for reach, same scale for impact— matters as much as the formula itself, and that's exactly what lessons 4 and 5 formalize.

Common mistakes

Comparing efforts in different units. What happens: someone estimates one bet's effort in "2 sprints" and another's in "3 weeks of a senior engineer", and plugs them into the same formula without converting. Why it happens: each team estimates work with whatever unit it uses daily, and nobody stops to normalize before calculating. How to spot it: the backlog's effort values mix sprints, weeks, "story points", and person-months in the same table. How to fix it: convert everything to the same unit before calculating —this module uses person-months (how much work one person does in a month) for Mercado's five bets—; if two bets aren't in the same unit, the riceScore comparing them means nothing, even if the calculation is "done right" arithmetically.

Multiplying Reach, Impact, and Confidence and forgetting to divide by Effort. What happens: someone calculates only the numerator (reach x impact x confidence) and confuses it with the final score. Why it happens: the numerator is already a big number and "feels" like a result. How to spot it: two bets with the same numerator but very different effort (one costs 1 person-month, the other 10) end up "tied" in the comparison. How to fix it: the full riceScore always divides by effort; without that division you're measuring "how much value it produces" but not "how much value it produces per what it costs", which is the question that actually matters when capacity is limited.

Treating the riceScore as an absolute number with meaning of its own. What happens: someone says "this bet has a score of 6400, that's great!" with nothing to compare it against. Why it happens: 6400 sounds like a big, objective number. How to spot it: a single bet's score gets cited, isolated, as if 6400 meant something by itself, instead of being compared against the other bets in the same backlog. How to fix it: the riceScore only works for comparing bets within the same set, calculated with the same methodology and the same units. 6400 isn't "good" or "bad" in the abstract; it's high or low only relative to the other scores in that quarter's backlog.

Exercises

Exercise 1 — Calculate by hand. Without running Node, calculate the riceScore of a bet with reach: 4000, impact: 3, confidence: 1.0, effort: 4. Show the numerator and the final result.

See solution

Numerator: 4000 x 3 x 1.0 = 12000. Final score: 12000 / 4 = 3000. With impact at its maximum value (3, massive) and confidence also at its maximum (1.0, 100%), the numerator grows a lot; even with a relatively high effort (4 person-months), the 3000 score falls below fasterCheckout (6400) but well above recommendations (833.33) from this same lesson. It's a good exercise for noticing that impact at its maximum value (3) weighs more, per unit, than a moderate reach: the impact scale isn't linear or small, as you'll see in lesson 4.

Exercise 2 — Find the unit error. A coworker calculates the riceScore of two bets like this: A = { reach: 2000, impact: 2, confidence: 0.8, effort: 1 } (effort in person-months) and B = { reach: 2000, impact: 2, confidence: 0.8, effort: 4 } (effort in weeks, and 4 weeks are roughly equivalent to 1 person-month). What's the mistake, and how do you fix it before comparing the scores?

See solution

The mistake is mixing effort units: A is in person-months and B is in weeks, unconverted. If you calculate riceScore directly, B comes out with an effort of 4 when in reality, converted to person-months, it's 1 (4 weeks ≈ 1 person-month) —the same as A—. Without the conversion, B would look like it costs four times more than it actually does, and its score would come out four times lower than it should. The fix: convert B's effort to person-months (4 weeks / 4 ≈ 1 person-month) before calculating the score. With the corrected unit, A and B have exactly the same riceScore, because their other three inputs are identical. This is the "comparing efforts in different units" mistake from the common mistakes section, in numbers.

Exercise 3 — Predict without calculating. Two bets: X = { reach: 10000, impact: 0.25, confidence: 1.0, effort: 1 } and Y = { reach: 1000, impact: 3, confidence: 1.0, effort: 1 }. Same confidence and same effort for both. Without calculating yet, which do you think wins? Then calculate both and compare against your prediction.

See solution

X: numerator 10000 x 0.25 x 1.0 = 2500, score 2500 / 1 = 2500. Y: numerator 1000 x 3 x 1.0 = 3000, score 3000 / 1 = 3000. Y wins, despite having ten times less reach than X. The reason: impact at its highest value (3) is twelve times greater than at its lowest value (0.25), so a tenfold smaller reach can be offset —and more than offset— by a much higher impact. If your prediction was "X wins, it has way more reach", it's worth noting the pattern: a massive reach with minimal impact doesn't always beat a modest reach with high impact. This is exactly the kind of comparison lesson 4 explores in depth.

Summary and next step

In this lesson you built the complete scale: riceScore({reach, impact, confidence, effort}) = reach x impact x confidence / effort. You ran it step by step over fasterCheckout (score 6400) and recommendations (score 833.33), seeing that the numerator measures expected value (people x how much it moves them x how confident the estimate is) and the denominator divides it by cost, in the same unit for every bet. And you learned two rules that will stay with you the rest of the module: riceScore only makes sense compared within the same backlog, and comparing effort in different units invalidates any comparison, no matter how neat the formula looks.

Before moving on you should be able to: write the riceScore formula from memory; calculate it by hand given an object with the four inputs; and explain why comparing two scores calculated with effort in different units is a mistake, even if the arithmetic is "done right".

Lesson 4 fully opens the scale's first two pans: Reach and Impact. You're going to see where each number comes from —what counts as "reach" at Mercado, what each level of the impact scale means— and why, as you saw in exercise 3, a huge reach with minimal impact can lose against a modest reach with high impact.

Resources

• Intercom, "RICE: Simple prioritization for product managers" — intercom.com/blog/rice-simple-prioritization-for-product-managers. The original source of the exact formula used in this lesson, including the impact scale and the confidence format as a percentage. In English.
• ProductPlan, "RICE Scoring Model" — productplan.com/glossary/rice-scoring-model. Reference explanation of each input and why RICE became a de facto standard in product prioritization. In English.
• Basecamp, "Shape Up" — basecamp.com/shapeup. A different approach to deciding what to build, useful as a contrast: where RICE scores candidates, Shape Up fixes the available time first and shapes the work within that limit. In English.