RICE Scoring: Data-Driven Prioritization

RICE scores a feature with one number: (Reach × Impact × Confidence) / Effort.

Start Here: What Is RICE?

The problem: An overloaded backlog

Product backlogs often contain more requests than a team can complete. Without an agreed method, rankings can depend on unexamined assumptions or the most vocal input.

The solution: The RICE formula

RICE weighs how many users a feature affects, how much it may help each person, how confident you are in those estimates, and how much work it takes. Intercom introduced the framework.¹

The formula:

RICE Score = (Reach × Impact × Confidence) / Effort

Use the score to support discussion, not to replace it.

The Four Components

1. REACH: How Many Users?

Simple Definition: Count the actual number of users who will experience this feature in your chosen time period.

Guidance: Use a count for a consistent time period, and base it on available evidence.

Common mistake: Counting all users when the feature applies only to a specific segment.

Use analytics or research where available, and record uncertainty where it is not.

2. IMPACT: How Much Does It Matter?

Simple Definition: How much will this improve the experience for each affected user?

The Impact Scale - Choose One:

Question to consider: If the feature were unavailable, how much would it affect the relevant users?

3. CONFIDENCE: How Sure Are We?

Simple Definition: How certain are you that your Reach and Impact estimates are correct?

The Confidence Scale:

Choose confidence definitions before scoring. Higher scores should be supported by stronger evidence.

4. EFFORT: What's the Total Cost?

Simple Definition: Total person-months needed from start to users actually using it.

The Complete Effort Checklist:

Real Example - Adding Filters to a Dashboard:

Discovery: 0.5 PM weeks = 0.125 person-months
Design: 2 designer weeks = 0.5 person-months  
Development: 2 engineers × 3 weeks = 1.5 person-months
Testing: 1 QA × 1 week = 0.25 person-months
Launch: 0.5 PM weeks = 0.125 person-months
Subtotal: 2.5 person-months
+ 30% buffer for unknowns = 3.25 person-months total

Consider an explicit contingency when the estimate has meaningful uncertainty. The appropriate amount depends on the work and team.

Try It Now

Score a real feature:

Example: Scoring dark mode

Step 1 - REACH: Who will use this?

• Total mobile users: 100,000 MAU
• Analytics shows 50% use app settings
• Estimated reach: 50,000 users
• Reach = 50,000

Step 2 - IMPACT: How much will it help each user?

• User feedback: "Would be nice to have for night reading"
• Doesn't solve a core problem, just improves comfort
• Using our scale: This is a "nice improvement"
• Impact = 1 (Medium)

Step 3 - CONFIDENCE: How sure are we?

• Evidence: 20 user requests, competitors have it
• No tests run, but logical that some users want it
• This is more than a guess but not proven
• Confidence = 70%

Step 4 - EFFORT: What will it take?

Design: 1 designer × 1 week = 0.25 person-months
Development: 2 engineers × 2 weeks = 1 person-month
Testing: 1 QA × 0.5 weeks = 0.125 person-months
Documentation: 0.125 person-months
Subtotal: 1.5 person-months
+ 30% buffer = 2 person-months total

• Effort = 2

Step 5 - Calculate RICE Score:

RICE = (50,000 × 1 × 0.70) / 2 = 17,500

Compare this score with other features scored using the same time period and scales. A RICE score has no universal priority threshold.

Real-World Examples

Intercom's Team Inbox

The original RICE use case¹:

• Reach: 2,000 customers/quarter
• Impact: 3 (Massive - key differentiator)
• Confidence: 80% (extensive interviews)
• Effort: 4 person-months
• RICE: 1,200

This example illustrates how a large estimated impact can offset higher effort for a key segment.

Spotify's Discover Weekly (Hypothetical)

• Reach: 100 million users/month
• Impact: 2 (High - drives engagement)
• Confidence: 60% (algorithm unproven)
• Effort: 10 person-months
• RICE: 12,000,000

High estimated reach can justify higher effort, depending on the strategic context.

Notion's Database Feature (Hypothetical)

• Reach: 10,000 power users/month
• Impact: 3 (reshapes the product)
• Confidence: 90% (deep research)
• Effort: 20 person-months
• RICE: 1,350

Lesson: Strategic value can outweigh moderate RICE score. The framework doesn't capture everything.

Common mistakes

1. Overestimating reach

What Happens: You score Reach as 100% of users for a settings menu feature. How to address it:

• Check your analytics for actual feature usage
• Look at similar features' adoption rates

2. Inflated impact scores

What Happens: Every feature gets Impact = 2 or 3 because "it's important." How to address it:

• Define specific metrics: "High = 10%+ improvement in our key metric"
• Compare new features to past launches - what was their real impact?

3. Overconfidence in estimates

What Happens: Everything is 80-100% confidence because you discussed it in a meeting. How to address it:

• Only increase with real evidence (user interviews, data, tests)
• Track predictions against outcomes and adjust the rubric when needed

4. Incomplete effort estimates

What Happens: Effort = 2 engineers × 2 weeks = 1 person-month. Done! How to address it:

• Use the complete effort checklist (see above)
• Ask each team lead separately, then add it up

5. Inconsistent time periods

What Happens: Feature A uses monthly reach, Feature B uses quarterly, Feature C uses yearly. Scores based on different time periods are not directly comparable. How to address it:

• Pick one standard (monthly or quarterly)
• Convert all features to the same time period
• Put the time period in your spreadsheet header as a reminder

AI Prompts for RICE Scoring

Estimate Reach

Estimate Reach for these features based on our segments:
[paste features and user data]
- Total users: [X]
- Segments: [list segments and sizes]
- Feature usage patterns: [current behavior]
Provide monthly reach with reasoning.

Score Impact

Score Impact using our North Star metric:
[paste features]
North Star: [your key metric]
Current baseline: [performance]
Scale: 0.25 (Minimal) to 3 (Massive)
Justify with expected metric improvement.

Assess Confidence

Generate Confidence scores from this research:
[paste research findings]
Assess:
- User evidence (quotes, surveys)
- Competitive analysis
- Technical feasibility
- Similar past features
Output percentage with justification.

Estimate Effort

Estimate effort in person-months for:
[feature description]
Consider:
- Frontend development
- Backend development
- Design work
- QA/Testing
- Documentation
- Rollout complexity
Break down by role and phase.

When to Override RICE Scores

Sometimes you need to build something despite a low score:

• Platform work that future features depend on
• Strategic partnerships or key customer needs
• Compliance or security requirements
• Technical debt that's blocking development

Key Rule: Document why you're overriding RICE. Review these decisions quarterly.

RICE vs Other Frameworks

Teams can use different methods for different decisions. No fixed progression is required.

Troubleshooting Your RICE Implementation

Problem: "Our scores are all over the place"

Symptom: Team members' scores differ by 10x for the same feature Solution:

• Create a scoring rubric with specific examples
• Do calibration exercises with past features
• Start with comparing rankings, not absolute scores

Problem: "Everything scores low"

Symptom: All features get RICE scores under 1,000 Approach:

• Check your time period - maybe switch from monthly to quarterly
• Check that features use the same time period and units
• Focus on the relative ranking and the assumptions behind it

Problem: "The highest score isn't what we should build"

Symptom: RICE says Feature A, but strategy needs Feature B Approach:

• RICE is input, not a final decision
• Document strategic overrides
• Consider if you need weighted scoring instead

Problem: "It takes forever to score everything"

Symptom: Spending hours debating each score Approach:

• Set a time limit that fits the decision
• Use rough estimates: 10, 100, 1000, not 47 vs 52
• Score in batches, not one by one

Problem: "Our predictions are always wrong"

Symptom: Actual impact never matches estimates Approach:

• Compare predictions with outcomes, then revise the confidence rubric
• Track predictions vs reality for learning
• Focus on relative accuracy, not absolute

Introduce it gradually

RICE supports discussion. It does not settle every decision. Start with a small set of features and refine the rubric from the results.

Week 1: Start Small (30 minutes)

Monday (10 min): Pick your standard time period (monthly or quarterly) Wednesday (10 min): Score your top 3 features using the calculator above Friday (10 min): Share scores with your team, get their reaction

Week 2: Expand (2 hours total)

Monday (1 hour): Score your entire sprint backlog Wednesday (30 min): Review scores with your tech lead Friday (30 min): Present top 5 RICE scores in sprint planning

Week 3: Align (3 hours total)

Team Workshop (2 hours):

• Everyone scores the same 5 features independently
• Compare and discuss differences
• Create your team's Impact definitions
• Document your scoring rules

Follow-up (1 hour): Update all backlog items with RICE scores

Week 4 and Beyond: Refine

• Track whether high RICE features actually delivered value
• Adjust your confidence scoring based on results
• Add RICE scoring to your feature request template
• Review and recalibrate quarterly

When you present to stakeholders, share the scores and the math behind them, not just the ranking. Be clear about when you've overridden a score and why.

Key takeaways

• Use a consistent time period and scoring rubric across comparable features.
• Base Reach, Impact, Confidence, and Effort estimates on available evidence.
• Include the work needed to deliver and support the feature in Effort.
• Treat RICE as input to a decision and document strategic overrides.

Next Steps

Try these next:

1. Score features with our RICE Calculator
2. Try simplified ICE Scoring for smaller teams
3. Use Weighted Scoring for custom criteria
4. Plot on Impact/Effort Matrix for visualization

Sources