MoSCoW was developed by Dai Clegg at Oracle UK in the 1990s and formalized as part of the Dynamic Systems Development Method (DSDM) agile framework. The name is an acronym: Must have, Should have, Could have, Won't have — with the letters "ow" added to make it pronounceable.
Unlike RICE or ICE scoring, MoSCoW is a categorical framework rather than a numerical one. It does not rank features against each other — it sorts them into four discrete buckets that define what ships in a specific release. This makes MoSCoW most valuable as a scope definition tool and a stakeholder communication tool rather than a backlog prioritization tool.
The most common MoSCoW mistake is treating all features as Must haves. When everything is Must have, nothing is prioritized — the category loses meaning, and the release scope becomes the entire backlog. Effective MoSCoW practice limits Must haves to the features without which the release is not viable. A useful test: if you removed this feature from the release, would you delay the launch? If yes, it is a Must have. If no, it is at most a Should have.
The Won't Have category is as important as Must Have — it is the primary tool for preventing scope creep. By explicitly naming what is not being built in this release (rather than leaving it unstated), MoSCoW creates a record of deliberate decisions. When a stakeholder asks "why isn't X in this release?" the Won't Have list is a better answer than "we didn't get to it."
MoSCoW vs RICE vs Kano
MoSCoW: Categorical — sorts features into Must/Should/Could/Won't for a specific release. Best for scope definition and stakeholder communication. Does not rank within categories. Best used after RICE or ICE has ranked the backlog, to define what goes into the next release from the top of the ranked list.
RICE scoring: Quantitative — produces a ranked list of all features by expected impact per unit of effort. Best for backlog prioritization across many features. Does not define release scope — gives you a ranked list from which you then scope a release using MoSCoW.
Kano model: Categorical by type of customer satisfaction — Basic (expected), Performance (linear), Excitement (delighter). Best for understanding which features create genuine delight vs. table stakes. Used strategically rather than for sprint-level scope definition. Complements MoSCoW by helping categorize which Should Haves might be Excitement features worth prioritizing higher.
These three frameworks are complementary, not competing: use RICE to rank the backlog, MoSCoW to scope the release, and Kano to inform long-term strategy.
How to Use MoSCoW Method in Product Management
Running a MoSCoW session for a release:
- Start with the full feature list for the release candidate — everything that could potentially ship.
- Apply the Must Have test: Would removing this feature delay the launch? Is the release unusable without it? If yes: Must Have. The Must Have list should be small — if it represents more than 60% of the feature list, you are over-committing.
- Identify Should Haves: Important features that significantly improve the release quality but are not launch-blocking. The release ships without them but is materially weaker. These are the candidates to cut if the sprint is running late.
- Identify Could Haves: Nice-to-haves that require minimal engineering effort. Include if time permits without risking the Must Haves and Should Haves. Cut first if the sprint is running over.
- Explicitly name Won't Haves: The most tempting extensions of the feature set that are not in scope for this release. Name them explicitly — "Mobile push notifications: Won't Have in this release." This document serves as the reference when stakeholders ask why X was not included.
Do this exercise with the tech lead, not solo. Engineers often have strong views on what is and is not launch-blocking from a technical dependency perspective — the backend service required for a Should Have feature might also be required for a Must Have, making the Should Have effectively a Must Have in disguise.
MoSCoW Method Examples
1MoSCoW for a notification feature release
Must Have: In-app status change notifications with real-time delivery; Slack notifications for Slack-connected workspaces; notification preferences (on/off per notification type). Should Have: Email digest option; per-user notification preferences (currently only workspace-level); notification history view. Could Have: Notification grouping (multiple status changes in one message); custom notification message templates. Won't Have this release: Mobile push notifications; third-party notification forwarding (PagerDuty, etc.); approve-from-Slack action buttons; notification snooze.
2MoSCoW for a pricing and billing change
Must Have: Annual billing option with 20% discount; seat selector on Pro and Team plan checkout; successful Stripe integration with new price IDs; seat-based billing logic in the backend; updated pricing page UI. Should Have: Prorated upgrades mid-billing-cycle; team seat management UI (add/remove seats without canceling); invoice download for past charges. Could Have: Credit card update flow within the app (currently requires Stripe customer portal); upcoming invoice preview. Won't Have this release: Multi-currency billing; invoice customization; purchase orders for enterprise; billing admin role separate from workspace owner.
3Using MoSCoW to handle a late-sprint scope challenge
Sprint week 3 of 4: the Should Have 'notification preferences per user' feature is behind schedule due to unexpected complexity in the data model. The tech lead flags it will take 3 additional days. Decision using MoSCoW: (1) Confirm it is a Should Have (not a Must Have) — launch is not blocked without user-level preferences, workspace-level defaults cover 80% of use cases. (2) Move it to the Could Have column for this release. (3) Document the decision in the sprint notes. (4) Add it as a top-priority Should Have for the next sprint. Launch proceeds on schedule without it.
How Scriptonia Automates This
Scriptonia's PRD template includes an explicit Feature Scope section with an In Scope list and an Out of Scope list — the functional equivalent of MoSCoW's Must Have and Won't Have categories. When you generate a PRD, Scriptonia populates these sections based on the feature description, flagging the most common scope creep risks for the feature type.
For teams running formal MoSCoW sessions, the Scriptonia PRD's out-of-scope list serves as the Won't Have input — features explicitly named in the PRD as out of scope become the starting point for the release-level Won't Have list. This creates a direct connection between the feature spec and the release scope decisions.