RICE Prioritization Scoring Template

In the post that introduced RICE, Intercom's Sean McBride defines each input and how to measure it¹. Keep his scales and count reach over one period for every item, since mixing monthly and quarterly counts inflates some scores threefold.

Then write down what impact means. McBride's team asks how much a project will "increase conversion rate when a customer encounters it." Yours might ask about retention or revenue, ideally tied to one of your team's OKRs. Two-factor sign-in scores low on user experience and high on unblocking enterprise deals, so pick one question for the whole backlog. If it ever changes, rescore every item's impact.

Pull every request into one list before scoring: sales call notes, support tags, survey answers, feedback forms. Give each distinct request its own row and record what the person actually said. "Better reporting" and "a monthly report of jobs per technician" look alike in a summary, but they need very different effort estimates.

Mark duplicates instead of deleting them: a request that arrives through three channels has more behind it. Split a row when two people turn out to describe different features. If nobody can say how many people a request would reach, leave it unscored and note why. When the evidence sits in interview recordings, turn the transcripts into themes first.

Take reach from data. Intercom's advice is to "use real measurements from product metrics instead of pulling numbers from a hat"¹. When reach needs arithmetic, show it: 1,200 sign-ups a month × 25% × 3 months = 900 a quarter.

For impact, write the mechanism in one sentence, then pick the notch that follows from it. "Saves each new account four hours of manual setup" is a basis someone can check; "high value to users" is not. If every item comes out high or massive, the scale isn't doing its job.

Confidence should name the estimate it discounts, such as reach from a survey with a 38% response rate. Itamar Gilad, a product coach who led parts of Gmail at Google, grades evidence with a Confidence Meter². In his example, your own conviction, an industry trend and colleagues' opinions add up to 0.1 out of 10: "Near Zero Confidence."

Effort comes from the people who will build it. The Scrum Guide is blunt: "The Developers who will be doing the work are responsible for the sizing."³ If there's no estimate yet, leave the cell blank rather than invent the weakest number in the formula.

Sort by score, then test the order before sharing it. The impact scale is built from doublings: minimal to low, low to medium and medium to high each double a score. Confidence's whole range, from 50% to 100%, doubles it only once.

In a sample backlog, SMS reminders score 4,000 (12,000 jobs × 1 × 100% ÷ 3) and two-factor sign-in scores 2,200 (8,800 users × 0.5 × 100% ÷ 2). Rate two-factor's impact medium instead of low and it scores 4,400, putting it first. First place rests on one person's choice between two adjacent words.

UK government analysts run the same test. HM Treasury's Green Book⁴ tells them to calculate switching values, such as the value of a key input that "would make the preferred option less attractive than another shortlisted option."

1. 1

   Find the gap

   Note the score of the item just above this one.

2. 2

   Move one input at a time

   Raise impact one notch, then confidence, then cut effort one step, holding the others fixed.

3. 3

   Record the cheapest change

   Write down the smallest change that gains a rank, and the score it produces.

4. 4

   Label the item

   Call it fragile if one notch or step moves it, firm if none does. Fragile means a judgment holds it there, so say whose.

When two people give one input different values, don't split the difference. Impact scores of 1 and 3 don't mean 2; often the two people are answering different questions. Record both values with their evidence and rank the item each way, to see how many places the argument is worth. HM Treasury's guidance on scoring options⁵ does the same: if a disagreement "cannot be easily resolved," record the reasons and test its "practical effects" in the sensitivity analysis.

Sometimes settling it changes nothing. In the same sample, a custom report builder sits last at 262.5 with high impact. At massive it would reach only 394, still short of the 483 above it, because 8 person-months of effort and low confidence hold it there.

The score informs the decision; it doesn't make it. Intercom's post says RICE scores "shouldn't be used as a hard and fast rule"¹, and names dependencies and "table stakes" features as reasons to work out of order. In Scrum, the Product Owner is accountable for ordering the backlog and is "one person, not a committee."³

Record every override with the rank it overrode, the reason, who decided and whether the requester knows. "Three stalled deals worth $520,000 need it this quarter" is a reason; "strategic priority" is not. Reordering quietly while the old scores stay put is how a team stops trusting the sheet.

When someone asks why their request isn't first, give three things: the gap to the item above, the input holding it there and the change that would move it. "Third, 120 points behind, until we test the upload service" starts a better conversation than "third."

An order isn't a plan. Check it against capacity with the product roadmap template, then spec the top item with the PRD template. To start faster, open this template in River and paste in the backlog you already have.