MoSCoW Prioritisation Explained in English

MoSCoW prioritisation is one of the most widely used techniques in agile and requirements analysis for categorising features and requirements by importance. The name is an acronym from the four priority categories. If you work as a business analyst, product manager, or project manager in an English-speaking team, you need to be fluent in both the terminology and the conversation around it. This guide covers the vocabulary, the method, and the phrases that make MoSCoW workshops run smoothly.

---

What Does MoSCoW Stand For?

Letter	Category	Meaning
Mo	Must Have	Critical. The product cannot be delivered without this.
S	Should Have	Important but not critical. Can be delivered in a later iteration if necessary.
Co	Could Have	Nice to have. Will be included if time and budget permit.
W	Won’t Have	Explicitly out of scope for this release — but possibly a future priority.

“Let’s go through each requirement and agree on the MoSCoW category — M, S, C, or W.”

---

Must Have

Definition

A Must Have requirement is the minimum viable requirement — without it, the system cannot be considered done. Failing to deliver a Must Have means the project has failed.

Ask: “Would the product be unusable, unsafe, or legally non-compliant without this?”

If yes → Must Have.

Common phrasing:

• “This is a Must Have — it’s legally required under GDPR.”
• “Authentication is a Must Have — users cannot access the system without it.”
• “This can’t be a Must Have for this sprint — we’d never ship anything.”

Warning sign: If everything is a Must Have, the prioritisation isn’t working. Must Haves should represent ~60% of the total effort at most.

---

Should Have

Definition

A Should Have requirement is high-value but not critical for launch. The product can go live without it — but there will be a real impact (user frustration, inefficiency, manual workarounds).

Ask: “Is there a painful but acceptable workaround if we don’t have this?”

If yes → Should Have.

Common phrasing:

• “Bulk export is a Should Have — users can export individually for now, but it’s painful at scale.”
• “Push notifications should be in this release — customers will complain without them, but the app functions.”
• “We’ve downgraded this from a Must Have to a Should Have — it’s important, but not blocking launch.”

---

Could Have

Definition

A Could Have requirement is low-priority. It would improve the product but its absence wouldn’t disappoint most users. Often called “nice to haves.”

Ask: “Would average users notice or care if this were missing?”

If rarely → Could Have.

Common phrasing:

• “Dark mode is a Could Have — useful for some users, but it won’t affect adoption.”
• “The animation is a Could Have — it’s a polish item, not a core requirement.”
• “We’ll put this in the ‘Could Have’ bucket and revisit it if we have capacity.”

---

Won’t Have (This Time)

Definition

A Won’t Have requirement is explicitly out of scope for this release — not because it’s unimportant, but because it’s been consciously deferred or de-prioritised.

The “this time” qualifier is important: Won’t Have now doesn’t mean won’t have ever.

Why Won’t Have is useful:

• It manages stakeholder expectations explicitly
• It prevents scope creep
• It creates a documented roadmap backlog

Common phrasing:

• “Multi-language support is a Won’t Have for v1 — we’ve agreed to English only for the MVP.”
• “We’ve put social login in Won’t Have for this sprint — it’s not a dealbreaker for the pilot.”
• “I want to be clear: Won’t Have doesn’t mean we’re dropping it permanently — it’s a v2 candidate.”

---

Facilitating a MoSCoW Workshop

Opening the session

“We’re going to prioritise today’s backlog using the MoSCoW method. The goal is to leave today knowing exactly what’s in scope for the next release and what’s not.”

“Remember: Must Have means we cannot ship without it. If we can ship with a workaround, it’s probably a Should Have.”

Handling disagreements

“We have two votes for Must Have and one for Should Have. Can the Should Have voter explain their reasoning?”

“I hear that this is very important to you — but does the business fail without it in this release?”

“Let’s separate urgency from importance — just because it’s urgent doesn’t automatically make it a Must Have.”

Dealing with scope creep

“We agreed this feature was a Won’t Have for this sprint. Has something changed that would move it up?”

“If we add this as a Must Have, something else needs to move down. What are we willing to trade?”

Checking the balance

“Can we do a quick count? We have 8 Must Haves, 4 Should Haves, and 2 Could Haves. If the Must Haves fill our entire capacity, the Should Haves won’t get delivered. Does everyone accept that?”

---

MoSCoW Vocabulary Quick Reference

Term	Pronunciation	Usage
MoSCoW	MOSS-cow	”Let’s run a MoSCoW prioritisation.”
Must Have	—	“This is a Must Have for compliance.”
Should Have	—	“Should Haves are high priority but not blocking.”
Could Have	—	“Dark mode is a Could Have / nice to have.”
Won’t Have	—	“That’s a Won’t Have for this release.”
Minimum viable	—	“What’s the minimum viable set of requirements?”
Scope creep	—	“Adding this mid-sprint is scope creep.”
Descope	—	“We may need to descope the dashboard for v1.”
Defer	—	“We’ve agreed to defer multi-currency to Q3.”

---

Common Pitfalls

Everything is a Must Have

“If everything is a Must Have, the prioritisation isn’t adding value. I’d like to challenge some of these — let’s ask: ‘Could we go live without this, even with a workaround?’”

Confusing Should Have with Could Have

“A Should Have should hurt if it’s missing — users will complain or work around it. A Could Have is something users might not even notice. Which category does this really fall into?”

Won’t Have becomes forgotten work

“Let’s document the Won’t Haves in the backlog with a note: ‘Deferred to v2.’ That way we don’t lose them.”

---

Practice

Test your requirements vocabulary with the Business Analyst English exercise set and explore all BA resources in the Business Analyst learning path.