Feature Prioritization Frameworks: RICE, MoSCoW, Kano

A feature prioritization framework is an agreed way of ranking features so that the order comes from reasons you can write down rather than from whoever asked loudest. The four most used answer different questions. RICE ranks a long list by estimated value per unit of effort. MoSCoW sorts a fixed scope into what must, should and could ship by a deadline. Kano sorts features by how customers react to having them or not. WSJF ranks by the cost of waiting. Pick the one whose question matches your problem, use it the same way every time, and record that choice where the whole team, and any AI assistant working with you, can read it.

This post is about ranking product features. For ranking your own week of work, how to prioritize tasks at work covers the personal version, including impact vs effort.

What a framework is for

No framework tells you what to build. It does three smaller things. It forces the same questions to be asked of every feature, so a pet idea gets the same scrutiny as a customer request. It turns a disagreement about conclusions into a disagreement about inputs, which is easier to settle: two people can argue for an hour about whether the export matters, or for five minutes about whether it reaches 200 customers a month or 2,000. And it leaves a record of why the order is what it is.

The input that matters most is what users actually need. The US Digital Service’s Digital Services Playbook↗ (opens in a new tab) puts that first: its opening play ends with creating “a prioritized list of tasks the user is trying to accomplish.” A framework applied to guesses produces confident-looking guesses.

RICE: value per unit of effort

RICE scores each feature on Reach, Impact, Confidence and Effort, then divides the first three multiplied together by the fourth. Sean McBride introduced it on Intercom’s blog↗ (opens in a new tab), with a fixed impact scale from 3 for massive down to 0.25 for minimal, confidence as a percentage, and effort in person-months. The result is “total impact per time worked.”

Use it when you have a long list of independent features and need a defensible order. Its weakness is that it looks more precise than its inputs. The formula, a worked example and a spreadsheet layout are in RICE prioritization.

MoSCoW: what fits in a fixed scope

MoSCoW sorts requirements into Must have, Should have, Could have and Won’t have this time. It comes from the DSDM method, and the Agile Business Consortium’s MoSCoW guidance↗ (opens in a new tab) defines the Musts as the “Minimum Usable SubseT” the project guarantees to deliver. It recommends keeping Must effort to “no more than 60%” so the Shoulds and Coulds absorb surprises.

Use it when the date is fixed and the scope is what moves: a launch, a contract, a conference demo. It does not rank features within a bucket, and without the 60 percent discipline everything drifts into Must. The Won’t list is its most underrated part, because it records what was explicitly left out.

Kano: how customers react

The Kano model classifies features by the effect they have on satisfaction. It comes from a 1984 paper by Noriaki Kano and colleagues, “Attractive Quality and Must-Be Quality”↗ (opens in a new tab), which argued that quality should be seen in two dimensions rather than one. The categories most teams use:

• Must-be: customers expect it and are unhappy without it, but having it earns no praise. Password reset, a working export.
• One-dimensional (often called performance): the more and better, the happier people are. Speed, capacity.
• Attractive (often called delighters): nobody asked, and people are pleased when it appears.
• Indifferent: customers do not care either way. A candidate to drop.

Kano is usually run as a survey that asks each respondent two questions per feature: how they would feel if it were there, and how they would feel if it were not. Use it when you are deciding the shape of a product or a release, not the order of a backlog. It tells you which features are table stakes, which is exactly the kind of feature a RICE score tends to undervalue.

WSJF: the cost of waiting

Weighted Shortest Job First ranks work by cost of delay divided by size. In the Scaled Agile Framework’s description of WSJF↗ (opens in a new tab), cost of delay is built from relative user and business value, time criticality, and risk reduction or opportunity enablement, and each is scored relative to the other items rather than in absolute units. Use it when timing matters as much as value: a regulatory change, a partner deadline, a feature a competitor is about to ship. For a small team outside SAFe, the idea travels well even if the full scoring does not: ask what each week of delay costs.

Comparison at a glance

Framework  Question it answers              Output             Best for
---------  -------------------------------  -----------------  ---------------------------
RICE       Most value per unit of effort?   A ranked number    Long lists, independent items
MoSCoW     What fits before the deadline?   Four buckets       Fixed date, flexible scope
Kano       How will customers react?        Five categories    Shaping a product or release
WSJF       What costs most to delay?        A ranked number    Time-sensitive work

How to choose one

1. Name the decision. “What goes in the June release?” is a MoSCoW question. “What do we build next, out of forty ideas?” is a RICE or WSJF question. “Which of these would customers miss?” is a Kano question.
2. Check your data. RICE needs a reach number you can defend; Kano needs customers willing to answer a survey. If you have neither, a plain value-vs-effort sort is more honest than a formula.
3. Pick one primary framework. Two frameworks used side by side invite people to quote whichever one supports their idea.
4. Allow named exceptions. McBride writes that RICE scores “shouldn’t be used as a hard and fast rule,” and lists dependencies and table-stakes features as reasons to override. Write each override down with its reason.
5. Review the choice after a quarter. If the ranked order and the order you actually shipped keep disagreeing, the framework is not the one you use.

Templates to copy

Release: <name>   Date: <fixed date>   Capacity: <person-weeks>
Musts must stay under 60% of capacity.

MUST (without these, the release does not ship)
- <feature>  effort: <weeks>
SHOULD (painful to leave out, still viable)
- <feature>  effort: <weeks>
COULD (first to go if time runs short)
- <feature>  effort: <weeks>
WON'T THIS TIME (agreed, with the reason)
- <feature>  reason: <one line>

Must effort: <sum> of <capacity> = <percent>

Feature: <one plain sentence a customer would understand>

1. If the product had this, how would you feel?
2. If the product did not have this, how would you feel?

Answers for both: I like it / I expect it / I'm neutral /
I can live with it / I dislike it

Like + dislike its absence       -> one-dimensional
Like + neutral or live with      -> attractive
Expect or neutral + dislike      -> must-be
Neutral + neutral                -> indifferent

The Kano mapping above is a simplified version of the full evaluation table; for a first pass on a dozen features it is enough to separate table stakes from delighters. For RICE, use the spreadsheet in the RICE prioritization post.

Recording the choice on a fenbs board

The framework is a decision, and it gets forgotten like any other. On fenbs it belongs on the Decisions and rules page as a rule: a decision that holds from now on, with who decided, the day, the reason and the options you considered. A person is always the decider. Every AI assistant connected to the board reads the rules first, so an assistant asked to “suggest a priority for this request” uses your framework rather than inventing one.

Rule: Features and enhancements are ranked by RICE score.
Reach is per quarter; effort is in person-weeks.
Must-be features (Kano) and legal deadlines may override
the score; the override and its reason go in a comment.
Decided by: <product lead>. Options considered: MoSCoW, WSJF.

• Each feature is a task of kind feature, enhancement or bug. The note holds the problem and the evidence; the score and its inputs go in a comment, so a changed estimate leaves a trail.
• The ranking becomes the task’s priority, 1 to 10, where 1 is the most urgent. Map the top of your ranked list to P1 and P2 and let the rest fall into bands.
• Size, XS to XL, is an optional field on each task. It is a rough stand-in for effort, not a person-month estimate.
• History records who changed a priority, so a feature that jumped from P6 to P1 overnight shows who moved it.

What fenbs does not do: it has no score field, no formula and no custom fields, so the arithmetic lives in your spreadsheet and the result lives in the priority. It also has no due dates, so MoSCoW’s fixed date sits in the release’s note, not on a calendar.