MoSCoW Method Without the Ranking Folklore
The MoSCoW method sorts a timeboxed release into Must, Should, Could, and Won't this time. ABC tests, the 60% effort cap, and where the four buckets collapse.
Updated 11 min read
The MoSCoW method sorts a timeboxed release into Must Have, Should Have, Could Have, and Won't Have this time. W is not Would. The Agile Business Consortium still publishes the bucket tests, including a cap of 60% Must effort.
Dai Clegg and Richard Barker documented the labels in 1994. RICE ranks a backlog; MoSCoW classifies scope for this release.
You run MoSCoW prioritization when the date is fixed and the feature list is not. Not the Russian capital. Not a 2x2 urgency matrix.
Key Takeaways
- MoSCoW is four buckets for a timeboxed release: Must, Should, Could, and Won't Have this time. The o's are padding.
- Must Have is the Minimum Usable SubseT. If a painful manual workaround exists, it is not a Must.
- Cap Must at 60% of effort, not 60 of 100 tickets. Could is about 20% of effort and the first thing you drop.
- Buckets beat a score when you need a scoping conversation. They collapse when everything is Must, the Won't column is empty, or you treat Must plus Should as the MVP.
- Pair the sort with a sequencer (RICE) and a delight map (the Kano model) after you know what is in this release.
What Is the MoSCoW Method?
The MoSCoW method is a prioritization technique that puts every in-scope item into one of four buckets for a stated timeframe. Must Have ships or you cancel.
Should Have hurts to skip, but the release is still viable. Could Have is wanted, and it is the contingency pool. Won't Have this time is agreed out of this box and kept on the list so it does not sneak back in.
ABC writes Must as Minimum Usable SubseT (MUST). That is a viability test.
Categorizing something as Should or Could does not mean you will skip it. It means delivery is not guaranteed if the date starts to slip.
Dai Clegg documented the buckets in CASE Method Fast-Track (with Richard Barker, Addison-Wesley, 1994, ISBN 978-0-201-62432-8) while at Oracle in the UK. Oracle does not own the method now.
The Agile Business Consortium, the not-for-profit steward of DSDM, still publishes the tests and the effort cap. The Consortium company was incorporated in 1995 as Dynamic Systems Development Method Limited and renamed on 5 October 2016.
How the MoSCoW Method Works
You name the timeframe first: this sprint, this increment, this release. Then you classify against that box, not against the product you hope to have in three years.
Nested Labels Across Timeboxes
One requirement can carry three labels at once: one for the project, one for the increment, and one for this timebox. ABC uses an archive facility as the example. It can be Must before the project ends, Should or Could in the first increment, and Won't in an early timebox.
At timebox planning, most items are Won't Have for this box. Only the work you actually plan gets Must, Should, or Could.
DSDM fixes time and cost, and flexes features. Flex scope inside the date. Do not treat Won't as a graveyard.
The Split Is Effort, Not Item Count
ABC's rule is a cap on estimated effort: typically no more than 60% Must, around 20% Could, Should filling the rest. Won't is excluded from the calculation.
Must effort above 60% raises the risk of missing the date unless estimates are already accurate and the environment is low-risk.
Filling 60 of 100 tickets as Must is not the handbook. Andrew Craddock is blunter: the 60/20/20 mix as a target is not the guidance.
"The handbook says no more than 60%, and if you only had 10%, fantastic." (Andrew Craddock, PMI UK, 26:11)
In one XP 2022 simulation, an 80% Must allocation dropped the chance of delivering every Must to 49.7% when estimates were as much as 50% low. Treat that as a warning about the cap, not as a planning spreadsheet.
Running the Session
Agree the objective criteria that separate Should from Could before you capture requirements. ABC treats the Must definition as not negotiable. Should versus Could is subjective unless you pre-agree the pain test.
Walk in with obvious Musts and obvious Won'ts on the table, then negotiate the middle with effort estimates visible. Review labels at the end of each timebox and each increment.
Coulds are the first items you descope when the date is at risk. Shoulds move only after Coulds are gone.
On r/ProductManagement, practitioners keep the method as a now / later / not-at-all ledger rather than a score.
"I like Moscow, but mostly as a way to ensure that things are accounted for and it is clearly communicated what part of a thing is being done now, later, and not at all." (u/HustlinInTheHall in r/ProductManagement, Oct 2025)
Types of MoSCoW Labels
Four labels. Same timeframe. Different tests.
Type | Best For | Key Characteristics |
|---|---|---|
Must Have | Viable subset this box | Cancel without it; no workaround |
Should Have | Painful to leave out | Viable without it; workaround exists |
Could Have | Contingency pool | First drop when the date slips |
Won't Have this time | Out of this timeframe | Recorded; excluded from effort |
Must Have
Must is the Minimum Usable SubseT. ABC gives the cancel-the-project test: if the answer to "what happens if this is not met?" is "cancel the project," it is a Must. No point delivering on the date without it, not legal without it, unsafe without it, or you cannot deliver a viable solution without it.
The workaround test is the line recaps skip. If any workaround exists, even manual and painful, it is a Should or Could. Mike Clayton puts the same bar in plain language: if you skip it, the project makes no sense.
"There are things that we must do. If we don't do them then it makes no sense to do the project at all." (Mike Clayton in "What is MOSCOW Analysis?", Online PM Courses, 0:40)
Should Have
Leave a Should out and the release still ships. The pain is real; you may need a temporary workaround. Differentiate Should from Could by degree of pain: business value, or how many people get hurt.
Do not bundle Should into Must to make a stakeholder feel heard. That is how the 60% cap dies in the room.
Could Have
Wanted, not load-bearing. Could is the contingency pool, delivered in full only in a best-case scenario. When the deadline is at risk, Coulds go first, in a 30-second conversation at the end of a timebox.
Pressuring a team to guarantee Musts plus Shoulds plus Coulds fights the method. The plan was built on early estimates.
Won't Have This Time
Won't Have this time is agreed out of this timeframe. You still record it on the prioritized list so nobody reintroduces it informally.
Won't is excluded when you calculate effort. It is not a permanent rejection.
W is not Would, not Wish, and not Want. Glossaries that soften the letter put the item back into maybe-scope.
"Won't have is very strong, very negative… let's soften it a bit, let's call it would like to have. No, don't mess." (Andrew Craddock, PMI UK, 23:21)
Benefits of the MoSCoW Method
Stakeholders Can Parse the Labels
Business analysts on r/businessanalysis keep MoSCoW because the labels are intuitive. The win is a shared cut, not a formula.
The Date Can Stay Put
DSDM-style delivery fixes the timebox and negotiates features. Coulds (~20% of effort) are scope-based contingency.
You do not pad calendar days and watch Parkinson's law fill them. New Musts can still land: they sink into the Must pot and push a Could into Won't this time.
Nested Cuts Survive "Everything Is a Must"
Teams inflate Must at the epic level. Nested labels let a project-level Must sit as Won't for this sprint while a specialist is out, without pretending the epic is optional forever. That is how the method survives a roadmap that still says "all of it."
MoSCoW vs Scoring Models
RICE and Kano answer different questions. The Kano model already has its own page.
Method | What it produces | Use it when |
|---|---|---|
MoSCoW | Four buckets | "What must be in this release?" |
RICE | A ranked list | "What should we build first?" |
Kano | Basic / performance / delight | "What do customers feel?" |
RICE (Reach × Impact × Confidence, divided by Effort) scores a big list. MoSCoW does not produce a score.
Inside Must, nothing tells you which Must comes first, and that is by design. Kano maps satisfaction against investment. MoSCoW never measures delight.
A common hybrid: MoSCoW to filter the release, then RICE to sequence inside a bucket. Or Kano first, so you do not Must a delighter and Could a baseline. Product user stories still need their own split after the feature-level cut.
On Reddit, the Kano gap is the live complaint:
"The problem with Moscow is it doesn't capture where something is needed because its baseline expectation, vs something that will excite and bring in / keep more users as a USP." (u/gabescharner in r/ProductManagement, Aug 2025)
Do not turn MoSCoW into a four-step ROI process. It is a bucket sort inside a fixed timebox.
Challenges and Limitations
Must Inflation
If dropping the item would not cancel the project, it is not a Must, even when the workaround is expensive. Craddock's bar is the whole project failing outright.
When Must exceeds 60% of capacity, you have a list, not a priority. Silent-sort first and total Must effort against the cap before the meeting opens, so the room starts on the overage.
No Rank Inside a Bucket
Four piles are not an order. After the sort you still need a sequencer, a now/next board, or sprint order.
MoSCoW also ignores reach, ROI math, customer delight, and task dependencies. Those are jobs for RICE, Kano, and your actual schedule, not extra letters on the acronym.
An Empty Won't Column
The usual failure is leaving Won't blank, or renaming it Would so the cut feels polite. A softened W reopens the item as maybe-in-scope.
Keep "this time" in the label, keep the column visible, and review it at the next increment. Theatre without a user-goal anchor inflates Must the same way: you classify features instead of outcomes.
Must Plus Should Is Not the MVP
ABC's Minimum Usable SubseT is the viable slice of this delivery. An MVP is a learning slice. They collide in workshops and they are not the same thing.
"You may use MoSCoW to agree what features are included in your MVP, but it would not be correct to say that an MVP should comprise of all M&S of the fully featured end product." (u/I_am_John_Mac in r/projectmanagement, Dec 2016)
Frameworks frame the conversation. They do not make the decision. Product discovery still has to kill work; MoSCoW only records the cut.
A Share-Findings Backlog
Independent explainers classify bicycles and login forms. Here is a six-week "Share findings" timebox for a UX research repository, with a non-empty Won't column.
Feature | Bucket | Test |
|---|---|---|
Share link readable without an account | Must | No point shipping the release without it |
Unpublished interviews stay private | Must | Unsafe without it |
Quote stays tied to the transcript | Must | Not a viable readout without source |
Inline comments on an insight | Should | Slack thread is a painful workaround |
Click a quote to the video timestamp | Should | Manual scrub still works |
Branded PDF of the share page | Could | First drop when the date slips |
Emoji reactions | Could | Best-case polish |
Public research gallery | Won't this time | Later increment |
AI auto-summary on the share page | Won't this time | Not this box |
Guest editor seats | Won't this time | Not this release |
If those three Musts already consume more than 60% of the six-week capacity, cut a Must or slip the date. Do not relabel comments as Must because a stakeholder likes them.
Run this at feature level (v1 share, v2 collaboration, v3 public gallery), not as a ranker of every user story. v1 is the Minimum Usable SubseT of this timebox.
