MoSCoW Prioritization: Must Have, Should Have, Could Have and Won’t Have
Make the trade-offs behind the labels explicit.
On this page
MoSCoW prioritization sorts requirements into four groups: Must Have, Should Have, Could Have and Won’t Have this time. It makes a practical distinction between what a delivery cannot work without and what can be postponed.
Its value is not the four labels. It is the agreement behind them: what the team will protect, what it can trade away and who can change that decision.
What is MoSCoW prioritization?
MoSCoW is a scope-prioritization technique used in DSDM and other project settings. Apply its categories to a named outcome and timeframe. “Must Have” for the whole project need not mean “Must Have” in its first release.
Think of the result as a conditional scope agreement, not a ranked backlog or proof that a deadline is achievable.
Visual reference. Judge categories against this delivery's purpose. Compare estimated effort, not item counts; exclude Won’t Haves from included effort. A Must Have must not rely on optional work. Labels alone do not establish capacity, a schedule or release readiness.
Text version
For one named outcome and timeframe / categories are scope decisions, not a ranked sequence or delivery guarantee
- Must Have
- Decision test: Stop delivery without it; Record the consequence: Minimum acceptance evidence
- Should Have
- Decision test: Important; a viable fallback exists; Record the consequence: Fallback, owner and cost
- Could Have
- Decision test: Useful; lower impact if deferred; Record the consequence: Benefit and deferral impact
- Won’t Have this time
- Decision test: Explicitly outside current scope; Record the consequence: Boundary and review trigger
Why does it matter?
“High priority” hides an important question: what would we actually stop the launch for? A booking service that cannot prevent overbooking and one without favorite-class shortcuts have different problems, even when both requests have enthusiastic supporters.
Useful prioritization turns those differences into decisions before a deadline is threatened. It also exposes when the proposed minimum is too large for the available resources. Relabeling work does not create capacity.
The four categories, with decision tests
| Category | Decision test for this timeframe | What to record |
|---|---|---|
| Must Have | Without it, the delivery is not viable or acceptable; stop rather than release. | The failure that blocks release and a testable minimum. |
| Should Have | Important, but a workable temporary alternative exists. | The workaround, its owner and its cost or inconvenience. |
| Could Have | Useful, with a smaller consequence if omitted. | The benefit and what happens if it is deferred. |
| Won’t Have this time | Deliberately outside the current scope. | The boundary and when or why to reconsider it. |
These are commitment categories, not customer-satisfaction categories. A feature described as “must-be” in the Kano Model does not automatically become a MoSCoW Must Have for every release. Check the intended users, delivery purpose and timeframe.
For a Should Have, “we will do it manually” is not enough detail. Name who will do it, whether they have time and how errors will be handled. An alternative that cannot actually be operated is not a credible fallback.
Start with an outcome, not a feature wishlist
Write a short scope statement before labeling requirements:
In six weeks, existing gym members can independently reserve a place in a scheduled class, and staff can rely on the class capacity limit.
This example deliberately excludes taking payments, acquiring new members and loyalty rewards. Those may matter to the business, but they are not all necessary to this release’s purpose. A product roadmap gives the wider direction; MoSCoW makes the boundary of one delivery explicit.
Define the quality and operational conditions separately. The worksheet below is not a security, accessibility, legal or release-readiness assessment. Relevant specialists still need to identify the applicable requirements. Cutting optional scope is not permission to lower essential quality.
A worked example: the gym’s six-week release
Hypothetical example. The gym and its delivery team have 30 person-days available for this release after allowing for known other commitments. They estimate the following work in the same effort unit. Each estimate includes the implementation, testing and handover needed for that row; shared work is allocated once, not counted again elsewhere.
Illustrative neighborhood gym planning scene for the hypothetical booking-release example; not a real business, project team or software demonstration.
| Requirement | Priority | Effort | Evidence or fallback |
|---|---|---|---|
| View the timetable and reserve a place | Must Have | 8 days | A member can book an available class and see the confirmed reservation. |
| Prevent reservations above class capacity | Must Have | 6 days | Two simultaneous requests for the last place cannot both succeed. |
| Staff manage schedules and capacity | Must Have | 4 days | Staff can create the classes the booking service needs. |
| Send a reminder before class | Should Have | 6 days | Reception sends a temporary daily reminder list manually. |
| Save favorite classes | Could Have | 6 days | Members can find the same class in the timetable without a shortcut. |
| Earn loyalty badges | Won’t Have this time | Not included | Revisit after observing the first release; not part of this effort total. |
The three Must Haves total 18 person-days. The included candidate scope is 18 + 6 + 6 = 30 person-days. Must Haves therefore represent 18 ÷ 30 = 60% of included estimated effort, not 60% of the number of requirements. Won’t Haves are excluded from that denominator.
The remaining 12 estimated days are valuable optional scope, not 12 days of idle time. If uncertainty consumes effort, the team has agreed what can be dropped. Completing every item is not promised.
DSDM’s typical project/increment guidance suggests keeping Must Haves to no more than about 60% of effort and retaining about 20% as Could Haves. This is a planning guideline, not a universal quota or delivery guarantee. The appropriate balance depends on the risk and confidence of the particular plan.
Thirty person-days are not thirty elapsed days. Different skills, dependencies, leave and external approvals still affect whether the work can fit into six weeks. Equal totals do not establish a feasible schedule.
What changes when the plan gets harder?
Suppose the capacity-control work turns out to need 10 days rather than 6. The total candidate scope becomes 34 days against 30 available. Must effort rises to 22 days, or about 64.7% of 34.
Dropping the 6-day favorites feature leaves 28 estimated days, including reminders. There are now 2 days of estimated headroom, but Must Haves are 22 ÷ 28 = 78.6% of the remaining included effort. The workload fits the arithmetic while the plan has become less flexible. That is a reason to revisit risk, not to celebrate a green score.
If the minimum itself no longer fits, the options are substantive: narrow the outcome, split a requirement into a smaller genuinely usable part, change the date or reassess resources. Do not rename necessary work “Should Have” merely to improve a percentage.
Challenge the hidden dependencies
In the gym example, member booking needs a timetable supplied by staff. Making staff schedule management optional would leave a Must Have dependent on work that might not ship.
Follow each essential requirement back to its prerequisites. Either protect the prerequisite, or redesign the solution around a credible alternative. Also check suppliers, approvals, data and operational preparation, not just software features.
For example, email reminders might depend on an external provider’s approval. If approval is uncertain, record it as a delivery risk. A category label cannot bring the approval forward.
The worksheet records one critical dependency per item to keep the exercise small. It flags obvious Must-to-optional conflicts and cycles in those recorded links. It is not a complete dependency model or scheduling engine.
Resolve disagreements with consequences
Imagine the gym owner calls reminders a Must Have because attendance matters. The receptionist says a manual list is manageable for the first two weeks. Instead of voting on the label, ask:
- What concrete result fails without automated reminders?
- Can reception reliably operate the alternative for this release’s volume?
- What extra time or errors would make that alternative unacceptable?
- Who has authority to accept the temporary cost?
If the workaround is acceptable, reminders can remain a Should Have with an owner and review date. If it is not, update the scope, effort and delivery decision together. Record unresolved disagreement rather than pretending a workshop produced consensus.
Control new requests without freezing learning
A new request is not automatically rejected, and it is not added for free. Record its reason, estimate, dependency effects and proposed trade-off. The decision owner should be able to say:
We are adding X because of this evidence. We are deferring Y, or changing the date/resources, and we accept these consequences.
Keep the earlier decision in the project record and communicate the new boundary. “Won’t Have this time” should have a reconsideration trigger, not become a forgotten promise that it will definitely ship next.
MoSCoW, RICE and a roadmap answer different questions
| Approach | Main question | What it does not establish |
|---|---|---|
| MoSCoW | What is essential, optional or excluded in this timeframe? | An exact order within a category or a feasible schedule. |
| RICE prioritization | How do candidate options compare on reach, impact, confidence and effort? | Which operational or release conditions are non-negotiable. |
| Product roadmap | Which outcomes and directions matter across time horizons? | A fixed promise to deliver every listed feature. |
Use evidence to compare alternatives, then make the current delivery commitment explicit. Avoid assigning precise-looking scores to obligations just to make them compete with optional polish.
Common mistakes and limitations
- Counting items instead of effort. Three small Could Haves do not offset one enormous Must Have.
- Bundling essentials with extras. “Booking system” may hide a basic reservation flow, advanced analytics and decorative features with different priorities.
- Calling everything a Must Have. If every item really is essential, acknowledge the fixed scope and manage date, resources and risk accordingly.
- Leaving the workaround unowned. A manual process needs staff time, access and a way to detect mistakes.
- Treating “fits” as “will finish.” Rough estimates do not prove staffing, sequence or approval dates.
- Confusing exclusions with commitments for later. Reconsideration is not guaranteed future delivery.
MoSCoW structures judgment; it does not remove politics, validate customer demand or calculate business value. Two teams can classify the same feature differently because their objectives and constraints differ. Make those assumptions visible enough to challenge.
Put it to work: agree one delivery boundary
Use 25 minutes for a first pass, not a complete delivery plan. Choose one outcome, a date and the person authorized to resolve trade-offs. List up to 12 concrete requirements. For each, record its category, consequence of omission, acceptance evidence, owner and one critical dependency if relevant.
Add comparable effort estimates and available capacity in person-days. Mark the source and uncertainty of the estimates in the decision notes; do not substitute guessed precision for missing evidence. Challenge the Must Haves, test a delay or overrun, and finish with one decision or evidence-gathering action and a review point.
Must Have (0)
Should Have (0)
Could Have (1)
- Untitled requirement
Won’t Have this time (0)
Add positive, comparable effort estimates for all included requirements to calculate totals. Missing effort is not zero.
Before downloading (13 checks)
- Outcome: add the missing context.
- Timeframe: add the missing context.
- Decision owner: add the missing context.
- Evidence, uncertainty and next decision: add the missing context.
- Review point: add the missing context.
- Capacity: enter positive person-days, up to 100,000, with at most two decimals and no separators.
- Identify a minimum deliverable with at least one Must Have.
- Item 1: record the requirement.
- Item 1: record the reason / fallback / exclusion.
- Item 1: record the acceptance evidence or exclusion boundary.
- Item 1: record the owner.
- Item 1: enter positive person-days, up to 100,000, with at most two decimals and no separators.
- Confirm the scope, effort unit and recorded dependency review yourself; the example is not pre-approved.
Quick checklist
Final takeaway
MoSCoW works when it changes an actual decision. Protect the smallest acceptable outcome, name realistic fallbacks, estimate the effort and agree who can trade scope when conditions change.
The useful output is not a board full of labels. It is a minimum delivery people can explain, optional work they are genuinely willing to defer and an honest boundary around this release.