Updated: 2026-07-07

Prioritising requirements is one of the most difficult and most frequent decisions in project management. The MoSCoW method offers a shared language that turns ambiguous conversations about "what is important" into explicit decisions agreed upon by the whole team.

Developed in 1994 by Dai Clegg at Oracle UK for the DSDM agile framework, MoSCoW addresses a very specific problem: when everything seems urgent, teams lose the ability to decide what they will deliver and what they will defer.

Key takeaways

  • MoSCoW is an acronym: Must have, Should have, Could have, Won’t have.

  • Its greatest value lies in forcing an explicit conversation about priorities before committing resources; the classification is the result, not the goal.

  • The "Must have" category must be defensible: if everything is Must, the method has failed.

  • It is especially useful in agile contexts where sprint scope needs to be agreed upon.

  • It does not consider cost, complexity, or risk; it is best complemented with other tools.

The 4 categories in detail

Must have Requirements without which the deliverable is not viable. If a Must have is not delivered, the project does not meet its minimum objective. The verification question: Can the system launch without this? If no, it is Must have. If "it would be uncomfortable", it is probably Should have.

Typical examples: user authentication, regulatory compliance, core product functionality.

Should have Highly important requirements that are not critical for launch but add significant value. If time or resources allow, they should be included. If not, they can be deferred to the next cycle without compromising deliverable viability.

Typical examples: email notifications, advanced search filters, data export.

Could have Desirable functionality with lower impact if omitted. First candidates for removal when unexpected issues arise. Their presence or absence does not change the core user experience.

Typical examples: interface personalisation, advanced keyboard shortcuts, colour themes.

Won’t have (for now) Requirements explicitly out of scope for the current cycle. The "Won’t" category is almost as important as "Must": explicitly placing something here avoids it re-emerging mid-sprint. It does not mean "never"; it means "not in this iteration".

How to apply it step by step

The standard process for a MoSCoW prioritisation session:

  • List all candidate requirements without prior filtering. Include backlog items, stakeholder requests, and technical team items.

  • Present each requirement with enough context for all participants to weigh in (business, development, design).

  • Classify individually before debating. Each person assigns a category. Discrepancies are the most valuable part of the exercise.

  • Debate discrepancies and reach consensus. The goal is not unanimous agreement: the final classification simply needs to be accepted by the team.

  • Document and review the result. The classification is a guide and must be revisited when project circumstances change.

The "Won’t" category deserves special attention: if not explicitly named, excluded requirements tend to re-emerge implicitly, generating scope creep.

Benefits in project management

3 concrete benefits of disciplined MoSCoW use:

  • Expectation alignment. Making each requirement’s priority explicit reduces end-of-sprint surprises: everyone knows what will and will not be delivered.

  • Faster decision-making. When unexpected issues arise, the pre-existing classification makes it easier to decide what to sacrifice first (Could have) and what to protect at all costs (Must have).

  • Stakeholder communication. The 4-category language is simple enough for non-technical profiles and precise enough to guide engineering decisions.

Common limitations

The "everything is Must have" problem: when stakeholders feel they will lose influence if their requirements are not Must, they tend to classify everything there. The facilitator must remind everyone that an inflated Must have destroys the method’s value.

Absence of cost and complexity criteria: MoSCoW classifies by functional importance, not implementation effort. A Could have that costs twice a Must have may require additional analysis before the final decision.

Project dynamism: the classification reflects the project’s state at a given moment. It should be reviewed each cycle, especially when time, budget, or strategy constraints change.

Lack of granularity: for complex projects, 4 categories may be insufficient. Combining MoSCoW with impact-effort matrices or business-value scoring provides more precision.

Application examples

Web development project: an e-commerce MVP might classify requirements as follows: – Must: product catalogue, shopping cart, checkout, payment integration. – Should: search filters, user reviews, order management panel. – Could: wish lists, product comparisons, personalised recommendations. – Won’t: loyalty programme, AR product try-on, native app.

Content management system: for a new CMS launch: – Must: content creation and editing, role management, secure authentication. – Should: scheduled publishing, social media integration, internal search. – Could: approval workflows, content versioning, multilingual support. – Won’t: sentiment analysis, generative AI features, ERP integration.

For teams tracking startup metrics and working with agile sprints, MoSCoW helps focus early iterations on features that drive key metrics (activation, retention) and defer those with lower measurable impact.

Conclusion

The MoSCoW method does not resolve the difficulty of prioritising: it makes it explicit and manageable. Its greatest contribution is creating a shared language that prevents priorities from being implicit, subjective, or different depending on who you ask. Well applied, it is the first step to protecting development teams from scope creep and ensuring every sprint delivers something of real business value.