"Everything is a priority." I have heard it often enough to know what it announces: a list of thirty items, twenty-eight of them marked essential, and a team discovering three weeks before delivery that half of them have to go. The MoSCoW matrix exists to have that conversation at the start rather than at the end.
The four levels
MoSCoW is an acronym. The four capitals carry the meaning; the two lower-case o's are only there to make the word pronounceable.
- Must have: essential. Without it, the delivery does not happen. No degraded version, no slipping to next month.
- Should have: important. Its absence hurts, but there is a workaround you can live with for the span of one release.
- Could have: desirable. You ship it if time allows. It is the first thing to go when the schedule tightens.
- Won't have: out of scope. Explicitly excluded from this delivery, and written down as such.
The method comes from Dai Clegg, who formalised it at Oracle in 1994, before DSDM and then most iterative approaches picked it up. It is not limited to software: any scope that breaks into independently deliverable pieces can go through it.
The 60% rule, which does all the work
Sorting into four columns is worthless if three of them stay empty. That is why DSDM adds a number: must haves should not exceed 60% of the total effort of the delivery, and around 20% should be kept as could haves.
The logic is mechanical. Could haves are your room for manoeuvre. They are what you sacrifice when a task takes twice as long as planned, when a developer falls ill, when the client adds a request. If your list is 90% must have, you have no adjustable variable at all, and the first surprise leaves you stuck.
This is exactly the situation the iron triangle describes when all three constraints are frozen at once. Something has to absorb. If it is not the scope, it will be the quality or the team.
The 60% is measured in effort, not in number of lines. Ten items marked essential can weigh less than two large pieces of work marked important. Without an estimate, however rough, the rule means nothing: estimating the duration of each task is therefore a prerequisite, not a later step.
The question that settles two essentials
Everyone gets stuck in the same place. Two people each defend their item, both say essential, and the meeting grinds to a halt.
The question that unblocks it is not "is this important". It is: what exactly happens if we do not ship it on the day?
- "We cannot open the service" or "it is a regulatory obligation": that is a must have.
- "Users will have to go through a spreadsheet export for two months": that is a should have. A workaround exists, it is painful, it is bearable.
- "It would be nicer that way": that is a could have.
The word that decides is workaround. A must have has none. The moment someone at the table describes a way, however ugly, of living without it for a few weeks, the item drops a level.
This conversation happens with the sponsor, not between team members. They are the one who carries the consequences of a delay, so they are the one who arbitrates. The team brings the effort estimates and the possible workarounds; it does not decide alone what is essential.
Won't have, the level everyone skips
It is the most useful column and the least filled. It says "not this time", and specifically not "never".
Its value is entirely defensive. A request written down in black and white as excluded does not come back in week six as "but I thought that was planned". It is recorded, it is dated, someone accepted it. It is one of the few moves that genuinely slows scope creep.
I always add a line next to each won't have: the release where it comes back. "Not in V1, to be revisited when scoping V2." It costs ten seconds and it turns a refusal into a postponement, which changes entirely how it is received.
What MoSCoW does not tell you
Three limits worth knowing before you lean on it.
Priority does not give the order of execution. Two items both marked must have cannot necessarily be done in any order: if one conditions the other, it is the dependency that commands, not the priority. That is the job of the network diagram and the critical path, not of the matrix.
A priority ages. A classification made at kick-off and never reopened becomes decoration within two months. The market moves, the sponsor changes their mind, a could have becomes urgent. The matrix is re-read at every milestone, otherwise it lies.
It says nothing about relative value inside a level. Fifteen must haves are still fifteen items to order among themselves. MoSCoW removes the noise; it does not build the sequence.
Where it fits in a project
It comes after the breakdown and before the schedule. You first list what has to be done, for instance with a WBS or a mind map. Then you prioritise. You plan only once both are done.
It is particularly useful when the date is imposed and will not move: it is the central mechanism of agile backward planning, where you start from the deadline and adjust the content. Scoping the project is the right moment to run the exercise.
In short
MoSCoW does not rank wishes. It forces an organisation to say what it accepts not to deliver. Everything else follows from that.
Three moves are enough for it to hold: write the four levels with the sponsor, check that must haves do not exceed 60% of the effort, and fill in the won't have column instead of leaving it empty.
In Orchesia, the backlog of a simplified project uses these four columns. Items move from one level to another by drag and drop, the share of effort is recalculated at each move, and the out-of-scope column stays visible instead of disappearing into a side file.
