MoSCoW prioritization
Definition
MoSCoW prioritization is a requirement classification technique that sorts work into four categories — Must have, Should have, Could have, and Won't have — to align stakeholders on the minimum viable scope and help teams make explicit trade-off decisions under time or budget constraints.
MoSCoW was developed by Dai Clegg at Oracle in 1994 and is part of the Dynamic Systems Development Method (DSDM) agile framework. The acronym uses uppercase letters for the categories: Must have, Should have, Could have, Won't have — with lowercase 'o's added to make it pronounceable.
The four categories:
- Must have (M): Non-negotiable requirements. Without these, the product cannot be released. If a Must have cannot be delivered, the release fails. Typically: core functionality, legal/compliance requirements, safety-critical items.
- Should have (S): Important but not critical. These add significant value and should be included if at all possible, but the product can ship without them if time or capacity runs short.
- Could have (C): Nice to have. These are desirable features with smaller impact. Include them if there's capacity after Musts and Shoulds are complete.
- Won't have (W): Explicitly out of scope for this release. Often called "Would like to have but not this time." The Won't have category is as important as the others — it gives stakeholders the explicit acknowledgment that their request has been heard and deliberately deferred.
When to use MoSCoW:
- Sprint planning to negotiate scope with a Product Owner
- Release planning to define what constitutes a shippable increment
- Discovery workshops to align business and engineering on trade-offs
- Feature prioritization with multiple stakeholders who each want their item first
MoSCoW works well on a whiteboard — the four quadrants are clear, and sticky notes move between categories as the conversation evolves. BoardSnap AI captures the resulting priority map as structured output.
Examples
- Release planning: 12 features categorized — 4 Must, 5 Should, 2 Could, 1 Won't. Team commits to the 4 Musts
- Sprint planning workshop uses MoSCoW on a whiteboard to reduce a 20-story sprint backlog to a realistic 12
- Stakeholder alignment session — engineering and product each categorize the same feature list, then compare results
- Won't have category explicitly records the three features the sales team requested that are deferred to Q3
- Discovery workshop produces a MoSCoW board photographed with BoardSnap, shared with the wider org as the scope baseline
Snap a moscow prioritization. Ship its actions.
BoardSnap turns any whiteboard — including this one — into a summary and action plan.