MoSCoW

Use this when you need to categorize features, requirements, or stories into Must Have, Should Have, Could Have, and Won't Have for a specific release, iteration, or scope boundary. MoSCoW is particularly useful when negotiating scope with stakeholders — it makes tradeoffs explicit and gives everyone a shared vocabulary for priority.

Framework attribution: MoSCoW prioritization was created by Dai Clegg in 1994 within the DSDM framework.

Process

Step 1: Gather inputs

Ask the user:

1. Items to categorize — List the features, requirements, stories, or capabilities. For each, provide a brief description.
2. Scope boundary — What is the timeframe or release these items are being prioritized for? (e.g., "MVP launch", "Q2 release", "Sprint 14-15", "Phase 1 contract deliverables".)
3. Success criteria — What must be true for this release/phase to be considered successful? (This defines what "Must Have" means.)
4. Constraints — Known capacity, timeline, budget, or technical constraints that limit what can be delivered.
5. Stakeholder context — Who needs to agree on these priorities? Are there competing views on what's essential?

Step 2: Identify which personas are affected

Before categorizing, prompt the user:

Persona check: Which user persona(s) does each item serve? If you have defined personas (e.g., from /persona-create or /persona-draft), name them. If not, describe the key user types briefly.

This prevents "Must Have" from meaning "the loudest stakeholder wants it" and grounds categorization in actual user need.

Step 3: Apply MoSCoW categorization

For each item, assign a category with rationale:

## MoSCoW Prioritization — (Release/Phase/Sprint Name)

**Date:** (Date)
**Scope boundary:** (What this covers)
**Success criteria:** (What "done" looks like for this release)

---

### Category Definitions (for this scope)

- **Must Have** — Without this, the release fails or is not viable. Non-negotiable.
- **Should Have** — Important and expected, but the release can ship without it. Plan to include; cut only under pressure.
- **Could Have** — Desirable if capacity allows. Improves the release but doesn't define it.
- **Won't Have (this time)** — Explicitly out of scope for this release. Acknowledged and deferred — not forgotten.

---

### Must Have

| # | Item | Rationale | Persona(s) Served |
|---|---|---|---|
| 1 | (Item) | (Why this is non-negotiable — what breaks without it) | (Persona names) |
| 2 | (Item) | (Rationale) | (Persona names) |

**Estimated effort for all Must Haves:** (Rough total — this should be ≤60% of available capacity to leave room for surprises)

### Should Have

| # | Item | Rationale | What we lose if cut |
|---|---|---|---|
| 1 | (Item) | (Why this is important but not essential) | (Impact of deferral) |
| 2 | (Item) | (Rationale) | (Impact) |

**Estimated effort for all Should Haves:** (Rough total)

### Could Have

| # | Item | Rationale | Trigger to include |
|---|---|---|---|
| 1 | (Item) | (Why this is desirable) | (What would make us pull this in — e.g., "if Must Haves complete early") |
| 2 | (Item) | (Rationale) | (Trigger) |

### Won't Have (this time)

| # | Item | Rationale | When to revisit |
|---|---|---|---|
| 1 | (Item) | (Why this is deferred — not "unimportant", but "not now") | (Suggested revisit point) |
| 2 | (Item) | (Rationale) | (Revisit point) |

Step 4: Validate the balance

Check the categorization against these rules of thumb:

### Balance Check

- **Must Haves should be ≤60% of capacity.** If Must Haves consume all capacity, there's no room for reality. Current: (X)% of estimated capacity.
- **Must Haves should map to success criteria.** Every Must Have should connect to a stated success criterion. Any that don't may be misclassified.
- **Won't Haves should be explicit, not hidden.** If stakeholders expect something that's a Won't Have, flag the misalignment now.
- **Should Haves are the negotiation zone.** In a scope crunch, these are what you discuss cutting — make sure the team agrees on the "What we lose if cut" column.

### Potential Misclassifications

- (Item) — Currently (category), but (reason it might belong elsewhere). Recommend: (action to resolve).

Step 5: Generate the scope summary

Produce a stakeholder-ready summary:

### Scope Summary

**In scope (Must + Should):** (Count) items, ~(effort estimate)
**Stretch (Could):** (Count) items, ~(effort estimate)
**Deferred (Won't):** (Count) items — revisit (when)

**Key tradeoff:** (The most important thing stakeholders should understand about what's in vs. out.)

**Risk if Must Haves expand:** (What happens if Must Haves grow during delivery — which Should Haves get cut first?)

Step 5b: Selling the scope decision

Use this when the client doesn't believe in MVP, when impact isn't clear, or when "we need all of it" is the response to any scope reduction. Categorizing items is the analytical work -- this step is the persuasion work that follows.

When the client wants everything:

• Reframe scope reduction as risk reduction: "Shipping less isn't about doing less -- it's about learning faster. Every item we defer is a bet we don't have to make yet."
• Use unknowns as arguments for smaller scope: "We have 3 open questions that affect these 5 items. Shipping the items we're confident about first lets us answer those questions with real data instead of guesses."
• Ask: "What's the smallest thing we can ship that proves the idea works?" This forces the conversation from features to evidence.

When MVP impact isn't clear:

• Connect Must Haves to a measurable outcome: "If we ship only the Must Haves, what number changes? If we can't answer that, we may not have the right Must Haves."
• Show the cost of delay: "Every item in Should Have adds [X] weeks. Is the value of those items worth [X] weeks of delayed learning?"
• Make Won't Haves feel safe: "Won't Have this time means we'll revisit in [specific timeframe]. It's a conscious deferral, not a cancellation."

When stakeholders have competing priorities:

• Use the persona column: "These 3 items serve Persona A, these 4 serve Persona B. Which persona are we optimizing for in this release?"
• Make the tradeoff explicit: "We can do all of Persona A's Must Haves or half of Persona A's and half of Persona B's. Which gives us more learning?"

Step 6: Review and validate

Ask the user:

• Is the Must Have list genuinely non-negotiable, or are some items actually Should Haves in disguise?
• Does the team agree on the success criteria that define Must Have?
• Are the Won't Haves communicated clearly to stakeholders who might expect them?
• Is the capacity balance realistic?

Adjust as needed.

Related skills

• /2x2-prioritize — for effort/impact or other 2-axis prioritization.
• /rice-score — for quantitative scoring when MoSCoW feels too subjective.
• /backlog-refine — for ongoing backlog health beyond initial categorization.
• /prd-draft — MoSCoW output feeds directly into the scope section of a PRD.
• /now-next-later-roadmap — translate MoSCoW into a stakeholder-facing roadmap.

Output location

Present the categorized table, balance check, and scope summary as formatted text in the conversation. The user copies the output into their PRD, planning documentation, or stakeholder communication.