What is the RICE framework?
RICE is a prioritization framework for comparing proposed work. Its four inputs are Reach, Impact, Confidence, and Effort. Sean McBride described the approach at Intercom. The formula is (Reach × Impact × Confidence) ÷ Effort. A higher score represents more estimated impact per unit of effort under the assumptions entered.
The score is a decision aid. It does not establish that a feature is valuable, that its estimates are accurate, or that the highest number should always ship first. A broken permission boundary or a prerequisite can require action regardless of its relative score.
This guide uses an original fictional backlog for InviteDesk, an invitation-management SaaS. The numbers are illustrative estimates, not observed customer results or ShowMeYourSaaS planning data. The downloadable lab lets you reproduce the arithmetic and explore how uncertainty changes the recommendation.
Download the inputs and local scoring lab
Download both files into the same folder. The CSV contains four example initiatives and the assumptions behind them. The JavaScript module contains the same baseline inputs and a sensitivity scenario. Read it in a text editor, then run node rice-scoring-lab.mjs with Node.js 22 or later to print the example scores.
The script makes no network requests and writes no files. It calculates its embedded examples; changing the CSV alone does not change the script. Edit the embedded inputs or import the exported scoreRice and rankRice functions into your own code. The CSV is an editable planning record, not a spreadsheet with automatic formulas.
Keep the evidence note beside each estimate when adapting the files. A number without its population, period, and reasoning is difficult for the next reviewer to challenge constructively.
Make the four inputs comparable
Reach counts the people or accounts expected to encounter the change during a fixed period. Pick one unit and one time window for the comparison. Here it means distinct active workspaces in the next 30 days. Counting individual invitation recipients for one feature and paying workspaces for another would distort the ranking.
Impact estimates the change for each reached unit. Intercom's original scale uses 3 for massive impact, 2 for high, 1 for medium, 0.5 for low, and 0.25 for minimal. This example uses that scale as a discussion convention. Explain the expected behavior behind the label rather than presenting the label as measured precision.
Confidence adjusts for the strength of the estimate. The lab uses a fraction from 0 to 1: enter 0.8 for 80%, not 80. Agree how evidence affects confidence before scoring. A frequent request can establish interest while leaving adoption and implementation effort uncertain.
Effort includes the work needed across the people involved. Intercom describes person-months; this example deliberately uses person-days for all four initiatives. That changes the numerical scale. Do not compare these raw scores with a backlog using person-months without converting every effort input.
Work through the fictional SaaS backlog
Suppose the team is comparing four ways to reduce invitation friction. The example estimates reach over the same 30 days, uses the same impact scale, and includes implementation, verification, and support preparation in effort. These are assumptions to review, not a forecast of revenue.
The expiry explanation scores 24: (120 × 1 × 0.8) ÷ 4. The resend status view scores 18: (90 × 2 × 0.6) ÷ 6. A bulk invitation import scores 12, and a reminder preference scores 10.8. Under these inputs, the expiry explanation is the strongest candidate for further planning.
That result does not imply four initiatives form an executable schedule. Check dependencies and available skills separately. For example, the status view might depend on reliable event records that its effort estimate has omitted.
| Initiative | Reach | Impact | Confidence | Effort | Score |
|---|---|---|---|---|---|
| Expiry explanation | 120 | 1 | 0.8 | 4 | 24 |
| Resend status view | 90 | 2 | 0.6 | 6 | 18 |
| Bulk invitation import | 40 | 3 | 0.5 | 5 | 12 |
| Reminder preference | 180 | 0.5 | 0.6 | 5 | 10.8 |
Test whether the ranking survives uncertainty
Change one questionable assumption before making the commitment. If the expiry explanation needs eight person-days rather than four, its score falls from 24 to 12. The resend status view then leads at 18. The lab prints this scenario as well as the baseline, making the dependency on effort visible.
Next ask what evidence could resolve the disagreement cheaply. A short implementation investigation might reveal that the explanation requires a new eligibility API. A small usability session might show that the problem is unclear permissions rather than unclear expiry. Either finding could change the proposal itself.
Do not average competing guesses merely to finish the meeting. Record the range, its reason, an owner for the next investigation, and the decision it could change. If plausible inputs repeatedly reverse the order, treat the apparent winner as uncertain rather than decorating its score with extra decimal places.
Handle missing inputs and mandatory work explicitly
Zero reach is a valid input and produces a zero score. Missing reach is unknown and should not silently become zero. The lab rejects absent, nonnumeric, negative, or non-finite inputs; effort must be greater than zero, and confidence must fall between 0 and 1. It also rejects duplicate initiative IDs and mixed period or population labels in a ranking.
An impact scale is still a model choice. The script accepts a nonnegative numerical impact, so a team can adapt its scale, but every initiative in a comparison needs the same agreed meaning. The arithmetic cannot detect that one reviewer used a different mental definition of high impact.
Keep mandatory fixes and prerequisites visible beside the ranked candidates. Write why a commitment overrides the score and what capacity it consumes. Hiding necessary work inside an artificially high impact number makes later reviews less informative.
Use RICE after collecting evidence
The feedback prioritization guide covers turning scattered requests into evidence about a problem. RICE comes after that synthesis: compare candidate responses with explicit assumptions. It cannot make an untested solution useful by assigning it a score.
Move the selected proposal into a product requirements document with observable behavior, scope, and acceptance criteria. Keep the scoring record as a dated explanation of why the team chose to investigate or commit, rather than using it as a permanent promise to customers.
Revisit the comparison when reach changes, evidence improves, or effort becomes clearer. Record actual learning without rewriting the original estimate to look accurate. The lab was checked against the baseline arithmetic, the sensitivity scenario, invalid inputs, mixed populations, duplicate IDs, zero reach, and stable ties. Framework source checked October 27, 2026.