MoSCoW Prioritization
Overview
MoSCoW is a prioritization technique used to reach a common understanding with stakeholders on the importance of each requirement. The name is an acronym derived from the first letter of each of the four prioritization categories.
The Categories
┌─────────────────────────────────────────────────────────────────┐
│ │
│ M - MUST HAVE │
│ ═══════════════ │
│ Non-negotiable requirements │
│ The product doesn't work without these │
│ These ship first │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ S - SHOULD HAVE │
│ ═══════════════ │
│ Important but not vital │
│ Product works without them (but not well) │
│ High priority for next iteration │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ C - COULD HAVE │
│ ═══════════════ │
│ Desirable but not necessary │
│ Nice UX improvements │
│ Include if time/budget permits │
│ │
├─────────────────────────────────────────────────────────────────┤
│ │
│ W - WON'T HAVE (this time) │
│ ═══════════════════════════ │
│ Explicitly out of scope for this release │
│ May be reconsidered for future releases │
│ Important to document (avoids scope creep) │
│ │
└─────────────────────────────────────────────────────────────────┘
Detailed Definitions
Must Have (M)
Definition: Requirements that are critical to the current delivery. Without them, the product is not viable.
Test questions:
- "Will the product work without this?" → If no, it's a Must Have
- "Is there a workaround?" → If no, it's a Must Have
- "Will users understand the value without this?" → If no, it might be a Must Have
Examples:
- User authentication (for apps requiring login)
- Core value-delivering feature
- Critical compliance/legal requirements
- Payment processing (for paid products)
Warning signs of false Must Haves:
- "Marketing wants this"
- "Competitors have this"
- "It would be nice to have"
- "Users might want this"
Should Have (S)
Definition: Important requirements that are not vital but add significant value.
Test questions:
- "Does this significantly improve the experience?" → If yes, Should Have
- "Would users be disappointed without it?" → If yes, Should Have
- "Is there a painful workaround?" → If yes, Should Have
Examples:
- Search functionality (if browsing is possible)
- Email notifications
- Profile customization
- Data export
Should Haves are first in line for V2.
Could Have (C)
Definition: Desirable requirements that are nice to have. Only include if time and resources permit.
Test questions:
- "Would this delight users?" → If yes but not critical, Could Have
- "Is this a polish item?" → Probably Could Have
- "Would users notice if it's missing?" → If barely, Could Have
Examples:
- Dark mode
- Keyboard shortcuts
- Animations/transitions
- Social sharing features
Could Haves are negotiated out first when time is short.
Won't Have (W)
Definition: Requirements that are agreed to be out of scope for the current release.
Why document Won't Haves:
- Prevents scope creep
- Manages stakeholder expectations
- Creates a backlog for future consideration
- Shows thoughtful prioritization
Examples:
- Mobile app (when starting web-only)
- Enterprise features
- Internationalization
- Advanced analytics
Won't Have doesn't mean "never"—it means "not now."
The MoSCoW Visual
PRIORITY
│
┌──────────────────┼──────────────────┐
│ │ │
│ MUST HAVE │ WON'T HAVE │
│ (Do First) │ (Not Now) │
│ │ │
│ ████████████ │ │
│ ████████████ │ ░░░░░░░░░░░░ │
│ ████████████ │ ░░░░░░░░░░░░ │
│ │ │
────┼──────────────────┼──────────────────┼────
│ │ │
│ SHOULD HAVE │ COULD HAVE │
│ (Do Next) │ (If Time) │
│ │ │
│ ▓▓▓▓▓▓▓▓▓▓▓▓ │ ░░░░░░░░░░░░ │
│ ▓▓▓▓▓▓▓▓▓▓▓▓ │ ░░░░░░░░░░░░ │
│ │ │
└──────────────────┼──────────────────┘
│
NECESSITY
Applying MoSCoW to MVP
Step 1: List All Requirements
Write down every feature/requirement without judgment.
Step 2: Start with Won't Have
Identify what's clearly out of scope. This is often easier than identifying Must Haves.
Step 3: Identify True Must Haves
Be ruthless. Ask: "Will the core product loop work without this?"
Step 4: Categorize the Rest
- Does it significantly impact value? → Should Have
- Is it polish/enhancement? → Could Have
Step 5: Review and Challenge
- Are there any false Must Haves?
- Could any Should Haves be demoted?
- Is the scope achievable?
Common Mistakes
1. Everything is a Must Have
Problem: If everything is critical, nothing is critical. Fix: Apply the "core loop" test. Only features essential to the core product loop are Must Haves.
2. Skipping Won't Have
Problem: Leads to scope creep and unmanaged expectations. Fix: Explicitly document what you're NOT doing.
3. Confusing Want with Need
Problem: Stakeholder desires become Must Haves. Fix: Require evidence or user validation for Must Have status.
4. Not Revisiting
Problem: Priorities change but categorization doesn't. Fix: Review MoSCoW at each iteration/milestone.
Combining with Value/Cost
MoSCoW can be combined with cost estimation for more nuanced prioritization:
| Feature | MoSCoW | Cost | Value | Priority |
|---|---|---|---|---|
| User login | M | S | 10 | 1 (mandatory) |
| Dashboard | M | M | 10 | 2 (mandatory) |
| Search | S | M | 8 | 3 |
| Export | S | S | 6 | 4 |
| Dark mode | C | S | 3 | 5 |
| Mobile app | W | XL | 7 | — |
Formula for S/C items: Value ÷ Cost = Priority Score
Workshop Usage
- Module 08: Part of backlog building exercise
- Exercise 03: Applied to participant's own features
Tips for Facilitation
- Do it as a team — Alignment is as valuable as the output
- Time-box debates — 2 minutes per contested item
- Use voting if stuck — Majority rules for S vs C debates
- Document reasoning — Why is this a Must Have?
- Be willing to revisit — New information changes priorities