Backlog prioritisation: RICE, MoSCoW and other methods

Prioritising a backlog means deciding what to do first based on business value, cost and risk, not on who shouts loudest. Methods like RICE, MoSCoW and the value-effort matrix do not make the decision for you, but they force you to name your criteria and compare tasks on one scale. For a small team, one simple method applied regularly is usually enough.

Here are the popular methods, when each fits and how to keep prioritisation from turning into bureaucracy.

Why do you need backlog prioritisation?

You need prioritisation because there are always more ideas and requests than the team can build, and development time is the product's most expensive resource. Without explicit rules, the work that gets done is whatever the boss suggested, the most persistent client asked for or a developer found interesting.

Signs that prioritisation is not working:

• the team keeps switching between urgent tasks;
• important improvements sit at the bottom of the list for months;
• nobody can explain why task A comes before task B;
• releases ship but product metrics do not move.

How does the RICE method work?

RICE is a formula that scores a task on four factors: Reach, Impact, Confidence and Effort. The score is reach × impact × confidence divided by effort. The method was created at Intercom, and its strength is comparing very different tasks on one scale.

Factor	What it measures	How to measure it
Reach	How many users the change affects in a period	Users or events per quarter
Impact	How strongly it affects each user	Scale: 3 massive, 2 high, 1 medium, 0.5 low, 0.25 minimal
Confidence	How sure you are of your estimates	100% data-backed, 80% some evidence, 50% a guess
Effort	How much work it takes	Person-weeks or person-months

Task: reduce checkout to a single screen
  Reach      = 4,000 buyers per quarter
  Impact     = 2 (high impact on conversion)
  Confidence = 80% (analytics data on abandoned carts)
  Effort     = 3 person-weeks
  RICE = 4,000 × 2 × 0.8 / 3 ≈ 2,133

The score itself is not the truth. Its value is that the estimates are visible and can be challenged: "why is reach 4,000 if only 2,000 people check out?"

When does MoSCoW fit?

MoSCoW fits when you need to agree quickly on the scope of a specific release or a fixed-deadline stage. Tasks go into four groups: Must have — the release is pointless without it; Should have — important but the release can ship without it; Could have — nice if time allows; Won't have — definitely not this time.

How to apply it:

1. Agree on the release goal first — without one, everything ends up as Must have.
2. Test each Must with "would we ship the release without it?" If yes, it is a Should.
3. Keep Must haves to roughly half of the team's capacity; the rest is buffer.
4. The Won't have list matters as much as the Must have list: it sets expectations early.

This method is especially useful for defining an MVP — as during discovery, when launch essentials are separated from version two.

Photo: Unsplash

Which other methods are worth knowing?

Besides RICE and MoSCoW, the value-effort matrix, the Kano model and cost of delay are useful. They answer different questions, so pick the one that fits your situation.

The value-effort matrix

Tasks go into quadrants along two axes: value and effort. Do valuable, cheap tasks first, then valuable, expensive ones; cheap low-value tasks only when there is slack; drop expensive low-value ones. It is quick and works well in short planning meetings.

The Kano model

The Kano model classifies features by their effect on satisfaction: basic — their absence annoys but their presence does not delight; performance — the more, the better; delighters — unexpected and memorable. It helps when designing a product, so you neither forget the basics nor drown in "wow" features.

Cost of delay

This approach estimates how much the business loses for every week a task is not done and divides it by the task's duration. It suits time-bound work: seasonal sales, legal requirements, a supplier contract ending.

How do you build prioritisation into the team's routine?

Build prioritisation in as a short regular ritual, not a one-off exercise: every week or two the product owner reviews the top of the backlog with the tech lead. One person should make the final call, and the team should understand the criteria.

What helps:

• a single backlog owner who makes the final decision;
• effort estimates from developers, not from whoever proposes the task;
• prioritising only the top of the list — the next month's work;
• every task framed as a problem with an expected outcome;
• comparing expected and actual impact after release, so estimates improve.

Technical work — upgrades, refactoring, security — is a category of its own. Unless it is called out explicitly, it always loses to product work. We usually reserve a fixed share of the team's time for it.

In short

• Prioritisation compares tasks by value, cost and risk, not by how loudly they are requested.
• RICE is good for comparing very different tasks; MoSCoW for scoping a fixed-deadline release.
• The value-effort matrix, the Kano model and cost of delay each answer their own questions.
• Review the top of the backlog regularly, with one product owner making the call.
• Reserve time for technical work, or it will always lose to product work.