What the four categories commit you to
| Category |
What it means |
The test an entry must pass |
| Must have |
Without it the release fails, breaks a legal obligation or misses its point. Delivery is postponed rather than shipped without it. |
If this were missing at go-live, would we cancel or delay? If not, it is not a Must. |
| Should have |
Important and painful to omit, but a workaround exists and the release still stands. |
Can we live without this for a period, at a cost we can name? |
| Could have |
Desirable if time and budget allow. The first category dropped when they do not. |
Would anyone outside the requesting team notice its absence in month one? |
| Won't have (this time) |
Explicitly excluded from this release, recorded in writing, revisited at the next planning round. |
Has the requester seen it written down and been told when it will be reconsidered? |
Where MoSCoW belongs in a decision process
The framework was built for time-boxed delivery, where the deadline is fixed and scope is the only variable left to manage. That is also where it serves best commercially: scoping the first phase of an ERP or CRM implementation, cutting an RFP requirements list down to what will actually be evaluated, or sequencing a transformation whose sponsors want everything in year one. DSDM's own guidance is worth keeping: Must haves should consume no more than around 60 per cent of the delivery effort, so that Should and Could items act as contingency when the Musts prove harder than estimated. A plan that is 100 per cent Must has no shock absorber.
An illustrative scoping session
A mid-market insurer scoping the first release of a policy administration replacement collects 240 requirements from the business, of which 175 arrive marked Must. The facilitator applies one question to each: if this were missing at go-live, would you postpone? Genuine Musts survive (regulatory reporting, policy issuance for the two core products, the broker data feeds), while entries that are really Shoulds with influential sponsors do not. The final cut carries 38 Musts and, just as importantly, a written Won't-have list of sixty items with a named date for reconsideration. When the familiar month-eight argument arrives ("we were promised the customer portal"), the answer is a document rather than a memory contest.
How the Must column gets flooded
The gaming of MoSCoW is so consistent that it is practically part of the method.
- Everything becomes a Must, because stakeholders learn that anything ranked lower may never be delivered. The inflation is rational for each requester and fatal for the plan.
- The Won't-have column is left empty, because writing a requirement there means telling a named stakeholder no, in a document they will see. An empty Won't list means the hardest conversations were skipped rather than resolved.
- Should becomes the diplomatic Must: the facilitator, unable to win the argument, parks contested items one rung down and every stakeholder privately keeps their own definition of what that rung means.
- Categories track the seniority of the requester rather than the consequence of absence, which is how an executive dashboard comes to outrank a statutory report.
- Items get promoted mid-delivery without anything being demoted, and a 60 per cent Must plan becomes a 95 per cent Must plan by month six.
The Won't-have list is the real output
A completed MoSCoW exercise produces two artefacts, and the less popular one matters more. The Must list tells the delivery team what to build. The Won't list tells the organisation what has actually been decided: it converts vague deferral into explicit, dated exclusion, protects the team from scope creep with a document instead of an argument, and gives every stakeholder whose item was excluded a legitimate route back at the next planning round. Teams that skip it have not prioritised; they have postponed the argument to the most expensive possible moment.
Independent challenge on the requirement list
Nobody inside the organisation can safely down-prioritise another function's requirements, which is why internal MoSCoW sessions drift towards inflation. Selected senior operators who have implemented comparable platforms bring the missing reference class: which Musts on lists like this turned out to be Shoulds in production, which ignored requirement came back as an expensive change order, and what a realistic Must proportion looks like for this class of programme. That challenge costs least before the RFP is issued, while the list still belongs to the buyer rather than to the contract.
