Apply MoSCoW to a defined release: Must requirements make it viable, Should requirements are important with workable alternatives, Could requirements provide removable scope, and Won’t items are explicitly excluded this time. Check effort, dependencies, and acceptance—not just the number of cards in each category.
Use MoSCoW to define what a release must deliver
MoSCoW separates requirements into Must Have, Should Have, Could Have, and Won't Have this time. The categories refer to a defined delivery period. A Must is necessary for a viable release; a Should is important but has an acceptable workaround; a Could is desirable with less consequence if omitted. Won't records an explicit exclusion for this period, not a promise to build it later.
The Agile Business Consortium's guidance connects the method to protecting a viable scope when time and capacity are constrained. The practical question is not how strongly a stakeholder likes a feature. It is what happens to the intended release if that requirement is missing.
This worked example follows a community center launching registration for a free event in six weeks. Its illustrative delivery budget is 20 person-days; the requirements, estimates, and checks below show how to turn that limit into a release plan.
State the release boundary before sorting the list
The event has 40 places, costs nothing to attend, and requires one reservation per person. Organizers need to see the current attendee list. Participants need to find the event, reserve an available place, know whether the reservation succeeded, and cancel if they cannot attend.
The release is not a general event-management platform. Paid tickets, recurring events, and group bookings are outside this period. Naming those exclusions prevents the registration discussion from silently expanding into payments, subscription schedules, or seat-allocation rules.
Quality requirements belong inside the delivery work. The team includes its agreed accessibility, privacy, authorization, and reliability acceptance checks in the estimates for the relevant flow. It does not create optional 'security later' or 'accessibility if time remains' cards to make the numbers fit.
| Decision | Agreed scope | Consequence for prioritization |
|---|---|---|
| Date | Registration opens in six weeks | Priorities apply to this release |
| Capacity | 40 available places | The reservation flow must not overbook |
| Payment | Free event | Payment processing is outside scope |
| User journey | Find, reserve, confirm, and cancel | A list of screens is insufficient without an end-to-end outcome |
| Organizer need | See the current attendee list | Authorized access is part of that requirement |
| Effort available | 20 person-days across the delivery team | Include design, implementation, and verification work |
Test each Must against a concrete failure
The event-information page is a Must because a participant needs the date, location, and availability before reserving. The reservation operation is a Must because the release has no purpose if a person cannot obtain a place. Confirmation and cancellation are also required in this example's agreed journey: users need a reliable outcome, and cancellations must make places available again.
A calendar download is useful, but the confirmed date and location are already available in the confirmation. Its absence does not make the service unusable. An automatic reminder matters more to the organizer, yet a named coordinator can send reminders from the attendee list for this one event. That makes the automation important without making it essential to launch.
A proposed workaround must be real. 'Someone can do it manually' is not a plan if no one has capacity, access, or responsibility. Record who would do the work and whether they accept it. If the workaround is infeasible, revisit the classification rather than pretending the risk disappeared.
| Requirement and estimate | Priority for this release | Reason or workable alternative |
|---|---|---|
| Event details and availability: 3 days | Must | Participants need the date, location, and whether places remain |
| Reserve a place without overbooking: 4 days | Must | This is the core transaction and capacity promise |
| Confirm, retrieve, and cancel a reservation: 3 days | Must | A clear result and cancellation path are part of the agreed journey |
| Authorized organizer attendee list: 2 days | Must | The event team must know who has a place |
| Automatic reminder: 2 days | Should | Coordinator can send an agreed manual reminder for this event |
| Automated waitlist: 2 days | Should | Coordinator can maintain and contact a manual waiting list |
| Calendar download: 2 days | Could | Participants can add the confirmed details to their own calendar |
| Saved display preferences: 2 days | Could | The default presentation remains usable |
| Paid tickets, recurring events, group booking | Won’t this time | They are outside the free, single-event release boundary |
Check effort, not the number of cards
The four Must requirements total 3 + 4 + 3 + 2 = 12 person-days. The two Shoulds total 4 days, and the two Coulds total 4 days. The planned candidate scope is therefore 20 days: 60% Must, 20% Should, and 20% Could by effort. Counting four Must cards out of nine rows would answer a different question and would incorrectly include excluded work.
The Consortium gives typical project guidance of no more than about 60% Must effort and around 20% Could effort to preserve flexibility. This example happens to match that pattern. The percentages are planning guidance, not evidence that the estimates are correct or that delivery is guaranteed.
Do not invent low-value work just to improve the ratio. If the real viable scope consumes almost all available effort, the release has little flexibility. The response is to examine scope, capacity, dependencies, or the date—not relabel an essential requirement as optional while still expecting it to ship.
| Category | Estimated effort | Share of included scope |
|---|---|---|
| Must | 12 person-days | 60% |
| Should | 4 person-days | 20% |
| Could | 4 person-days | 20% |
| Included total | 20 person-days | 100% |
| Won’t this time | Excluded from this release estimate | Not part of the percentage denominator |
Replan when a necessary task grows
During implementation planning, the team discovers that the capacity-handling work needs one additional person-day. Must effort rises from 12 to 13. Keeping every optional item would now require 21 days against the same 20-day capacity. A priority label does not create the missing day.
The team removes the two-day saved-display-preferences item from this release. The revised planned work is 13 Must + 4 Should + 2 Could = 19 person-days, leaving one day of unallocated capacity. Calendar download remains conditional. The team records that this consumes some of the original flexibility and reviews the remaining Must risk.
The revised Must share of the 19 days of included work is about 68.4%; it is 65% of the 20-day capacity. These are different denominators. Reporting only the more favorable number would hide the tradeoff. The team has not regained the original 60% balance; it has made a specific scope decision and must still judge whether the remaining delivery risk is acceptable.
| Item | Before | Revised decision |
|---|---|---|
| Must work | 12 days | 13 days; essential capacity handling retained |
| Should work | 4 days | 4 days; manual workarounds remain documented |
| Could work | 4 days | 2 days; saved preferences removed |
| Total included work | 20 days | 19 days |
| Available capacity | 20 days | 20 days, with 1 day unallocated |
| Must share | 60% of included scope | About 68.4% of included scope; 65% of capacity |
Make acceptance and dependencies visible
A Must requirement needs a checkable outcome. For reservation capacity, the team verifies that two people competing for the final place cannot both receive confirmed bookings. For cancellation, it verifies both the participant's visible result and the organizer's current list. These checks express the requirement more clearly than a card titled 'booking page.'
Check whether a Must secretly depends on optional work. If confirmation requires the attendee list to exist, that dependency belongs in the essential delivery path. If a calendar file is only an enhancement to confirmation, its absence should not prevent the confirmation itself from working.
The release review uses the agreed journey and acceptance checks. It does not treat a high count of completed Could cards as compensation for a missing Must. If the viable release cannot be delivered, the team raises that decision explicitly rather than publishing an incomplete journey under a favorable completion percentage.
| Requirement | Checkable outcome | Dependency or condition |
|---|---|---|
| Availability | A participant can see whether a place is available | Uses current capacity information |
| Reservation | Only one confirmed booking is created for the final place | Capacity enforcement is essential, not a later enhancement |
| Confirmation and retrieval | The participant can identify the confirmed event and reservation | A decorative calendar download is not required |
| Cancellation | The participant sees cancellation and the place becomes available | Organizer list reflects the current state |
| Organizer list | An authorized organizer sees confirmed attendees | Required access protections are included |
Use a small decision record to prevent scope from drifting back
Write down the requirement, priority, reason, estimate, workaround, and owner. For a Won't item, state the current time boundary and what would justify reconsidering it. Do not imply that a deferred item is automatically promised for the next release.
When a stakeholder asks to add paid tickets halfway through this example, the team can point to the free-event boundary and assess a new decision explicitly. It does not quietly attach payment work to the existing reservation card and preserve the old estimate.
The useful output of MoSCoW is a release the team can explain: the smallest viable outcome, the important work it hopes to include, the scope it can remove, and the items everyone agrees are outside this period. The categories become meaningful when the delivery decisions follow them.
| Field | Fill in | Decision check |
|---|---|---|
| Release and outcome | [Date or increment] / [usable outcome] | Is the time boundary explicit? |
| Requirement | [Specific behavior or result] | Can completion be observed? |
| Priority and reason | [Must / Should / Could / Won’t] / [consequence of omission] | Is the category supported by the actual consequence? |
| Effort and dependencies | [Person-time] / [required work] | Does an essential item depend on optional scope? |
| Workaround | [What, who, and capacity] | Has the responsible person accepted it? |
| Acceptance | [How the outcome will be checked] | Are essential quality requirements included? |
| Change decision | [Owner, scope tradeoff, review trigger] | What leaves the plan if new work enters? |