Blog

RICE Feature Scoring: Formula, Example and Pitfalls

RICE Feature Scoring: Formula, Example and Pitfalls

Hand-drawn scoring motifs framing the title

RICE feature scoring ranks backlog items with one number: (Reach × Impact × Confidence) ÷ Effort. A higher score means more expected value per unit of work. The method is quick to learn. The hard part is feeding it honest inputs and not treating the output as a verdict.

This guide covers the formula, the scales, a worked example with numbers, the mistakes that make scores meaningless, and where the Kano model fits next to RICE.

TL;DR

  • RICE = (Reach × Impact × Confidence) ÷ Effort. Score each backlog item, then sort by the result.
  • Use fixed scales: impact from 0.25 to 3, confidence at 100%, 80% or 50%, effort in person-months.
  • Confidence is the weakest input. Write down the evidence behind every percentage.
  • RICE ranks. It does not tell you whether a feature fits your strategy, so set the goal first.
  • Kano answers a different question: how users will feel about a feature, not how it ranks.

Table of Contents

What RICE feature scoring is

RICE is a prioritization framework that compares initiatives on four factors: Reach, Impact, Confidence and Effort. Sean McBride created it at Intercom in 2018 because the growth team needed a more structured way to compare very different project ideas than gut feeling and the loudest voice in the room.

The point is not mathematical precision. The point is that every idea gets judged on the same four questions, so a debate about "which feature is better" turns into a debate about specific assumptions. Dovetail's analysis of feature prioritization makes the same point: the goal is a common language for trade-offs rather than an argument over personal opinion.

The formula, factor by factor

The RICE formula is:

Score = (Reach × Impact × Confidence) ÷ Effort

Reach

Reach is how many people the feature touches in a set period. Pick one period and use it for every item. Monthly is the usual choice. A guide from Rework adds a useful warning: be honest about what "affects" means. A user who sees a settings page once is not "reached" by a change to it in the same way as a user who lives in it daily.

Good sources for reach: product analytics (monthly active users who hit that screen), support ticket counts, and the number of votes a request has on your feedback board.

Impact

Impact is the effect on each person reached, toward the goal you chose. The standard scale is 3 for massive, 2 for high, 1 for medium, 0.5 for low and 0.25 for minimal. Because it is a coarse scale, two people can disagree by one step, and that disagreement is exactly what you want to surface.

Confidence

Confidence is how sure you are about reach, impact and effort. The usual scale is 100% for high confidence backed by data, 80% for medium confidence backed by some evidence, and 50% for low confidence, which is mostly a guess. The same guide notes that anything under roughly 40 to 50% is generally treated as a high-risk moonshot.

Effort

Effort is the total work from every function, counted in person-months: design, engineering, QA, docs and anything else that has to ship. Round up. Effort sits in the denominator, so underestimating it inflates a score faster than any other mistake.

A worked example

Imagine a small B2B product team with one goal for the quarter: raise the share of new accounts that invite a teammate in their first week. Reach is the number of accounts affected per month. These numbers are illustrative, not benchmarks.

FeatureReach (accounts/month)ImpactConfidenceEffort (person-months)RICE score
One-click invite link300280%0.5960
Onboarding checklist2,000180%2800
Redesigned dashboard4,0000.5100%4500
Slack-based invites500350%3250

The math for the first row: 300 × 2 × 0.8 = 480, divided by 0.5 gives 960.

What the table tells you:

  • The invite link wins on a small reach because it is cheap to build and likely to work.
  • The dashboard redesign reaches the most people, but the per-user effect on the goal is small and the cost is high.
  • Slack invites have the biggest per-user effect, but at 50% confidence and three person-months they fall to the bottom. If someone could raise that confidence with five customer interviews, the score would move.

That last point is the real value. The score shows which inputs to go and verify.

How to interpret a RICE score

The absolute number means nothing. A score of 960 is not "good". It only means something relative to the other items scored in the same period with the same reach definition. Do not compare scores across teams or quarters.

Read the list this way:

  1. Look at the top three and the bottom three. The middle of the list is noise.
  2. Look for scores within about 20% of each other. Treat them as ties and decide on strategy or dependencies.
  3. Look for surprises. If the item everyone loves lands near the bottom, find out which input drove it. Either the input is wrong or the enthusiasm is.

Practitioners describe the best use of the final number as a way to surface disagreements and force trade-off conversations rather than to close them.

Where RICE goes wrong

The illusion of objectivity

A precise number feels scientific. Experts point out that teams then prioritize the number over sound judgment. The score is only as good as the evidence behind it, and a framework can be used to make a guess look objective.

Inflated confidence

Confidence is usually self-assessed, and it invites enthusiasm bias: teams rate features they want to build more confidently. One critique argues that the confidence score is a number picked by feel, with nothing to check it against and no way to test it afterward.

A simple fix: next to every confidence percentage, write the evidence in one line. "80%: 14 customer requests plus a prototype test with six users" is a score. "80%: feels right" is a 50%.

Gamed effort

When a pet project is on the list, effort estimates tend to shrink. Have the people who will build it estimate effort, not the people who proposed it, and keep the estimates visible.

Apples to oranges

RICE works best when every item serves one clear goal, such as improving activation. Applied to a mix of unrelated items (a security fix, a billing change, a new integration), the scores stop being comparable. Experienced managers suggest pairing RICE with other frameworks, such as Kano for the intent of a feature, or WSJF when time-sensitivity and cost of delay matter.

Strategy blindness

RICE does not know your strategy, your dependencies or your deadlines. As Nexoro's piece on going beyond RICE notes, two features with the same score can serve very different goals. Define the current strategic focus first, then score. Fygurs' comparison also observes that leadership often overrides scoring outcomes, which is a sign that RICE works better for documenting trade-offs than for making decisions automatically.

RICE vs Kano: different questions

Teams searching for RICE often end up asking about Kano too, so here is the short version.

RICE ranks items by estimated value per unit of effort. The Kano model, introduced in 1984, sorts features by how customers react to having or lacking them. The categories:

  • Must-be: basic expectations. Users barely notice them when present and are upset when absent.
  • Performance: satisfaction rises roughly in line with how much of the feature you provide.
  • Delighters: unexpected features that create enthusiasm.
  • Indifferent and reverse: features users do not care about, or actively dislike.

Kano is a survey method: you ask users how they would feel if a feature existed and how they would feel if it did not. It is a diagnostic of user needs, not a backlog ranker. The Microsoft best-practices document reports that roughly one in four tested features ends up in the indifferent or reverse groups, which makes Kano a good way to catch features that would not pay off.

A practical combination:

  1. Use Kano on a handful of big bets to learn whether they are must-haves, performance drivers or delighters.
  2. Feed that into the Impact and Confidence inputs in RICE.
  3. Use RICE to rank the long list.

If your problem is scope negotiation for a fixed deadline, a different tool fits better. Our piece on MoSCoW prioritization with evidence covers it.

Running a RICE session that holds up

  1. Write the goal on the first line. One goal per scoring round.
  2. Fix the definitions. Reach period, what counts as "reached", and what each impact level means in your product.
  3. Score alone first, then together. Independent estimates before discussion prevent anchoring on the first number said aloud.
  4. Record evidence. A link or a line for every confidence value.
  5. Sort, then argue. Spend the meeting on the items where people's inputs differ the most.
  6. Re-score after learning. When an interview or test changes your confidence, update the row.
  7. Keep the override visible. If leadership moves an item up, write down why. That is not a failure of the method; it is the method documenting a trade-off.

Time-box it. A scoring pass should take a couple of minutes per item, not an hour. If an item needs an hour, that tells you its confidence is low and it needs research, not debate.

Our view: use real user evidence for Reach and Confidence

We build a public feedback board, so we see where RICE inputs come from in practice, and the usual weakness is that teams guess at the two inputs customers can actually inform.

Reach is a count. If requests live in emails, chats and call notes, nobody can count them, so reach becomes a hunch. When ideas are posted and voted on in one place, a request with 140 votes and a request with 6 are visibly different, and you can tell which accounts asked. That turns the Reach input from a guess into something you can point at. Confidence works the same way: comments on an idea reveal the use case, and a cluster of people describing the same problem in their own words is stronger evidence than a team's enthusiasm.

Our advice, in order:

  • Treat votes as a signal for reach, not as the score itself. Votes show who is vocal, not necessarily who is affected, so cross-check with analytics.
  • Do not publish RICE scores to customers. Publish statuses (under review, planned, in progress, shipped) and a roadmap, which explain what you are doing without making promises tied to a formula. Our guide to public product roadmap formats shows four ways to do that.
  • Keep roadmap and backlog separate, or scores will drift away from what you tell users. See our five-step playbook on roadmap and backlog drift.
  • If your roadmap is organized by time horizon, set strategic triggers before scoring. We describe one approach in our now, next, later roadmap guide.

The score should end a guessing contest, not start a new one.

— Aron

Collect the evidence RICE needs

If your feature requests are scattered, scoring them is the slow part. Petĩra gives you a public feedback board where users post ideas, vote and comment, with statuses and a public roadmap on top. Import existing feedback from Canny, Fider or a CSV file, and export everything as JSON or CSV when you want to score it in a spreadsheet.

Every plan includes unlimited users, ideas and votes at a flat rate. The Free plan costs 0 € per month, Pro is 19 € per month (190 € per year), and Team is 49 € per month (490 € per year). See the plans on our pricing page, or start from the Petĩra homepage. If you are comparing the market first, our pricing comparison of 12 feedback tools lays out the numbers.

Collect the evidence RICE needs — overview diagram

FAQ

What is the RICE scoring method?

RICE is a prioritization method that scores each initiative on Reach, Impact, Confidence and Effort. You multiply the first three, divide by effort and rank the results. It was created at Intercom to compare many different project ideas in a consistent way.

How do you calculate a RICE score?

Estimate reach as the number of users affected in a fixed period, impact on a 0.25 to 3 scale, confidence as a percentage and effort in person-months. For 1,000 users, impact 2, confidence 80% and 2 person-months, the score is 1,000 × 2 × 0.8 ÷ 2 = 800. Compare it only with other items scored the same way.

Is RICE better than the Kano model?

Neither is better, because they answer different questions. RICE ranks a backlog by expected value per effort, while Kano diagnoses how users feel about features: must-have, performance or delighter. Many teams use Kano to inform the impact and confidence inputs, then rank with RICE.

When should you not use RICE?

Avoid it when items serve unrelated goals, when you have no data and every confidence value would be a guess, or when a hard deadline or dependency decides the order. In those cases use RICE only as a conversation aid, and add a framework that handles time-sensitivity or scope.

Sources

Recommended