MoSCoW Prioritisation
Ruthlessly sort requirements into four buckets
MoSCoW is a straightforward requirements prioritisation technique that categorises every item into four buckets: Must Have (critical for viability), Should Have (important but not critical), Could Have (nice to have), and Won't Have this time (explicitly out of scope for this release). Its simplicity makes it ideal for stakeholder alignment sessions and scope negotiation in fixed-time, fixed-cost projects.
Developed by Dai Clegg at Oracle in 1994. Named as an acronym: Must Have, Should Have, Could Have, Won't Have. Became a core component of DSDM (Dynamic Systems Development Method).
Use MoSCoW Prioritisation when
- ✓Release planning where you need to negotiate scope with stakeholders under time pressure
- ✓Fixed-scope contracts or projects with hard deadlines where scope must be explicitly controlled
- ✓Stakeholder workshops where you need rapid agreement on what is and isn't in scope
- ✓Projects using DSDM where MoSCoW is a core framework component
Avoid it when
- ✗Long-horizon roadmap planning where relative comparison matters more than binary bucketing
- ✗Technical debt or infrastructure work where Must/Should/Could distinctions are unclear
- ✗Teams that need to compare items within the same category (use RICE or weighted scoring instead)
Key Concepts
Non-negotiable requirements. Without these, the solution is not viable. Estimated at ≤ 60% of available budget/time.
Important but not critical. Can be deferred to a next release without breaking the solution.
Nice to have but not a priority. Included only if budget and time allow.
Explicitly out of scope for this release. Prevents scope creep by making exclusions as explicit as inclusions.
MoSCoW works best within a fixed timebox. Must Haves define the minimum viable delivery; the rest flex.
Must Haves should never exceed 60% of available capacity. If they do, reprioritise — some 'musts' are actually 'shoulds.'
How it works
List all candidate features, requirements, or user stories for the scope negotiation session.
Stakeholders and the team assign each item to M, S, C, or W. The PM facilitates. Disagreements surface valuable scope negotiation.
Verify Must Haves represent ≤ 60% of capacity. If not, challenge each item: "Would the release fail without this?" If no, it's a Should.
Document the MoSCoW classification and get explicit sign-off. Won't Haves are as important to document as Must Haves.
Tools that support MoSCoW Prioritisation
Industry standard for software development teams — most PMs will encounter Jira in their career
Exceptionally intuitive and visually clean interface — one of the lowest onboarding friction tools for non-technical teams
Highly visual and intuitive interface with color-coded boards — one of the easiest PM tools for non-technical teams to adopt
All-in-one platform replacing multiple tools — docs, whiteboards, goals, time tracking, chat, and project management in a single workspace
Unmatched flexibility as an all-in-one workspace — combines docs, wikis, databases, and project management in a single tool
Spreadsheet-familiar interface makes adoption easy for teams transitioning from Excel — minimal training needed for basic use
Extremely intuitive drag-and-drop Kanban interface — virtually zero learning curve, new users productive within minutes
Browser-based with no installation required — runs on any OS and enables instant sharing via URL, removing friction for cross-functional collaboration with PMs, engineers, and stakeholders
Frequently Asked Questions
No more than 60% of available time or budget. If Must Haves take 80% of capacity, there is no buffer for the unexpected — and something unexpected always happens. Forcing that discipline surfaces the real priorities.
A ranked list implies everything will be done in order. MoSCoW makes explicit commitments: Must Haves are guaranteed; Won't Haves are explicitly excluded. The team and stakeholders align on what 'done' means before work starts, not after.
Yes. Apply MoSCoW at the start of sprint planning to classify backlog items for the sprint. Must Haves fill the sprint capacity target; Should and Could Haves provide overflow if the team runs ahead. It's particularly useful when sprint scope is being negotiated with multiple stakeholders.