MoSCoW
Classify your requirements as Must, Should, Could and Won't. Dai Clegg's MoSCoW method to protect the essential when time is tight.
Description
The MoSCoW method is a prioritization technique created by Dai Clegg (Oracle UK, 1994) that classifies project requirements into four categories (Must have, Should have, Could have, Won't have this time) to focus effort on the highest-value features within a fixed timeframe. Published in CASE Method Fast-Track: A RAD Approach (Addison-Wesley, 1994, co-authored with Richard Barker), it was later standardized by the DSDM consortium (now Agile Business Consortium) starting in 2002. Your sprint starts Monday, your backlog contains 40 items, and your team delivers 15 per sprint. Who decides which ones make the cut? Without a shared framework, MoSCoW prioritization answers that question with a logic anyone can grasp in five minutes. A Must have is something without which the product does not work: if you are building an e-commerce site, the shopping cart is a Must have. A Should have delivers significant value but does not block the release: advanced search filters. A Could have would be nice if time permits: personalized recommendations. A Won't have this time is explicitly deferred, not forgotten. MoSCoW prioritization works like a field surgeon's triage: you save the critical cases first, then treat the important ones, then the secondary ones if resources allow. DSDM recommends a precise rule: Must haves should not exceed 60% of the total estimated effort, leaving a 40% buffer split between Should and Could. This buffer protects your Must haves in case of overruns. Unlike scoring frameworks such as RICE or ICE that produce a continuous numerical ranking, the MoSCoW method forces a categorical, binary decision: it is essential or it is not. That simplicity is its strength in contexts where decision speed matters more than analytical granularity.
Objectives
- Prioritize features
- Prioritize work
- Improve team collaboration
Used by
- -Oracle UK (company of origin where Dai Clegg created the MoSCoW method in 1994)
- -BBC (uses the MoSCoW method in its digital projects to prioritize requirements under time constraints)
- -Spotify (applies MoSCoW alongside its agile processes for scope decisions at the squad level)
Advantages
- Decision in 5 minutes per item. Binary categorization (essential or not) eliminates endless scoring debates.
- Critical scope protection. The 60% rule guarantees your Must haves will be delivered even if estimates are optimistic.
- Universal language. "Is it a Must or a Should?" is understandable by everyone, from developer to CEO.
- Ideal for agile timeboxing. The MoSCoW method is designed for fixed deadlines where scope must adapt to time, not the other way around.
Limitations
- No granularity in ranking. Two Must haves have the same status even if one is 10x more critical than the other. For fine-grained ranking, use RICE or ICE as a complement.
- Subjectivity in categorization. What is Must for the PM may be Should for the Tech Lead. The collective workshop mitigates this bias but does not eliminate it.
- Does not capture effort. MoSCoW says what to do, not how much it costs. Combine with effort estimates to avoid a sprint with 15 impossible Must haves.
- Risk of "everything is Must have". If stakeholders classify 80% of items as Must, the method loses its usefulness. Apply the 60% rule without exception.
How to apply MoSCoW
- 1
List all requirements in the scope
Empty your backlog, customer requests, technical constraints, and team ideas into a single list. Each item should be formulated as a concrete need, not as a technical solution. Aim for 15-40 items. Beyond that, segment by theme or release. Output: an exhaustive list visible to all stakeholders.
- 2
Define the time constraint (timebox)
The MoSCoW method works within a fixed time frame: sprint, release, quarter. The date is immovable; the scope adjusts. Without this constraint, the distinction between Must and Should loses its meaning. Set the delivery date and the team's available capacity. Output: a clear timebox with estimated capacity in days/points.
- 3
Categorize each requirement in a collective workshop
Gather PM, Tech Lead, Designer, and 1-2 business stakeholders. For each item, ask: "If we do not deliver this within this timebox, what happens?" If the answer is "the product does not work" or "we lose customers," it is a Must have. If it is "that's unfortunate but we survive," it is a Should or Could. If it is "not now," it is a Won't. Debate for 2 minutes per item, no more. Output: each item classified into one of the 4 categories.
- 4
Verify the 60% rule
Calculate the total effort of the Must haves. If it exceeds 60% of your capacity, you have too many Must haves. Downgrade the least critical items to Should have. This 40% buffer is not waste, it is your quality insurance: it absorbs unforeseen events, bugs, and optimistic estimates. Output: validated distribution respecting the 60/20/20 rule.
- 5
Plan execution by priority
Start with the Must haves. They are non-negotiable and must be completed first. Then move to Should haves. If time remains, tackle the Could haves. If a Must have takes longer than expected, sacrifice a Could have, never another Must have. Output: ordered execution plan with identified dependencies.
- 6
Document the Won't haves with justification
Won't have is not a trash bin. Each rejected item must have a written justification and a reconsideration timeline (next sprint, next release, Q3). Share this list with stakeholders to avoid "but I thought we agreed to it." Output: documented and shared Won't have list.
- 7
Revisit the categorization at each sprint/release
A Should have from this sprint can become a Must have in the next one if the context changes (user feedback, competitive pressure, regulatory constraint). Revisit your categorization at the beginning of each cycle. Output: updated categorization with justifications for changes.