What Is MoSCoW Prioritization? How to Use It Effectively
MoSCoW prioritization is a structured requirements prioritization technique that categorizes features, requirements, or work items into four groups based on their necessity: Must-have, Should-have, Could-have, and Won’t-have (this time). The technique was created by software development expert Dai Clegg while working at Oracle and has since become widely adopted in agile development, project management, and product planning contexts.
The MoSCoW acronym uses capital letters to form the mnemonic (Mo-S-Co-W), with lowercase letters filling gaps in the spelling. The “this time” qualifier in Won’t-have is deliberate — it explicitly frames deprioritized items as deferred rather than permanently excluded.
The Four MoSCoW Categories
Must-Have (M)
Must-haves are non-negotiable requirements — the minimum viable scope that the product or release absolutely must include to be considered viable. If a must-have is missing, the release should not go forward.
The test for a must-have is rigorous: ask “what happens if we deliver without this?” If the answer is “the product doesn’t work,” “regulatory requirements are violated,” or “the release fails entirely,” then it’s a must-have. If the absence is inconvenient but not disqualifying, it’s not a must-have.
Example: For an e-commerce checkout, must-haves include payment processing, order confirmation, and fraud prevention. Without these, the checkout can’t function.
Should-Have (S)
Should-haves are important requirements that add significant value but whose absence doesn’t make the product unviable. They should be included if at all possible and are expected to be in the vast majority of releases.
The test: “this is important and we expect to include it, but if we run out of time or capacity, we could survive without it.”
Example: In the e-commerce checkout, should-haves might include saved payment methods, order history access, and email confirmation with order details.
Could-Have (C)
Could-haves are desirable requirements that would improve the user experience or add value but have lower priority than should-haves. They’re the items that get implemented if there’s capacity remaining after must-haves and should-haves are addressed.
Example: Order tracking with real-time carrier updates, gift wrapping options, or a delivery date estimator.
Won’t-Have This Time (W)
Won’t-haves are explicitly out of scope for this release — items that have been evaluated and consciously deprioritized. The “this time” qualifier is important: it signals that the item is deferred, not permanently rejected.
Explicitly naming won’t-haves serves a critical function: it creates a shared agreement about scope boundaries that prevents stakeholders from assuming these items will be included.
Example: Subscription-based repeat ordering, loyalty rewards integration, or multi-currency checkout are explicitly deferred to future releases.
How to Apply MoSCoW Effectively
Use It Collaboratively
MoSCoW is most powerful when the categorization is done collaboratively — with the product owner, stakeholders, and development team participating. This ensures that priorities reflect diverse perspectives and builds shared understanding of scope decisions.
Be Strict About Must-Have
The value of MoSCoW depends on using must-have sparingly and honestly. Teams that inflate the must-have category undermine the framework’s ability to create meaningful scope flexibility. A general guideline: must-haves should represent 60% or less of the delivery capacity.
Pair with Timeboxing
MoSCoW is particularly powerful when combined with fixed time constraints (as in DSDM). When time is fixed, MoSCoW provides the scope flexibility that allows the team to deliver on time — completing must-haves and as many should-haves as capacity allows.
Revisit as Circumstances Change
MoSCoW categorizations should be revisited as the project progresses and new information emerges. A requirement that was a could-have at the start of a sprint might become a must-have after a customer conversation reveals its criticality.
Key Takeaways
MoSCoW prioritization provides a simple, shared vocabulary for scope discussions that cuts through the ambiguity of unstructured priority debates. By creating explicit categories with clear criteria, it helps teams make scope decisions more transparently and manage the inevitable trade-offs between ambition and capacity with less conflict and more shared understanding.