How RICE scoring works
RICE is a prioritization framework from Intercom's product team. It turns four estimates into one comparable number, which makes it harder for the loudest request or the most recent customer call to jump the queue.
| Input | Question it answers | Scale |
|---|---|---|
| Reach | How many users or accounts will this affect in a set period? | A real count per quarter (or per month), such as 400 users |
| Impact | How much will it move the goal for each user it reaches? | 3 · Massive, 2 · High, 1 · Medium, 0.5 · Low, 0.25 · Minimal |
| Confidence | How sure are you about the reach and impact estimates? | 100% · High, 80% · Medium, 50% · Low |
| Effort | How much team time will it take, design to release? | Person-months (or any one unit used for every item) |
A worked example
The example backlog in the calculator above is a typical small SaaS list. Here is how it ranks:
| Rank | Feature request | Calculation | RICE score |
|---|---|---|---|
| 1 | Slack alert for new bug reports | 180 × 2 × 80% ÷ 0.5 | 576 |
| 2 | Onboarding checklist | 600 × 2 × 50% ÷ 1.5 | 400 |
| 3 | CSV export for reports | 420 × 1 × 80% ÷ 1 | 336 |
| 4 | Dark mode | 900 × 0.5 × 50% ÷ 2 | 113 |
| 5 | SSO / SAML login | 40 × 3 × 100% ÷ 3 | 40.0 |
Dark mode reaches the most users (900), yet it ranks #4. Its impact per user is low and nobody has evidence it changes retention, so confidence is 50%. Slack alert for new bug reports wins because a small, cheap change helps a group of users a lot. That is the point of RICE: it shows the trade-off a vote count hides.
Where to get each number
- Reach: start with the number of unique users who requested the feature or voted for it on your roadmap, then check product analytics for how many users touch that part of the product each quarter.
- Impact: tie it to one goal you track, such as activation, retention, or expansion revenue. If you cannot name the goal, score impact at 0.5 or lower.
- Confidence: use 100% only when you have data for both reach and impact, 80% when you have data for one, and 50% for a hunch.
- Effort: ask the people building it, and include design, QA, docs, and release work, not just coding time.
Common RICE mistakes
- Mixing reach periods: one item per month, another per year.
- Giving everything 100% confidence, which turns RICE back into gut feel.
- Counting requests instead of people, so one vocal customer looks like ten.
- Treating the score as the decision. Use it to start the conversation, then check strategy and dependencies.
- Scoring bugs with RICE. Triage bugs by severity and frequency instead; see the bug reporting workflow.
Collecting the requests you score
RICE is only as good as the list you feed it. If requests arrive through email, DMs, and support chats, you will undercount reach for some and miss others entirely. A single intake point fixes that. A feedback widget in your product sends every request to one inbox, and a public roadmap with votes gives you a running reach count. Before you score a request, use the clarifying questions to learn the problem behind it.
Questions people ask
What is a good RICE score?
There is no universal good score. RICE scores only mean something relative to the other items scored with the same reach period and effort unit. Use the ranking, not the absolute number.
What unit should I use for effort?
Person-months is the original convention, but person-weeks or ideal days work as long as every item uses the same unit. Mixing units is the most common way RICE rankings go wrong.
How do I estimate reach for a feature request?
Count the people or accounts affected in a fixed period, such as one quarter. A good starting point is the number of unique users who asked for it or voted on it, scaled by how many similar users never told you.
Is RICE better than ICE or MoSCoW?
RICE adds reach, which makes it better for comparing requests that affect very different numbers of users. ICE is faster when you lack usage data, and MoSCoW is better for scoping a single release than for ranking a backlog.
Is my data stored anywhere?
No. The calculator runs in your browser and saves your list to this browser’s local storage only. Nothing is sent to TellTide.