RICE scoring: formula, worked example and pitfalls

RICE scoring ranks product ideas with one number: reach times impact times confidence, divided by effort. A higher score means more expected value per unit of work. The method came from the product team at Intercom and has become a default way to compare feature requests that cannot be separated by gut feeling. It works best on a short list of serious candidates, and it is only as good as the estimates that go into it.

What is the RICE scoring formula?

The score is Reach × Impact × Confidence ÷ Effort. Reach, impact and confidence multiply because each one scales the payoff, and effort divides because the same payoff costs more when it takes more work. Pick one time window for reach, such as a quarter, and use it for every item, or the scores will not compare.

Intercom’s original write-up defines the scales in the table above, and most teams keep them unchanged so scores stay comparable between people.

How do you score each RICE factor?

Reach comes from data you already hold. For a feature request, start with the number of distinct accounts that asked, then add an estimate of the accounts that would use it without asking. Impact is the least precise factor, so use the five-value scale and resist inventing decimals. Confidence is a discount for guessing: use 100% only when you have usage data or a tested prototype, 80% when you have strong signals, and 50% when you are mostly guessing. Effort is the time of everyone involved, design and testing included, in person-months.

Two people scoring the same item should land within one step of each other on every factor. If they do not, the item is not understood well enough to rank, and the disagreement is the finding.

What does a RICE scoring example look like?

Take four requests from a tracked backlog, scored over one quarter.

Work through the first row: 400 × 1 × 0.8 ÷ 1 = 320. Dark mode reaches three times as many people but each of them gains little, so it lands just below the export. The Slack integration has a good impact score that confidence cuts in half, which tells you the next step is research, not building.

Single sign-on ranks last, and that deserves a second look. Sixty accounts is a small reach, but if those are the larger accounts and several renewals depend on the feature, the score is missing something the method cannot see.

What are the common RICE mistakes?

The first is false precision. A reach of 1,247 and an impact of 1.3 look rigorous and carry no more information than 1,200 and 1. Round aggressively.

The second is scoring items you have already decided to build. The scores then get nudged until the favorite wins, and the exercise only produces cover.

The third is ignoring who asked. RICE counts people, so a request from ten small accounts outscores a request from one account worth more than all ten together. When revenue matters, add a column for it and read it beside the score. Weighting by account is covered in how to prioritize feature requests.

The fourth is comparing scores across different time windows or different teams’ scales. Keep one sheet, one window and one set of definitions.

When should you use something other than RICE?

When you have no reach data, use ICE (impact, confidence, ease), which drops reach and replaces effort with an ease rating, and accept that it is rougher. When the question is what kind of value a feature carries instead of how much, the Kano model classifies requests as must-be, performance or delighter features, and the two combine well. When the decision is about order and timing instead of ranking, a roadmap format fits better, and how to build a product roadmap covers it.

How do you keep RICE scores honest over time?

Store the inputs next to the score, not only the result, so anyone can see which assumption drove a rank. Revisit an item when its facts change, such as a new batch of requests lifting reach, or an engineer spotting that effort doubled. After shipping, compare the predicted reach and impact with what happened and adjust how your team estimates next time. The raw material for reach is the grouped, labelled request list described in feature request tracking, and the result belongs in the reply you send to the people who asked.

FAQ

What is a good RICE score? There is no universal threshold, because the number depends on your reach window and effort unit. Compare scores only within one sheet, and treat the ranking, not the absolute value, as the output.

What is the difference between RICE and ICE scoring? ICE multiplies impact, confidence and ease and leaves out reach. It is faster to fill in and less accurate when features affect very different numbers of users, which is the case RICE was designed for.

How do you estimate reach for a feature request? Start with the count of accounts that requested it, add the share of active accounts likely to use it unprompted, and express the total per quarter. If the guess is rough, lower the confidence factor instead of inventing precision.

Should every feature request be scored with RICE? No. Scoring is worth the effort for the handful of items close enough to need a tiebreaker. Obvious wins and obvious rejections can be decided without it.

The technical claims in this article have not been independently reviewed. If something here is wrong, tell us and we will correct it.

Related on changeloop: Developer docs, Changelog tools compared