Understand the four priority levels
MoSCoW ranks needs according to their real importance to project success. It can be applied to features, requirements, deliverables or work packages.
The classification should reflect the consequence of not delivering an item, not the personal preference of the requester.
Must, Should, Could, Won’t
Each level answers a different question.
- Must have: without it, the release or project is not acceptable.
- Should have: very important, but a workaround or later delivery is possible.
- Could have: useful value if capacity allows.
- Won’t have for now: deliberately excluded from the current version or period.
Define criteria before ranking
To avoid turning every request into a Must, agree criteria such as regulatory obligation, critical dependency, security, user value, business impact, contractual commitment or operational risk.
Ask: what happens if this item is not delivered now? If the answer is mainly “it would be less convenient”, it is probably a Should or Could.
Limit the number of Must items
A list dominated by Musts usually means prioritisation has not really happened. Preserve capacity for uncertainty and trade-offs.
Prioritise with the right stakeholders
Prioritisation should not be decided by the delivery team alone. Business owners, users, sponsors and constrained functions should contribute when their interests are affected.
Run a short session with the needs list, decision criteria and available capacity. Disagreements become visible and can be resolved explicitly.
Record why an item was ranked
A short rationale prevents the same debate from restarting in every meeting. Record the reason, decision-maker and review date when useful.
Connect MoSCoW to schedule and scope
Priority should change what the team does. Musts are secured first. Shoulds remain while the plan is sustainable. Coulds become the first adjustment area when delivery is under pressure.
Won’ts are not necessarily discarded forever: they are explicitly out of scope for the current period and may feed a future backlog.
Website example
For a contact form, consent, validation and message delivery may be Must; a customised confirmation email Should; a success animation Could; a customer portal Won’t for this release.
Review priorities when context changes
Priority is not permanent. A new compliance constraint, risk, user insight or dependency may change the order.
Revisit MoSCoW at major milestones and before significant scope trade-offs. The method works when it reflects the current situation.
Avoid the “everything is urgent” trap
Separate urgency from importance. An urgent request may contribute little to the project objective, while a Must may require long preparation without being urgent today.
Implementation checklist
Before considering the topic under control, check these points in your project.
- Criteria agreed.
- Musts limited.
- Trade-offs shared.
- Rationale recorded.
- Priorities linked to plan.
Continue with related project management guides
Conclusion
This method becomes truly useful when it is applied consistently and adapted to the project context. The goal is not to create more documentation, but to make decisions, responsibilities and trade-offs more explicit.