What is MoSCoW prioritization?
Short answer
MoSCoW is a prioritization method that sorts work into four groups for a given release or deadline: Must have, Should have, Could have, and Won't have this time. Musts are non-negotiable for the release to be viable, Shoulds are important but can slip, Coulds are nice extras, and Won'ts are explicitly out. It makes the trade-off visible when time is fixed and scope has to give.
Last updated 19 October 2026. Written by the Kaneo team, who also build one of the tools mentioned.
The four categories
Must have
Without it the release fails: it is illegal, unsafe, unusable, or breaks the core promise. A good test is whether you would cancel the release if it were missing.
Should have
Important and expected, but there is a workaround or it can follow shortly after. Painful to drop, not fatal.
Could have
Valuable if there is time, small impact if there is not. These are the first to go when the schedule slips.
Won't have (this time)
Agreed to be out of this release. Writing them down stops the same requests from returning every week and records them for later.
A worked example: a mobile app's first release
| Item | Category | Why |
|---|---|---|
| Sign in and sign out | Must | The app is unusable without it |
| View and complete tasks | Must | The core reason anyone installs it |
| Push notifications for mentions | Should | Expected, but email covers it for now |
| Offline mode | Should | Important for some users; can ship in the next update |
| Dark mode | Could | Nice to have, no effect on the core job |
| Home screen widgets | Could | Small audience, more effort than it looks |
| Tablet layout | Won't | Planned for a later release |
Rules that keep MoSCoW honest
Cap the Musts
A common guideline is that Musts take no more than about 60% of the available effort, with Shoulds around 20% and Coulds the rest. That leaves room for estimates to be wrong without missing the date.
Tie it to a date
MoSCoW only works for a specific release or time box. Without one, everything drifts towards Must.
Challenge every Must
Ask what would happen if it were missing on launch day. If the answer is "people would be disappointed", it is a Should.
Decide who settles disputes
Agree in advance who makes the final call when stakeholders disagree on a category, usually the product owner.
MoSCoW compared with other methods
MoSCoW is coarse on purpose: it answers what is in and out, not the exact order. Within each group you still need a ranking. RICE and weighted scoring give finer numbers but are harder to explain to stakeholders, while the Eisenhower matrix suits personal work better than release scope.
The method was created by Dai Clegg at Oracle in 1994 and later became part of the Dynamic Systems Development Method (DSDM). The lower-case o letters are only there to make the acronym pronounceable.
MoSCoW in Kaneo
Create four labels, Must, Should, Could, and Won't, or a dropdown custom field with those values, and tag each item in the release. Filter the backlog or board by the field to see each group, and by Must alone when checking whether the release is on track.
Use Kaneo's priority field for the order within a group. Items marked Won't can stay in the backlog, so they are there for the next release without cluttering the board.
Frequently asked
What does MoSCoW stand for?
Must have, Should have, Could have, and Won't have (this time). The o letters are added to make it readable.
What is the difference between Must and Should?
A Must is required for the release to work at all. A Should is important but has a workaround or can follow soon after without the release failing.
Is MoSCoW agile?
It comes from DSDM, an agile framework, and works well in any time-boxed delivery: sprints, releases, or fixed-date projects.
What are the disadvantages of MoSCoW?
It does not rank items within a category, and without discipline stakeholders push everything into Must. A cap on the Must effort and a clear decision-maker address both.