Prioritise to Execute — RICE Framework

You have 14 initiatives on the roadmap, 3 engineers, and a quarter that started last week. Everything is urgent. Everything is important. Nothing is moving.

This is not a planning problem. It's a prioritisation problem. And the only way to solve it is with a framework that forces you to compare initiatives on the same scale — objectively, repeatedly, without politics.

RICE is that framework.

The Formula

RICE was developed by Intercom to score product features, but it works for any initiative where you need to decide what to do first. The formula is simple:

Each component answers a different question. Together, they produce a single number that lets you rank every initiative on your backlog against every other one.

The Four Components

Reach

How many people will this affect in a given time period?

Reach is a raw number. Not a percentage, not a feeling — a count. How many customers, users, transactions, or leads will this initiative touch per quarter?

Reach prevents you from over-investing in features that delight 50 people while ignoring improvements that affect 50,000.

Impact

How much will this move the needle for each person it reaches?

Impact is scored on a fixed scale. The standard scale is:

Score	Label	Meaning
3	Massive	Fundamentally changes the experience or outcome
2	High	Significant improvement that users will notice immediately
1	Medium	Meaningful but not transformative
0.5	Low	Minor improvement, nice to have
0.25	Minimal	Barely noticeable change

The fixed scale is important. Without it, every team lead will argue their initiative is "high impact" and you're back to politics.

Confidence

How sure are you about these estimates?

Confidence is a percentage that discounts your score based on how much evidence you have. It's the honesty multiplier.

Score	Label	Evidence
100%	High	Strong data: A/B test results, validated research, historical metrics
80%	Medium	Some data: user interviews, competitive analysis, directional analytics
50%	Low	Gut feel, anecdotal feedback, untested assumptions

Confidence is what separates RICE from a simple "Reach × Impact" calculation. It penalises initiatives that sound great on paper but are based on wishful thinking. If your confidence is 50%, the score gets halved — which is exactly what should happen when you're guessing.

Effort

How much work will this take?

Effort is measured in person-months (or person-weeks for smaller teams). It includes design, engineering, QA, launch — everything needed to ship.

Effort is the denominator. High-effort initiatives need proportionally higher Reach, Impact, and Confidence to justify their cost. This is the mechanism that kills vanity projects.

A Worked Example

Suppose you're deciding between three initiatives for Q3:

Initiative	Reach	Impact	Confidence	Effort	RICE
Redesign onboarding flow	8,000	2	80%	3	4,267
Build enterprise dashboard	200	3	100%	6	100
Add CSV export	5,000	1	100%	0.5	10,000

The enterprise dashboard — the one that felt most important in the meeting — scores lowest. It reaches only 200 users and costs 6 person-months. The CSV export, which nobody was excited about, scores highest because it's a quick win that touches 5,000 users with high confidence.

This is RICE working as intended. It doesn't tell you the dashboard is a bad idea. It tells you to ship the CSV export first, then the onboarding redesign, then the dashboard.

When RICE Works Best

RICE is at its strongest when:

• You have more ideas than capacity — which is always
• Multiple stakeholders disagree on priorities — RICE gives you a shared language and a number to debate, not opinions
• You need to justify trade-offs — "We scored this at 4,200 vs 900" is a better answer than "We just felt it was more important"
• You're planning quarterly roadmaps — score everything, sort by RICE, draw a line where capacity runs out

The value of RICE isn't the scores themselves. It's the conversation that happens when you disagree about a score.

When two people disagree on the Impact of an initiative, they're forced to articulate their assumptions. That conversation — grounded in Reach data and Effort estimates — is where real prioritisation happens.

When RICE Isn't Enough

RICE has blind spots. Knowing them prevents you from misapplying the framework.

The solution isn't to force these into RICE. It's to maintain separate tracks: a RICE-scored backlog for feature work, a tech debt budget, and a compliance lane. RICE governs one track, not all of them.

Making It Stick

The hardest part of RICE isn't the formula. It's the discipline to use it consistently.

1. Score everything in the same session. Scoring one initiative in isolation is useless. The value is in the relative ranking. Block 90 minutes with your leads and score the entire backlog together.
2. Re-score every quarter. Reach changes. Effort estimates improve. Confidence shifts as you learn more. Stale scores lead to stale roadmaps.
3. Make scores visible. Put the RICE scores in your project tracker, your roadmap document, your sprint planning board. When someone asks "why are we doing X before Y?", the answer should be one click away.
4. Protect the framework from politics. The moment you override a RICE score because a senior stakeholder "just feels strongly" about something, the framework loses credibility. If the score is wrong, challenge the inputs — don't bypass the system.
5. Start imperfect. Your first round of estimates will be rough. That's fine. RICE gets more accurate as your team develops a shared calibration for what "Impact: 2" or "Effort: 3" actually means.

RICE in Practice: A TPM's Sprint Workflow

Theory is easy. Here's how RICE actually fits into a sprint cadence when you're triaging hundreds of incoming requests.

As a Technical Program Manager managing a reporting tools backlog with 100+ customer feature requests per quarter, I set aside 60 minutes every sprint, 4 days before the sprint ends, to score new and re-score existing tasks. That timing is deliberate — it gives engineers visibility into what's coming before the next sprint starts, so they can self-assign from the backlog based on RICE priority ahead of sprint planning.

This rhythm solves two problems at once. First, it prevents sprint planning from becoming a 90-minute debate about priorities — the RICE scores already settled that. Second, it gives engineers agency. When people pick their own work from a ranked list, they show up differently than when work is assigned to them.

The 60-minute scoring session is non-negotiable. Skip it once and you're back to gut-feel prioritisation by the loudest voice in the room.

Tools That Support RICE Scoring

RICE works in a spreadsheet, but it works better inside the tools your team already uses for roadmapping and backlog management. Most modern project management platforms support custom fields, which means you can add Reach, Impact, Confidence, and Effort columns and calculate the RICE score directly alongside your tasks.

Here are the platforms worth considering:

• Jira — The standard for engineering teams. Use custom fields for each RICE component and build a sorted backlog view by score. Works well with Confluence for documenting the scoring rationale alongside roadmap pages.
• Asana — Strong for cross-functional teams. Custom fields make RICE scoring straightforward, and portfolio views let you compare scores across multiple projects.
• Notion — Best for teams that want RICE scoring and documentation in one place. Database views with formula properties can auto-calculate scores, and you can link scoring tables directly to strategy docs.
• ClickUp — Has built-in priority frameworks and custom fields. The formula fields can calculate RICE scores automatically and surface them in list, board, or timeline views.
• Monday.com — Visual and accessible for non-technical stakeholders. Number columns for each RICE component with a formula column for the score make it easy for leadership to see and understand the ranking.
• Trello — Lightweight option for smaller teams. Use custom fields via the Power-Up, or simply add RICE scores to card titles and sort columns manually. Less structured, but lower friction to start.
• Linear — Built for speed. Custom properties and views make it fast to score and re-sort. Particularly strong for engineering-led teams that want minimal overhead.

The tool matters less than the habit. Pick whatever your team already opens every morning. The goal is to make RICE scores visible at the moment decisions get made — not buried in a spreadsheet that gets opened once a quarter.

Final Thought

Prioritisation isn't about saying yes to the right things. It's about saying no to everything else. RICE gives you the language and the evidence to do that without it feeling arbitrary.

Score your backlog. Sort by RICE. Draw the line. Ship what's above it.

Everything below the line isn't rejected — it's deferred, with a clear reason why. And next quarter, when the inputs change, you re-score and the line moves.

That's how you prioritise to execute.