Prioritizing Requirements: MoSCoW, Kano, and Saying No
A requirement tells you what to build. A priority tells you what to build first — and, just as importantly, what not to build at all. A specification with requirements but no priorities is not a plan; it is a wish list, and the team will end up building whatever is loudest, not whatever matters.
Two tools do most of the work: MoSCoW for the commitment, and Kano for the value judgment.
Why prioritize at all
Resources are finite and deadlines are real. An unprioritized list hides the trade-off instead of making it. When the schedule slips, someone will have to decide what to cut — and if the decision was never made, it will be made under pressure, badly.
Prioritization is not bureaucracy. It is the requirement decision you make so that the eventual cut is deliberate instead of accidental.
MoSCoW: the commitment
The discipline is the fourth bucket. Writing something as "Won’t have" is what prevents scope creep — because a feature that was never excluded quietly becomes expected.
- Must have — non-negotiable. The release fails without it; if it is at risk, the schedule moves.
- Should have — important but not vital. It hurts to leave it out, but the release can survive without it.
- Could have — nice to have. Small value; included only if everything else is done.
- Won’t have (this time) — explicitly out of scope. Not "never", just "not now".
Kano: the value judgment
Kano’s model sorts features by how they affect satisfaction, which is a better guide to value than "we think users want it".
- Basic (must-be) — expected. Its absence causes strong dissatisfaction; its presence adds no delight. You must ship these, but they never win you customers.
- Performance — the more, the better. Satisfaction rises in proportion to how well it is fulfilled. This is where speed, capacity, and polish live.
- Attractive (delighters) — unexpected. Their presence delights; their absence causes no dissatisfaction. These are what people tell their friends about.
- Indifferent — nobody notices either way. Candidates for the cut list.
- Reverse — their presence actually causes dissatisfaction. Know these so you do not build them.
The "won’t do" list is a decision too
The most underrated output of prioritization is the list of things you are deliberately not building. It sets expectations, protects the schedule, and gives the team permission to stop gold-plating. A requirements document with no exclusions is a document that will grow forever.
Saying "not now" is not failing to plan — it is the plan.
Putting them together
Use Kano first, to understand value: separate the basics (you must ship them) from the performance features (ship the highest-value ones) from the delighters (ship one, it is cheap and memorable). Then use MoSCoW to commit: basics are Must-haves, high-value performance features are Should-haves, low-value ones are Could-haves, and everything else is a Won’t-have — recorded, not forgotten.
The result is a specification that says not just what the system is, but what the team is actually going to do, in what order, and what it has consciously left out.