MoSCoW and RICE: prioritisation for product managers

The fastest way to misuse either method is to reach for it at the wrong moment. They were built for different shapes of decision.

MoSCoW is a commitment scheme. It assumes a fixed timebox and a fixed team, and flexes the only remaining variable, scope. Every item is sorted into one of four commitment levels, and the point is the agreement, not the ranking: two Must-haves are not ordered against each other, they are both simply in.

RICE is a scoring model. It assumes a backlog with no deadline forcing a decision, and produces one number per candidate so they can be lined up. It says nothing about what a coherent release looks like.

Put crudely: MoSCoW tells you where the line is, RICE tells you what order things sit in above it. Neither tells you whether the work is worth doing at all, which belongs to whatever goal system sits above the backlog, usually OKRs and SMART goals.

The method was devised by Dai Clegg at Oracle in the mid-1990s, for rapid application development, and was then absorbed into DSDM, the Dynamic Systems Development Method, one of the frameworks that predated and fed into agile practice. It is still maintained by DSDM's successor, the Agile Business Consortium, which is why the canonical definitions live there rather than with any vendor. The two lowercase o characters exist only to make the acronym pronounceable.

The categories are not four shades of importance. Each is a different statement about what happens if the item is not delivered on the target date.

The workaround test is what makes the Should-have category usable. If a support agent can do the thing by hand for six weeks, it is a Should-have, however loudly it is requested. If there is genuinely no way to operate without it, it is a Must-have, however small it looks.

Won't have this time is the category teams skip, and the one doing the most work. An unwritten no comes back every planning session; a recorded "not in this release, revisit in Q4" ends the argument for the length of the timebox and gives the stakeholder something to plan around. It also makes the other three credible, since a scheme with no visible rejections is not prioritising. Keeping that list somewhere durable, with the reasoning, is the same discipline as a meeting decision log.

Sorting items into four buckets achieves nothing on its own. What turns MoSCoW into a planning tool is a constraint on how much of the timebox the Must-haves may consume. The Agile Business Consortium's guidance puts a ceiling on it: no more than 60% of the timebox's effort should sit in Must-haves. The remaining 40% goes to Should-haves and Could-haves, with the Could-haves (commonly around half of that remainder) acting as deliberate contingency. Won't-haves carry no estimate at all, so they never appear in the split.

The logic is straightforward. If Must-haves are 60% of the plan, the team can lose a third of the timebox to sickness, a bad estimate, or an unexpected dependency and still deliver something that works, by shedding Could-haves and then Should-haves. If Must-haves are 90% of the plan there is nothing to shed, and the first surprise becomes a missed date. The percentage is not a target to hit, it is a smoke alarm: a plan that cannot get under it has not been prioritised.

This is also why MoSCoW only works inside a fixed timebox. Take away the deadline and Must-have degenerates into a synonym for important, because nothing is being traded against anything, which is the same argument that makes timeboxing work at the scale of a single afternoon.

RICE was developed at Intercom and published on the company's blog, as a way to compare project ideas with nothing else in common: a bug fix, an integration, and a redesign do not sit on any natural scale together. Each candidate gets a score, best read as total impact per unit of effort. The formula is one line:

RICE score = (Reach × Impact × Confidence) / Effort

Each input means something specific, and the discipline is in the definitions rather than the arithmetic.

Two of these are routinely mishandled. Reach must use one unit across the whole list: mixing accounts for one feature and individual users for another makes the ranking arithmetic nonsense. And confidence is not enthusiasm, it is a discount for ignorance. Numbers from a dashboard and a completed experiment sit at 100%; numbers from one loud customer and a hunch sit at 50%, and halving that score is the point.

Four candidates for a B2B product's next quarter. Reach is the same unit throughout: customer accounts that would encounter the change in one quarter.

The arithmetic, in full:

• Bulk CSV import. 800 × 2 = 1,600. 1,600 × 0.8 = 1,280. 1,280 / 3 = 427. Discounted to 80% because the impact estimate came from support tickets rather than a test.
• Onboarding checklist rebuild. 1,200 × 1 = 1,200. 1,200 × 1.0 = 1,200. 1,200 / 4 = 300. Modest per-account effect, but it reaches every new account and the numbers come from a finished experiment.
• In-app notification centre. 2,000 × 0.5 = 1,000. 1,000 × 0.5 = 500. 500 / 5 = 100. The widest reach on the list and nearly the lowest score: low per-account impact, weak evidence, and five person-months compound against it.
• SAML single sign-on. 60 × 3 = 180. 180 × 1.0 = 180. 180 / 2 = 90. Cheap and certain, but it touches sixty accounts.

The ranking is CSV import, onboarding, notification centre, SSO. Three things about it matter more than the order itself.

The widest reach lost. The notification centre touches more accounts than anything else and finishes third, because reach multiplied by an impact of 0.5 is usually a smaller number than a narrow feature at 3. That is RICE working correctly, and it is the most common surprise for teams new to it.

One estimate flips the top two. Effort is the denominator, and effort estimates are the least reliable input on the sheet. If the CSV import turns out to be five person-months rather than three, its score falls to 1,280 / 5 = 256, below the onboarding rebuild's 300. A re-estimate any engineer would call within normal error reverses first and second place.

The bottom two are a tie. Ninety and one hundred are not a ranking. Either row could move 10% for reasons unrelated to merit, so treat scores within roughly 20% of each other as tied and decide between them on grounds RICE does not model.

SSO scored last, and on most B2B roadmaps it would still get built first. That is not a defect in the arithmetic, it is the boundary of the model.

RICE counts heads. Those sixty accounts might be the enterprise segment carrying most of the revenue, or SSO might be a procurement checkbox that blocks every deal above a certain size, in which case its real reach is not sixty existing accounts but every deal the sales team cannot currently close. Reach measured against today's user base is structurally blind to the users a feature would let you acquire, and equally blind to sequencing constraints, contractual obligations, and coherence: four unrelated top-scoring items can add up to a release with no story.

This is exactly where MoSCoW earns its place. SSO is a Must-have for the enterprise release and no score is going to argue with that. The two methods compose, with MoSCoW deciding membership and RICE deciding order within a category.

MoSCoW's characteristic failure is that everything becomes a Must-have, for a predictable reason: each stakeholder sees only their own item, and Should-have reads to them as a polite no. A backlog where 90% of the effort is Must carries no information, and has destroyed the contingency that made the timebox survivable. Four countermeasures, in increasing order of unpleasantness:

• Run the percentage. Add up the estimates. If Must-haves exceed 60% of the timebox, the classification is wrong by arithmetic, and that is a much easier conversation than an argument about who cares more.
• Ask the workaround question. Not "is this important" but "what do we do for six weeks if this is not there". If anyone can answer, it is a Should-have.
• Make Musts sponsored. Every Must-have needs a named person who will defend it and who owns the consequence of the release slipping for it. Anonymous Must-haves multiply, sponsored ones do not.
• Publish the Won't-have list. Inflation is partly a fear that unlisted things vanish. A visible, dated deferral list is what makes a Should-have feel like a plan rather than a brush-off.

RICE's characteristic failure is the opposite: a number that looks far more solid than the guesses it was built from. A score of 427 has three significant figures and perhaps one of them is earned. Once the number is in a spreadsheet the provenance of its inputs disappears, and a ranking resting on one person's estimate of impact acquires the authority of a measurement.

The model contains its own partial antidote, and teams skip it: confidence exists to discount weak inputs, so scoring everything at 100% removes the mechanism that keeps the rest honest. The other habits worth adopting:

• Round the output. Rank into bands rather than positions. Above 300 is a strong candidate, 100 to 300 is a maybe, below 100 needs a reason other than the score.
• Record where each input came from. A column saying "dashboard", "experiment", or "one customer call" next to each number costs nothing and is the first thing anyone should read.
• Test the denominator. Re-score with every effort estimate at 1.5×. The items that hold their position are the safe bets.
• Never compare across lists. A score is only meaningful against others produced by the same people, with the same reach unit, in the same session. There is no absolute RICE scale.

Both sit below strategy and above the working day. Which items reach the backlog at all is closer to the sort performed by the Eisenhower Matrix; what you personally do on Tuesday morning belongs to Ivy Lee and Eat the Frog. Neither of those scales up to a roadmap, and neither MoSCoW nor RICE scales down to a to-do list.