MoSCoW Prioritisation: A Plain-English Guide to Must, Should, Could and Won't

Every project has more ideas than time. Deciding what to deliver first, and what to leave for later, is one of the hardest conversations a team can have. MoSCoW prioritisation is a simple way to hold that conversation. This guide explains the four categories, draws on the Agile Business Consortium's published description, and offers a short way to try it on your own project.

What MoSCoW means

The name is an acronym built from four categories, with the lower-case "o" letters added to make it pronounceable. Each requirement on a project is placed in exactly one group.

• Must Have. The Agile Business Consortium describes these as the Minimum Usable SubseT (MUST) of requirements which the project guarantees to deliver. They are the baseline the project commits to.
• Should Have. Important but not vital. Leaving one out would be painful, but the solution would still be viable.
• Could Have. Wanted or desirable but less important. These are the first items to drop if the deadline is at risk.
• Won't Have this time. Requirements the team has agreed will not be delivered within this timeframe. They are recorded to keep the scope clear, not forgotten.

The 60% guidance

One of the most useful points in the Consortium's description concerns proportion. It suggests keeping Must Have effort to typically no more than 60% of the total. Higher levels add risk, unless estimates are accurate, the approach is well understood, the team is performing well and the environment is low-risk.

It also describes a contingency pool of typically around 20% Could Have effort. The thinking is straightforward: if the Could Haves are the first to go when something slips, then having some of them in the plan gives the team room to absorb surprises without breaking the commitment to the Musts. Won't Have items are left out when calculating effort for a timeframe.

A short way to try it

1. List the requirements. Write each on its own line, in plain words.
2. Agree the timeframe. MoSCoW only makes sense against a fixed period, such as a release or a quarter.
3. Sort into the four groups. Ask of each item: if we deliver everything else but not this, is the result still usable? If not, it is a Must.
4. Estimate the effort. Add up the effort for each group, then compare the Must Have total with the whole.
5. Challenge the Musts. If the Musts are well over 60% of the effort, ask which items are really Shoulds in disguise.
6. Record the Won't Haves. Writing them down prevents quiet scope creep and gives stakeholders a clear answer when they ask where an item went.

Common pitfalls

The most frequent problem is "everything is a Must". If every item is critical, the method has no room to work. Another is leaving the Won't Have list empty, which can hide disagreements instead of resolving them. A third is treating the categories as permanent: an item that is a Won't Have this time can become a Must next time, and that is perfectly normal.

The takeaway

MoSCoW is not a formula. It is a structured conversation that helps a team agree what matters most, protect the essentials, and be honest about what will wait. Used with realistic estimates, it makes trade-offs visible early, when they are cheapest to make.

Based on the Agile Business Consortium article "What is MoSCoW Prioritization?". General information only.