The MoSCoW method: complete guide to requirement prioritization

MoSCoW prioritization solves one problem: forcing explicit decisions about what ships vs. what waits. The method divides requirements into four categories (Must Have, Should Have, Could Have, Won't Have) with one rule: if everything is a Must Have, the method has failed. MoSCoW's value is in forcing the conversation, not recording the outcome.

"MoSCoW works if you're disciplined about Must Have. If your Must Have list contains more than 60% of requirements, you haven't prioritized, you've renamed a full backlog. The whole point is that Must Have should be painful to define."

— Emma L., Senior PM at an enterprise software company

The four MoSCoW categories defined

Must Have (M): Requirements that are non-negotiable for the release. Without these, the product fails completely or violates a hard constraint (legal, safety, contractual). Must Haves should represent 50 to 60% of requirements maximum. If Must Have exceeds 60%, the scope is unrealistic.

Should Have (S): Requirements that are high-value but not critical. The product ships without them, but at lower quality. Should Haves represent what you build if time permits in the original scope.

Could Have (C): Nice-to-have requirements that would improve the product but have relatively low impact compared to effort. These are the first cuts when scope must be reduced.

Won't Have (W): Requirements explicitly excluded from this release. This is the most valuable category, it prevents scope creep by documenting what you have decided not to build. Always populate this list.

MoSCoW applied: feature example

Requirement	MoSCoW	Rationale
User can export activity as CSV	Must	3 enterprise customers blocked without it; contractual commitment
Date range filter on export	Should	Highly requested, but export works without it
PDF export format	Could	One customer request; low impact relative to engineering effort
Scheduled exports via email	Won't	Out of scope for v1; added to v2 roadmap

The failure modes that make MoSCoW useless

Must Have inflation. Every stakeholder marks their favorite requirements as Must Have. The result: a "prioritized" list where 90% is Must Have. Prevention: Must Have requires a hard justification, what specific failure mode occurs without it?

Empty Won't Have list. Skipping Won't Have is the most common MoSCoW mistake. The Won't Have list is the document that prevents scope creep, without it, there's no shared agreement on what's excluded.

Static MoSCoW after sprint start. MoSCoW should be recalibrated when effort estimates change significantly. A feature that was a Should Have at 2 days of effort becomes a Could Have at 2 weeks of effort.