# MoSCoW Prioritization

**Framework:** MoSCoW (Must Have, Should Have, Could Have, Won't Have)  
**Use for:** Feature, requirement, or scope prioritization — forcing explicit triage when everything feels like a priority.  
**Time required:** 30–60 minutes for an initial sort. Plan for one round of debate before locking.

---

## How to use this template

**The four categories:**

| Category | Meaning | Target % of scope |
|---|---|---|
| **M — Must Have** | Non-negotiable for launch / delivery. Without these, the product doesn't work or the project fails. | ~60% of effort |
| **S — Should Have** | Important but not critical. High value; can be descoped if pressed but should be the last to go. | ~20% of effort |
| **C — Could Have** | Nice to have. Will be dropped under time or resource pressure without significantly affecting core value. | ~20% of effort |
| **W — Won't Have (this time)** | Explicitly out of scope for this version. Saying "won't have" is important — it gives the team permission not to build it and prevents scope creep. | — |

**The discipline:**
- If everything is a Must Have, MoSCoW isn't working. Force real triage.
- The "Won't Have" list is as important as the Must Have list — it's the explicit list of what's been scoped out.
- MoSCoW is for a specific release or time box, not forever. Something in "Won't Have" today can be a Must Have in the next cycle.

---

## Context

**Product / project / release:** _______________  
**Time box / deadline:** _______________  
**Team:** _______________  
**Date:** _______________  
**Facilitated by:** _______________

---

## ✅ MUST HAVE

*Without these, the product/project fails or isn't usable. Zero negotiation.*

| Item | Owner | Effort estimate | Rationale for Must Have |
|---|---|---|---|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |

**Total estimated effort — Must Haves:** _______________

---

## 🟡 SHOULD HAVE

*High value; important but the product can ship without them. First to defend in scope conversations.*

| Item | Owner | Effort estimate | What we lose without it |
|---|---|---|---|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |

**Total estimated effort — Should Haves:** _______________

---

## 🔵 COULD HAVE

*Nice to have. Will be dropped under time or resource pressure. Build only if all Should Haves are done.*

| Item | Owner | Effort estimate | Notes |
|---|---|---|---|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |

**Total estimated effort — Could Haves:** _______________

---

## ❌ WON'T HAVE (this release)

*Explicitly out of scope. Saying this out loud prevents scope creep and gives the team permission not to build it.*

| Item | Why out of scope | When to revisit |
|---|---|---|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |

---

## Effort balance check

| Category | Effort | % of total |
|---|---|---|
| Must Have | | |
| Should Have | | |
| Could Have | | |
| **Total in scope** | | 100% |

**Is the Must Have % reasonable?** Target: ~60% of total effort. If Must Haves are >80%, either the team is over-committing or the definition of "must" is too loose.

**Does the combined Must + Should fit in the time box?** ☐ Yes  ☐ No — need to descope

---

## Descoping log

*When items move categories under pressure, log the change and the reason:*

| Date | Item | Moved from | Moved to | Reason |
|---|---|---|---|---|
| | | | | |
| | | | | |
| | | | | |

---

## Sign-off

| Name | Role | Signature | Date |
|---|---|---|---|
| | | | |
| | | | |
| | | | |

---

*MoSCoW is a prioritization technique developed by Dai Clegg at Oracle in the 1990s. Covered in the Frameworks & Mental Models Guide on biztechprimer.com.*
