When everything is essential, nothing is a tradeoff
Pine Repairs wants a booking pilot with live slots, rescheduling, saved preferences, and a loyalty scheme. Every request has a good story. The team has one delivery window. To make a real commitment, it needs to distinguish “customers cannot complete the pilot’s purpose without this” from “we would like this too.”
Pine Repairs is a hypothetical service business planning a booking-portal pilot for a small customer group. Requirements, capacity constraints, workarounds, and choices below are invented.
MoSCoW groups requirements into Must Have, Should Have, Could Have, and Won’t Have this time. The Agile Business Consortium describes the method in the DSDM delivery approach. It helps stakeholders agree scope within a defined timeframe.
Ask what would happen if each item were missing
A booking must be confirmed without double booking, and staff must see it. Those requirements protect the pilot’s basic purpose. Self-service rescheduling is different: for a small trial, staff may accept changes by phone if they genuinely have capacity.
That workaround is a condition, not a clever excuse for omitting work. If phone changes become unmanageable, the rescheduling decision must be reopened. The first board records scope for this pilot window; it does not rank the features for all future releases.
What each commitment means
Read the groups within one delivery window. They are categories, not four steps through which each requirement progresses. Won’t Have this time records an agreed exclusion; it does not mean the idea has no value forever.
Must Have means that the delivery would not be viable without the requirement. Ask whether there would still be a usable outcome if it were absent. A genuine workable alternative is a reason to challenge the Must label.
Should Have is important, but the outcome can remain viable without it, perhaps with a difficult temporary workaround. Could Have is desirable but has less impact if omitted. Won’t Have this time makes an exclusion explicit for the agreed window.
These meanings follow the Consortium’s guidance. The review prompts and fictional release below show FrameworkWorld’s suggested application, rather than a complete DSDM implementation.
Capacity makes the categories credible
If every item is a Must, the exercise has documented demands without producing flexibility. A label cannot create engineering time, resolve a dependency, or reduce testing effort.
Estimate work at a level sufficient to discuss feasibility. Include integration, acceptance, and operational readiness rather than counting only visible features. Do not use the number of requirements as a substitute for effort: one requirement can contain more work than several others combined.
Check dependencies in the same review. If a Must depends on another requirement, either that supporting work must be secured or the proposed delivery needs redesign. Leaving the dependency as an optional item makes the apparent commitment misleading.
Ask what happens if the item is missing
The difference between Must and Should is not how strongly someone argues. It is whether the agreed delivery remains viable without that requirement.
For the fictional booking pilot, preventing double bookings supports viability. A portal that confirms the same slot to two customers would fail its central promise. Self-service rescheduling might be a Should if staff can manage a small number of changes by phone.
That workaround must be real. Name who would handle the calls, whether they have time, and what customers would experience. A theoretical alternative that nobody can operate does not establish viability.
A Could provides flexibility when capacity tightens. It remains a legitimate idea; it simply has a lower consequence of omission in this window. Won’t Have records an agreed boundary so an excluded item does not reappear as an assumed promise halfway through delivery.
Dependencies can alter the discussion. A visible Must may rely on an unglamorous integration or permission check. The supporting work needs to be secured even if no stakeholder would describe it as an exciting feature. Split the requirement or redesign the delivery if necessary, rather than hiding the dependency in a lower-priority column.
Pressure-test Pine’s minimum booking promise
The team agrees that customers must be able to choose an available slot, receive confirmation, and avoid booking a slot someone else has already taken. Staff must be able to see those confirmed appointments. Without these capabilities, the proposed pilot would not function as agreed.
Self-service rescheduling is a Should Have because staff can handle a limited pilot’s changes by phone. The operations lead accepts that workaround and its workload. Saved preferences are a Could Have. A loyalty scheme is Won’t Have this time.
An estimate reveals that the first design for live slot availability would exceed capacity. The team does not simply reclassify double-booking prevention as optional. It narrows the pilot to a smaller set of controlled slots and checks that the revised design still meets the acceptance criteria.
If staff cannot support phone changes, the rescheduling priority needs another discussion. A workaround is evidence of viability only while someone can actually perform it.
Make the scope agreement visible
| Pilot requirement | Category | Reason for this window |
|---|---|---|
| Confirm a slot without double booking | Must | The booking outcome is not viable otherwise |
| Let staff see confirmed appointments | Must | Staff need the information to deliver the service |
| Customer self-service rescheduling | Should | Staff accept a temporary phone workaround |
| Saved preferences | Could | Helpful convenience with lower omission impact |
| Loyalty scheme | Won’t this time | Outside the agreed pilot outcome |
The classifications belong to the hypothetical Pine Repairs pilot. They are not universal priorities for every booking system. A larger rollout with no phone support could make rescheduling essential.
Now pressure-test the agreement. Suppose the team loses capacity during the pilot build. It first checks whether a smaller controlled set of slots can preserve the booking promise. It does not remove double-booking prevention merely because that work became difficult.
If the viable minimum still cannot fit, the decision returns to scope, time, or resources. Reclassifying the same work with more optimistic labels does not create capacity.
A new request also needs an explicit exchange. If a stakeholder adds another Must, ask what leaves, what changes in the outcome, or what extra resource is genuinely available. Record the decision so a quiet addition cannot become a surprise commitment.
At the review date, compare the actual delivery with the agreed categories and the assumptions behind them. If the phone workaround overloaded staff, that is evidence for changing the next window’s plan. It is not proof that the original labels should be treated as permanent product rankings.
Shrink the design while protecting the outcome
When the first live-availability design exceeds capacity, Pine tries a smaller controlled set of slots. It keeps the confirmation and double-booking requirements. Changing the implementation or scope can be legitimate; renaming an essential outcome “Could” does not make the pilot viable.
The next check is whether staff can deliver the workaround and customers can complete the booking. If the minimum still cannot fit, the team must change scope, time, or resources. It should record that decision before the deadline turns an impossible promise into somebody’s emergency.
Agree the delivery boundary
- Name the delivery outcome, date, and people who will accept it. Record the resources and dependencies assumed to be available.
- Break broad wishes into requirements with observable acceptance criteria. Separate an essential capability from optional convenience.
- For each proposed Must, ask what would happen without it and whether a workable alternative exists. Record the reason for the label.
- Compare Should and Could items by the consequences of omission. Involve those who would operate any workaround.
- Review estimated effort against available capacity. Reduce scope or renegotiate the delivery if the viable minimum does not fit.
- Publish the four groups together. Agree who may change a priority and what tradeoff a new Must would require.
- Revisit priorities when evidence changes. Keep earlier decisions visible so a quiet addition does not become an unacknowledged promise.
Stop treating the plan as committed if a critical dependency is unresolved. Escalate the choice between a smaller viable release and a different delivery window.
Limits and alternatives
MoSCoW does not rank every requirement within a group or calculate the return from a feature. Labels can also hide power differences when the loudest stakeholder declares everything essential. Require a reason connected to the delivery outcome and let delivery and operations colleagues challenge feasibility.
Avoid presenting Should and Could as guaranteed scope. Explain their delivery uncertainty before stakeholders build dependent plans around them.
RICE Prioritization compares candidate work using reach, impact, confidence, and effort. Use it when you need a more explicit comparison before negotiating a release boundary.
Kano Model investigates how customers respond to an attribute’s presence and absence. A Kano basic need is not automatically a Must for every timebox; connect customer evidence to the outcome of this particular delivery.
Sources and further reading
- Agile Business Consortium, What is MoSCoW Prioritization?, May 28, 2026, accessed October 21, 2026. Official guidance on the four categories and their use in delivery. This article is an independent explanation, not an affiliated training resource or a substitute for the Consortium’s materials.