Classify requirements as Must Have, Should Have, Could Have, or Won't Have this time. A Must Have is something whose absence makes the release unsafe, illegal, or unable to achieve its agreed purpose.
- Define the release outcome and timebox before classifying anything.
- Test every Must by asking what fails if it is absent.
- Write Won't Have this time, so deferral is explicit rather than dismissive.
The four MoSCoW categories
Must Haves are non-negotiable for this delivery. Should Haves are important but have a tolerable workaround. Could Haves are desirable if capacity remains. Won't Haves are explicitly outside the current timebox, even if they remain valuable later.
| Category | Requirement | Reason |
|---|---|---|
| Must | SAML SSO | The pilot customer's security policy blocks access without it. |
| Should | Audit-log export | Admins can use a manual export during the pilot. |
| Could | Custom login branding | Helpful for adoption but unrelated to secure access. |
| Won't this time | Multiple identity providers | The pilot requires one configured provider. |
Stop Must Have inflation
Ask: if this is missing, can the release still operate safely and achieve its stated purpose? If the answer is yes, the item is not a Must. Revenue potential alone does not automatically make a requirement a Must unless the release decision explicitly depends on that contract or commitment.
Keep the Must set small enough that the team has a credible delivery plan. If almost everything is a Must, the categories are no longer helping the team manage scope.
A practical MoSCoW workshop
Run the classification as a constrained decision, not a voting exercise.
- Write the release outcome, deadline, and non-negotiable constraints.
- Classify each requirement provisionally and record the reason.
- Challenge every Must with the failure test.
- Check that Should and Could items can actually be removed if delivery slips.
- Publish the Won't Have list with the next review date.
Common mistakes
- Using MoSCoW without a specific release or timebox.
- Treating stakeholder seniority as proof that an item is a Must.
- Leaving Won't Have items undocumented, which lets them quietly return.
- Using the categories as a complete roadmap ranking within each group.
Check your understanding
A feature is valuable, but the release still works safely and meets its purpose without it. Can it be a Must Have?
Not under the strict MoSCoW test. It belongs in Should or Could unless a real constraint makes it indispensable.
Sources
- Agile Business Consortium: MoSCoW prioritisationThe DSDM definition of Must, Should, Could, and Won't Have this time.