MoSCoW is a prioritization technique used in software development, management, business analysis, and project management to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement.
MoSCoW stands for:
- M - Must have: Critical requirements that must be delivered
- S - Should have: Important but not vital requirements
- C - Could have: Desirable but not necessary requirements
- W - Won't have (this time): Requirements agreed as lowest priority or out of scope
The interstitial Os are added to make the word pronounceable.
Developed by Dai Clegg in 1994 for use in rapid application development (RAD). First used extensively with the dynamic systems development method (DSDM) from 2002.
MoSCoW is often used with timeboxing, where a deadline is fixed so that the focus must be on the most important requirements.
Commonly used in agile software development approaches such as:
- Scrum
- Rapid application development (RAD)
- DSDM (Dynamic Systems Development Method)
In Agile product management, where priorities can shift quickly, MoSCoW offers the flexibility to adapt while keeping the team focused, allowing for iterative development with high-priority features tackled first and lower-priority items deferred if timelines or resources change.
- Helps teams categorize and prioritize tasks or features
- Encourages alignment through collaborative decision-making
- Provides clear communication with stakeholders
- Placing initiatives in the "will-not-have" category helps prevent scope creep
- Creates realistic expectations about deliverables
- Manages stakeholder expectations
- Ensures resources are allocated efficiently
- Helps meet deadlines with clear priorities
- Keeps project scope clear
- Particularly useful for teams working under tight timelines or budgets
- Creates social accountability
- Builds trust since nothing's hidden
- Everyone sees what's prioritized and why
- Gather all requirements or features
- Collaborate with stakeholders to categorize each item
- Ensure "Must have" items are truly critical
- Balance "Should have" and "Could have" based on resources
- Be explicit about "Won't have" to manage expectations
- Review and adjust as project evolves