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 toolMoSCoW 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
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. |
The PM proposes a first pass: every item into Must, Should, Could, or Won't. A draft to react to beats a blank page.
The hardest and most valuable step. Challenge every “Must”: would the release genuinely fail without it? Most “Musts” are really “Shoulds” in disguise.
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.
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.
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 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 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 |
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.
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.
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.
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.