MoSCoW Method
A prioritization technique that classifies requirements into four categories — Must Have, Should Have, Could Have, and Won't Have — to scope a release against a fixed deadline.
What is the MoSCoW Method?
The MoSCoW method is a prioritization framework that categorises requirements into four buckets based on their necessity within a fixed timeframe. The name is an acronym from the first letters of each category (the Os are added for pronunciation).
| Category | Definition |
|---|---|
| Must Have | Non-negotiable. The release fails without these. |
| Should Have | Important, but a workaround exists. Include if capacity allows. |
| Could Have | Nice to have. Include only if time and budget allow. |
| Won't Have (this time) | Explicitly out of scope for this release. |
How to apply it
Step 1: Set the release boundary. MoSCoW only works with a fixed deadline or capacity constraint. Without one, everything becomes Must Have.
Step 2: Classify with stakeholders. Must Haves should represent ~60% of estimated effort — leaving buffer for Should Haves and unexpected complexity.
Step 3: Document Won't Haves explicitly. This is the most underused part. Writing down what you're not building prevents scope creep and converts "no" into "not this release."
Step 4: Get sign-off. All key stakeholders should agree on the Must Have list before development begins.
Recommended capacity split
| Category | % of sprint/release capacity |
|---|---|
| Must Have | ~60% |
| Should Have | ~20% |
| Could Have | ~20% (pulled in if Must + Should complete early) |
MoSCoW vs. RICE
| Dimension | MoSCoW | RICE |
|---|---|---|
| Output | Categorical buckets | Ranked numeric scores |
| Use case | Scoping a specific release | Ranking a full backlog |
| Effort | Low — qualitative judgement | Medium — requires estimates |
| Strength | Fast stakeholder alignment | Data-backed, defensible prioritisation |
Use together: RICE to rank your backlog, MoSCoW to scope a specific sprint or release from the top of that ranked list.
Common mistakes
- All Must Have lists. If everything is Must Have, either the deadline is wrong or the scope hasn't been properly challenged. Force-rank the Must Haves — the bottom becomes Should Have.
- Ignoring Won't Have. Without an explicit Won't Have list, scope creep enters through requests that "shouldn't take long."
- Using MoSCoW without a deadline. The framework is meaningless without a constraint it's scoping against.
Free templates for MoSCoW
Frequently asked questions
Who invented the MoSCoW method?
Dai Clegg created MoSCoW in 1994 while working at Oracle. It was later adopted as part of the DSDM (Dynamic Systems Development Method) agile framework.
Should Could Haves ever be included?
Yes — that's their purpose. If the team delivers Must Haves and Should Haves ahead of schedule, Could Haves get pulled in. They act as a productive buffer that keeps developers working without overcommitting scope.
How detailed should each MoSCoW item be?
Detailed enough for engineering to estimate and QA to test. 'Improve performance' is too vague. 'Reduce search API response time from 800ms to under 300ms' is a Must Have. Vague items belong in the backlog, not a MoSCoW matrix.
Can MoSCoW be used for product roadmaps, not just sprints?
Yes — it works at any horizon. Apply it to a quarterly roadmap (Must Have this quarter, Should Have if capacity allows, Won't Have until next quarter) or a release (Must Have for launch, Should Have in v1.1). The fixed constraint just changes from sprint capacity to quarter capacity.
Apply MoSCoW Method to your real product data
PMRead ingests customer feedback, interviews, and Slack threads — and generates PRDs grounded in real evidence.
Related terms
PRD (Product Requirements Document)
A written document that describes what a product or feature should do, why it exists, and how success will be measured — before engineering begins.
RICE Scoring
A quantitative feature prioritization framework that scores each initiative by Reach, Impact, Confidence, and Effort — producing a single number to rank your roadmap.