Posts

RICE scoring framework: how to prioritize your product backlog

Product team gathered around a whiteboard covered in colorful sticky notes, sorting and ranking items to decide what to build next Every product team has the same problem: too many ideas and not enough time. Stakeholders push competing priorities, engineers want to pay down tech debt, and customers keep requesting features. Without a clear way to rank what matters most, the loudest voice in the room wins. RICE is a scoring framework developed by Intercom's product team that tries to fix this. It evaluates features across four dimensions (Reach, Impact, Confidence, and Effort) and produces a single number you can use to compare anything in your backlog.

How RICE scoring works

Here's the formula: RICE Score = (Reach × Impact × Confidence) / Effort Each component measures something different:

Component	What it measures	How to score it
Reach	How many people this affects in a set time period	Real numbers (e.g., 2,000 users/quarter)
Impact	How much each person is affected	3 = massive, 2 = high, 1 = medium, 0.5 = low, 0.25 = minimal
Confidence	How sure you are about your estimates	100% = data-backed, 80% = some evidence, 50% = mostly guesswork
Effort	Total team time required	Person-months (include design, dev, QA, docs)

The output is "total impact per time worked," which is what you should optimize for when deciding what to build next.

A quick example

Say your team is considering adding personalized product recommendations:

• Reach: 2,000 customers per quarter
• Impact: 2 (high, directly affects conversion)
• Confidence: 80% (you have A/B test data from a competitor)
• Effort: 3 person-months

RICE Score = (2,000 × 2 × 0.8) / 3 = 1,067 Compare that against other backlog items and you have a data-driven ranking. Try plugging your own features into our free RICE Score Calculator to see how they stack up.

Scoring each component well

The formula is simple. Getting accurate inputs is the hard part.

Reach: use real numbers, not percentages

Reach should be a concrete count of users or events over a fixed time period. "All our users" is not a reach estimate. Check your analytics. If you're building a new settings page, don't assume all 10,000 active users will touch it. Historical data might show only 1,200 users visit settings in a given quarter. Use that number.

Impact: force a distribution

The biggest mistake teams make with Impact is rating everything a 2 or 3. If every feature is "high impact," the score loses meaning. Set a rule: no more than 20% of features can be rated 3 (massive). Define what each level means for your specific metrics. For example, "3 = projected 10%+ improvement in a business metric we're actively tracking."

Confidence: start low and earn your way up

Default to 50% confidence for any idea that hasn't been validated. A stakeholder request with no user research? 50%. A feature inspired by a competitor with no data on whether your users want it? 50%. Move to 80% when you have supporting evidence like user interviews, survey data, or prototype test results. Save 100% for features backed by hard analytics or successful experiments.

Effort: count everything, not just engineering

A common trap is estimating only dev time. Real effort includes discovery, design, QA, documentation, and launch coordination too. Ask each discipline for their estimate and add a 30% buffer. A person carefully balancing objects of different sizes on a scale, representing the weighing of reach, impact, confidence, and effort

RICE vs MoSCoW vs WSJF

RICE isn't the only prioritization framework out there. Two other popular options are MoSCoW and WSJF. Each works best in different contexts.

	RICE	MoSCoW	WSJF
Type	Quantitative score	Categorical buckets	Economic score
Best for	Feature-level ranking	MVP scope definition	Epic/initiative-level decisions
Data needed	User metrics + estimates	Stakeholder judgment	Economic data + cross-team input
Complexity	Medium	Low	High
Output	Numerical priority score	Must / Should / Could / Won't	Cost-of-delay priority

MoSCoW sorts items into Must Have, Should Have, Could Have, and Won't Have. It's fast and easy to explain to non-technical stakeholders. The downside is that it's subjective: everything tends to drift into "Must Have" without clear criteria. It works best early on when you're defining an MVP. WSJF (Weighted Shortest Job First) comes from the SAFe framework. Its formula factors in business value, time criticality, and risk reduction, all divided by job size. It works well for large initiatives spanning multiple teams, but it requires real training to use properly. Most teams find it overkill for feature-level decisions. RICE sits between the two. It asks for more rigor than MoSCoW but doesn't need the heavy data infrastructure WSJF demands. If your team has basic user analytics and wants to move past gut-feel prioritization, RICE is a good starting point. If your team uses priority poker to collaboratively rank backlog items, RICE scores give you a solid starting point for those discussions.

Common mistakes that skew your scores

Even teams that adopt RICE consistently fall into a few traps. Scoring in isolation. When a single PM scores everything alone, bias creeps in. Have engineers estimate Effort, designers weigh in on Impact, and data analysts validate Reach. Collaborative scoring produces better results. Anchoring on the first score. If you discuss scores out loud before everyone votes, people anchor on the first number they hear. Score individually first, then compare. Same principle as planning poker: independent estimation before group discussion. Skipping recalibration. RICE scores go stale. Market conditions shift, new data comes in, and team capacity changes. Revisit scores quarterly and update any item that's been sitting in the backlog for more than one cycle. Treating the number as absolute. A RICE score of 850 vs 820 doesn't mean the first feature is meaningfully more important. Group similar scores into tiers (high / medium / low priority) and use judgment within each tier. Team members individually writing scores on cards before revealing them together, preventing anchoring bias

Getting started with RICE

If you haven't used RICE before, here's how to roll it out without overcomplicating things. The goal isn't perfect precision. An estimate that's roughly right beats an opinion that's confidently wrong. Most of RICE's value comes from the conversation it forces: who are we building for, how much does it matter, and what will it actually cost. For more on preparing your backlog for sprint planning, see our guides on backlog refinement and sprint planning.