01 / UNDERSTAND
What is moscow prioritization?
MoSCoW prioritization groups requirements into Must have, Should have, Could have and Won’t have this time. It supports a conversation about what is essential within a specific delivery period and what can change.
A Must is necessary for a viable outcome. A Should is important but can be temporarily omitted with an acceptable workaround. A Could has a smaller omission cost. A Won’t is explicitly outside the current scope, not necessarily rejected forever.
Why use MoSCoW Prioritization?
Labels such as high priority can hide incompatible expectations. MoSCoW makes the consequence of omission discussable and gives a team room to respond when work takes longer than expected. The categories are useful only if people share their meaning and the capacity assumptions are credible.
When to use it
USE IT WHEN
A release or timebox needs a clear minimum usable scope.
Stakeholders disagree about which requirements are essential.
The team needs an explicit way to reduce scope without losing the intended outcome.
When to choose another method
Use User Interviews when the value of the requirements is still speculative.
Use RICE Scoring to compare opportunities under consistent estimates.
Use Impact / Effort Matrix for a preliminary discussion of relative value and effort.
What you’ll need
Agree the timeframe, intended users and minimum outcome before sorting requirements. Bring delivery estimates, dependencies and evidence about consequences. Include people who can decide scope and those who would operate any proposed workaround. Keep binding obligations explicit rather than voting them away.
What the method needs
Keep the elements that help answer your question and support a decision.
Without this requirement, the agreed delivery would not be viable.
Important, but omission can be tolerated temporarily with a credible workaround.
Desirable, with a smaller consequence if omitted.
Explicitly excluded from the current delivery period.
02 / PUT IT INTO PRACTICE
How to prioritise with MoSCoW
Keep evidence and assumptions distinct. Revisit your work when new information changes your understanding.
01
Define the delivery promise
State the period and the outcome the release must support.
For a reservation pilot, define who can reserve what and how confirmation works.
02
Clarify requirements
Split broad bundles and describe the result rather than only a preferred feature.
A reminder channel and a valid reservation record are different needs.
03
Test proposed Musts
Explain what fails without each one. Challenge preference disguised as necessity.
A reservation that can silently exceed capacity may invalidate the pilot.
04
Assess workarounds
For Shoulds, identify who does the extra work, for how long and at what cost.
A manual confirmation route needs real staffing and an agreed response time.
05
Check capacity and dependencies
Compare the essential scope with available effort. Rework the plan if everything is guaranteed.
A small visible feature may require a large shared dependency.
06
Record and revisit
Publish the categories, reasons and triggers for review. Reassess when evidence or capacity changes.
Do not quietly move a Won’t into the release without revisiting the agreement.
Example: scoping an equipment reservation pilot
Illustrative scenario: a community equipment library plans a limited reservation pilot. Preventing conflicting reservations and providing a dependable confirmation are Musts for the agreed service. Automated reminders are a Should because a staffed manual reminder process is proposed for the pilot.
Saved favourites are a Could. Recommendations are a Won’t this time. During review, the coordinator finds that the manual reminder workload has no assigned capacity. The Should classification therefore rests on an unproven workaround.
The team must provide that capacity, change the pilot or reconsider automation. The example shows that a category is conditional on delivery facts. It is not a universal priority order for reservation products.
03 / BELOW THE SURFACE
Below the surface: a workaround moves the cost
Omitting a feature can save build effort while creating operational work elsewhere.
OMISSION
What becomes impossible without it?
Distinguish viability from preference.
WORKAROUND
Who carries the deferred work?
Name capacity, limits and duration.
REVIEW
What would change the category?
Keep the agreement responsive to evidence.
A manual process can be reasonable for a small pilot. It becomes misleading when its labour, delay or failure risk is invisible in the scope conversation. Name the person and capacity behind every important workaround.
Ask what happens at the busiest period, during absence or when a request is exceptional. An arrangement that works for a demonstration may not support the promised service period.
This editorial check complements the established categories. It does not mean every inconvenience becomes a Must. It means the decision to defer a requirement should include the cost and feasibility of the alternative, together with a point at which that alternative must be reviewed.
MoSCoW Prioritization companion worksheet
The four category worksheet records scope for a named period. Page two examines one disputed requirement, including omission consequences, workaround capacity and dependencies. It is an original companion, not an official DSDM template.
Practical tips
State the timeframe beside the categories.
Evaluate effort as well as the number of requirements.
Common mistakes
Calling nearly everything a Must.
Treating Won’t as a permanent rejection.
Assuming a manual workaround is free or available.
What you’ll get
A shared delivery agreement with explicit flexibility. When the essential scope does not fit, revise the promise or capacity rather than relabelling the same commitment optimistically.