The MoSCoW Method
Sort every piece of work into Must, Should, Could, and Won't — so the team agrees on what's non-negotiable before engineering starts, not during crunch.
▸ Try the interactive toolThe framework
MoSCoW is a categorical prioritisation method used in sprint planning, release scoping, and stakeholder negotiation. It sorts every proposed piece of work into four buckets — Must have, Should have, Could have, and Won't have (this time) — creating explicit, documented agreement on what's non-negotiable before engineering begins.
Where RICE ranks on a continuous scale, MoSCoW draws hard lines. Its value is the forced conversation about the Must/Should boundary and, crucially, the explicit Won't list — naming what you're consciously not doing this time is what prevents scope creep and the silent re-addition of cut work.
Must have — release fails without it · Should have — important but not vital · Could have — nice if time allows · Won't have (this time) — explicitly out of scope, by agreement
Try it yourself
What it prevents
Most scope disasters come from never agreeing what was truly required. MoSCoW makes that agreement explicit and written, before the pressure hits.
| The shortcut | What it costs | What it gives you instead |
|---|---|---|
| Everything is a “must” | If all work is required, nothing is prioritised and the release bloats. | The Must/Should debate forces honesty about what's truly non-negotiable. |
| Silent scope creep | Cut items quietly reappear mid-sprint. | A named Won't list makes re-adding work a visible, deliberate decision. |
| Stakeholder ambush | “I assumed that was included” surfaces at launch. | Documented buckets are a shared contract everyone agreed to up front. |
| Crunch-time chaos | When time runs short, the team cuts in a panic. | Could and Should are pre-agreed cut order — the panic decision was already made calmly. |
Step by step
Draft an initial bucket assignment
The PM proposes a first pass: every item into Must, Should, Could, or Won't. A draft to react to beats a blank page.
Debate the Must/Should boundary
The hardest and most valuable step. Challenge every “Must”: would the release genuinely fail without it? Most “Musts” are really “Shoulds” in disguise.
Name the Won't list with stakeholders
Explicitly agree what's out of scope this time — and get stakeholders to acknowledge it. This is the step teams skip and the one that prevents the most pain.
Check the Must list fits the timebox
Add up the Musts. If they don't fit the sprint or release, you haven't finished prioritising — something labelled Must is actually a Should.
Treat the buckets as a cut order
If time runs short, Coulds go first, then Shoulds. Musts are protected. The order was agreed calmly, so the cut isn't a fight.
A short illustration
A team heading into a release had a backlog where every item was marked “critical.” Running MoSCoW, the Must/Should debate revealed that of fourteen “critical” items, only five would actually break the release if missing.
More importantly, they wrote a Won't list — three features stakeholders had assumed were coming. Surfacing that in the planning room, not at launch, turned a future ambush into a five-minute alignment.
The agreed scope contract
The deliverable is a four-bucket list everyone signed off — read as a contract and a pre-agreed cut order.
| Bucket | The test | Behaviour under time pressure |
|---|---|---|
| Must | Release fails without it | Protected — never cut |
| Should | Important, not vital | Cut second, reluctantly |
| Could | Nice to have | Cut first, without drama |
| Won't (this time) | Out of scope, agreed | Stays out — re-adding is a visible decision |
Why it matters
The Won't list is the part that does the work. Naming what you're not doing — and getting stakeholders to agree — is what stops scope creep and the slow re-addition of cut work.
MoSCoW's discipline is refusing to let “Must” inflate. In practice almost everything wants to be a Must, because no one wants their item cut. The facilitator's job is to keep asking “would the release genuinely fail without this?” until the Must list is short enough to be true — and to make sure the Won't list isn't empty, because an empty Won't list means nothing was really prioritised.
Common mistakes
An inflated Must list isn't prioritisation. Interrogate each one: would the release truly fail without it?
If you're not consciously not-doing anything, you haven't drawn a real boundary. Name the cuts.
Buckets the team agreed but stakeholders never saw become an ambush at launch. Get explicit acknowledgement.
“Won't have this time” is not “never.” Keep the door open for a future release so the conversation stays honest.
When not to use it
- You need a fine-grained ranking. MoSCoW buckets but doesn't order within a bucket — use RICE when you need a precise sequence.
- Continuous flow, no release boundary. MoSCoW is scoped to a timebox; for a steady Kanban flow, a ranked backlog fits better.
- Solo, low-stakes decisions. The ceremony pays off when multiple stakeholders must agree; alone on a small call, it's overhead.
Where this sits in the toolkit
RICE ranks the candidates; MoSCoW draws the Must/Should line for a specific release. Rank first, then bucket.
The Must list becomes the committed sprint scope; the agreed cut order de-risks delivery.
MoSCoW is as much a stakeholder-alignment tool as a prioritisation one — the Won't list is a negotiation made explicit.
What counts as a “Must” should trace to a strategic bet — the MVSR ladder is the upstream filter.
MoSCoW your current sprint
Take your current or next sprint's work and force every item into Must, Should, Could, or Won't. Be strict on Must: would the release actually fail without it?
Then write at least one item on the Won't list — something real you're choosing not to do.
If you couldn't move most items off “Must,” or couldn't name a single “Won't,” you've found exactly why the team feels overloaded.
New tools and AI deep-dives, occasionally.
No spam. Unsubscribe anytime.