Every project runs out of time before it runs out of requirements. MoSCoW is a structured way of deciding what actually has to be there, and of making that decision visible and agreed rather than settled quietly by whoever shouts loudest.
What MoSCoW means
- Must have – critical. Without it the project has failed. Not “important” – failed.
- Should have – important but not vital. Its absence significantly reduces value or usability, but the thing still works.
- Could have – desirable. Enhancements whose absence does not affect success.
- Won’t have this time – agreed to be out of scope for this release. Not rejected: deferred, deliberately and on the record.
That last category does more work than people expect. “Won’t have this time” is what converts an argument into a decision, and it is the reason MoSCoW reduces scope creep rather than merely describing it.
When to use it
- Project initiation – sets expectations and defines scope by separating essential from deferrable before anyone is committed.
- Requirement gathering – the process itself surfaces disagreement between stakeholders early, while it is still cheap.
- Sprint planning – backlog prioritisation, so development effort goes to the critical features first.
- Resource allocation – so the genuinely critical work is never the thing that ends up understaffed.
Five things that make it work
- Keep stakeholders in the room. Prioritisation done without them is a list, not an agreement, and it will be reopened later at the worst moment.
- Be realistic. Overcommitting to “Must haves” is the commonest way this fails – if everything is a Must, nothing is prioritised and the method has achieved nothing.
- Review regularly. Priorities move as a project proceeds; categories set once and never revisited stop describing reality.
- Define the boundary explicitly. Write down what separates a Must from a Should on this project, or the categories will mean different things to different people.
- Document the decisions and the reasoning. Not just what was agreed but why – which is what protects the decision when it is challenged three months later.
What it looks like in practice
A software development project
- Must: user authentication and authorisation – secure access is not negotiable
- Should: advanced analytics and reporting
- Could: customisable interface themes
- Won’t this time: third-party integrations, planned for the next release
A new system implementation
- Must: data migration from the old system – without it there is no continuity of service
- Should: staff training on the new system
- Could: automated workflows
- Won’t this time: integration with legacy systems being phased out anyway
Note what is a Should in the second example: training. That is a common and revealing call – the system works without it, but adoption may not. Where training lands in a MoSCoW list tells you a good deal about whether a programme has understood the difference between delivery and adoption.
See also Why Good Project Managers Are Not Always Good Change Managers, or talk to us.
Further reading: GOV.UK Service Manual: agile delivery