What is the MoSCoW method — and the mistake that makes it useless.
Short answer
MoSCoW is a prioritization framework that sorts requirements or features into four categories: Must have (critical for launch), Should have (important but not launch-blocking), Could have (nice to have if time allows), Won't have (explicitly out of scope for this release). Developed by Dai Clegg at Oracle in the 1990s, it's widely used in agile projects, product launches, and workshop facilitation.
MoSCoW stands for Must have, Should have, Could have, Won't have. The vowels were added to make it pronounceable. It was developed by Dai Clegg while working at Oracle and first published in 1994 in a Dynamic Systems Development Method (DSDM) white paper.
What each category means.
Must have — the non-negotiables. Without these, the release fails or the product is unsafe/unusable. Must haves should be as small as possible — if everything is Must have, you've made no decisions. A good test: would the project be cancelled without this? If yes, it's a Must. If it would still ship (just worse), it's probably a Should.
Should have — important, high-value, but deliverable via workaround if necessary. These are done if time allows and are typically the first items promoted to Must if Must haves complete early.
Could have — nice to have. Relatively small effort for modest value. These are cut first if the schedule is tight. Good for building a quality buffer into planning — if all Coulds get done, the release is stronger than the baseline; if none do, the baseline is still acceptable.
Won't have (this time) — explicitly out of scope for this release. Not necessarily forever — "Won't have this release" is more useful than "Won't have ever." This category is valuable because it gives stakeholders who asked for these items a documented answer without reopening the conversation every sprint.
The common mistake. Over-classifying things as Must have. When 70% of the backlog is Must, the framework has failed — it's a prioritization tool, not a scope-negotiation tool. A well-applied MoSCoW should have Must ≤ 50% of the total scope, Should at 20–30%, Could at 20–30%, and Won't at whatever remains.
Running a MoSCoW session.
- List all requirements or features — one per sticky note.
- Draw four columns on the whiteboard.
- Silent placement: each participant places stickies in the column they think is right.
- Discuss all disagreements. The Decider has final say on Must/Should disputes.
- Review the Must column: does this represent a shippable, valuable release? If not, promote some Shoulds.
Snap the MoSCoW board with BoardSnap. The AI reads the four columns and produces a structured requirement list with priorities and counts per category.
Frequently asked
When should you use MoSCoW instead of RICE or Kano?
MoSCoW is best for scope negotiation with stakeholders — it produces a shared, documented agreement about what's in and out of a specific release. RICE is better for internal backlog prioritization where you're choosing order, not scope boundaries. Kano is better for understanding customer delight versus dissatisfaction thresholds. Use MoSCoW at kickoff; use RICE for sprint-level ordering.
Does 'Won't have' mean the feature will never be built?
Not necessarily. The full phrase is "Won't have this time." Many items categorized as Won't are high-value features scheduled for a future release. The category communicates that the current release will not include them, which prevents scope creep without permanently killing the idea.
Who created the MoSCoW method?
Dai Clegg, while working at Oracle UK, developed MoSCoW for use in the Dynamic Systems Development Method (DSDM) framework in the early 1990s. It was published in a DSDM white paper in 1994 and has been widely adopted in Agile and project management since.
See it work in ten seconds.
BoardSnap is free on the App Store. Snap a board — get a summary and action plan.