COMMON PITFALL
MoSCoW method: when everything is a Must
A board where nearly everything is a Must and nothing is a Won't has sorted nothing.
By Michael Tor · October 2026
The MoSCoW method sorts the scope of a fixed-date release into Must have, Should have, Could have, and Won't have this time. Wikipedia credits Dai Clegg with developing it in 1994, and the Agile Business Consortium's DSDM guidance describes Must Haves as the Minimum Usable SubseT the project guarantees to deliver. It is a call about what you give up, not a label exercise. It works only when every Must survives the cancel test, Must effort stays under an agreed ceiling, and the Won't column is written down. When nearly everything is a Must and nothing is a Won't, the drop call has only been postponed.
Who is this for?
Product managers and delivery leads running a release-scope session against a fixed date. This happens before a launch event, a contract deadline, or a compliance date. Sales and leadership each bring their item as a Must. The board looks sorted and everyone leaves happy. But the Must column holds most of the effort, the Won't column is empty, and nobody has agreed what drops first when the estimate slips.
What is the Must inflation failure mode?
Stakeholders label their items Must and nothing is given up. The real choice about what to cut gets made weeks later under deadline pressure by whoever is in the room. The DSDM guidance notes that in a traditional project all requirements are treated as Must Have. DSDM's guidance puts it as: believing everything is a Must Have is often symptomatic of insufficient decomposition of requirements. The inverse happens when the Won't column is read as never. Stakeholders fight harder to keep items out of it, which inflates the Musts further. Wikipedia lists this timing ambiguity as a known criticism.
Will your MoSCoW list hold when the date is at risk?
Check your board against these six conditions before the work starts.
-
Every Must passes the cancel test
If it were missing, you would stop the release. DSDM's guidance puts it as: if there is some way around it, even a manual and painful workaround, it is a Should or a Could.
-
Must is sized by effort under a ceiling
Must is sized by effort and sits under a ceiling agreed before sorting. DSDM describes typically no more than 60 percent Must Have effort.
-
A named pool of Coulds is sized as real contingency
DSDM describes a pool of Could Haves of typically around 20 percent of effort as contingency. Agree the order they drop in before work starts.
-
The Won't column is filled with timeframes
Each item says which timeframe it is out of, like this release or a named later review, so nobody reads it as never.
-
No Must depends on a Should or a Could
DSDM's guidance says a Must cannot depend on anything other than a Must.
-
The rule separating Should from Could is agreed
The rule that separates a Should from a Could was agreed before the sorting started, not argued item by item.
Consider a team with a fixed date to ship a partner integration before a trade show. Stakeholders tag 11 of 14 items as Must. The PM runs the cancel test. Single sign-on is in the partner contract, so it stays a Must. Bulk CSV export has a manual workaround, so it becomes a Should. Dark mode goes to Won't, tagged not this release, review after the show. Two small reporting items become the named Could pool that drops first.
When does MoSCoW help?
It helps when time and budget are fixed and scope has to flex. DSDM describes fixing time, cost and quality and negotiating features. It also helps when stakeholders need plain categories with a clear promise instead of high, medium, or low.
When does it hurt?
It hurts when you need an order inside a bucket. Wikipedia notes it does not help choose between requirements with the same priority. ProductPlan's glossary notes it has no objective method for ranking items against each other. Pair it with a ranking method for that step. It also hurts when there is no fixed timeframe, because the categories drift. Do not use it to settle whether the release is the right bet at all. MoSCoW sorts the scope of a release you have already chosen to ship. Keep the Won't list and the reason each Must stayed a Must in your product decision log.