The mygyaan practical guide
Finish what matters.
Leave the rest for later.
MoSCoW prioritisation turns a growing wish list into a clear delivery agreement. Decide what you must deliver, what can flex, and what is out of scope.
Understand the four prioritiesThe danger is not always a bad idea.
It is one more good idea.
A project starts with a clear purpose. Then come extra reports, new integrations, another audience and a more polished interface. Each request sounds reasonable. Together, they change the work without changing the deadline.
That is scope creep: the delivery expands without an explicit agreement about the extra time, cost or trade-offs. MoSCoW helps you make those decisions before enthusiasm becomes an unmanageable commitment.
Start with a specific release or timebox. A requirement can be a Must for one delivery and a Won’t for another. Priority only makes sense in relation to the outcome you have agreed.
01 / Decide what belongs
Must. Should. Could. Won’t.
Must have
Essential to the outcome
Without this requirement, the agreed delivery is not usable, safe, lawful or capable of achieving its core purpose. These are the commitments you protect first.
The decision question
If we leave this out, does the delivery fail its purpose?
An inconvenient workaround may be acceptable. An unsafe or unlawful one is not. Explain the consequence of omission before calling something a Must.
Example: For a customer-order portal: customers can submit an order, and the team receives the correct order details.
Should have
Important, but not essential
This adds meaningful value and should be included if capacity allows. But the core outcome remains viable without it, usually with a tolerable temporary workaround.
The decision question
Can we deliver the core result without this, even if it is less convenient?
Describe the workaround, its cost and who will use it. Shoulds are not automatically postponed; they come after protecting the Musts.
Example: A downloadable order acknowledgement. Initially, the team can send a confirmation manually.
Could have
Useful if there is room
This is a worthwhile enhancement with a smaller impact if omitted. Include it only when it does not put more important commitments at risk.
The decision question
Would leaving this out make little difference to the core result?
A Could is not a bad idea. It is the first place to release capacity when estimates change or unexpected work appears.
Example: Saved favourite orders or a personalised dashboard theme. Helpful, but not necessary to place an order.
Won’t have
Not in this delivery
This is explicitly outside the agreed scope for the current release or timebox. Record it so that it does not quietly return through another meeting or message.
The decision question
Have we agreed not to spend capacity on this during this delivery?
Won’t does not mean never. Keep the idea and the reason for deferring it; reconsider it in a future planning decision, not by default.
Example: Predictive stock recommendations and a multi-country rollout when the immediate goal is a usable ordering portal for existing customers.
02 / Make the trade-offs concrete
Example: a customer-order portal
The first delivery lets existing customers submit orders that the operations team can act on. It is not a complete digital transformation. These are illustrative choices for that goal—not universal priorities for every business.
| Priority | Agreed scope | Why it belongs here |
|---|---|---|
| Must have | Submit accurate orders; deliver them securely to the team. | Without this, the core customer journey does not work. |
| Should have | Download an order acknowledgement. | Useful, with a manual confirmation available as a temporary workaround. |
| Could have | Save favourite orders for faster reordering. | Adds convenience after the basic ordering journey is reliable. |
| Won’t have | Predictive stock recommendations and multi-country expansion. | Outside the agreed first delivery; assess separately later. |
03 / Use it in your next planning conversation
Turn the labels into an agreement
- 01
Define the finish line
Write the outcome, delivery date and acceptance criteria. “Launch a portal” is vague; “existing customers can submit accurate orders to our team” is testable.
- 02
List the requirements
Write one clear requirement per line. Separate the customer outcome from the solution someone happens to prefer. Include dependencies and safety or compliance obligations.
- 03
Sort together
Bring the people who approve, build and use the result into the same discussion. Use the omission test rather than the seniority of the person requesting the feature.
- 04
Check capacity
Estimate the work and allow for uncertainty. If even the Musts do not fit, reduce the delivery scope or explicitly renegotiate time and resources. A label cannot create capacity.
- 05
Record the agreement
Give each requirement an owner, a priority, a reason and a definition of done. Write down the Won’ts as clearly as the Musts.
- 06
Control changes
When a new request arrives, assess its value, effort and dependencies. Agree what moves out or what changes before accepting it. Review priorities at planned checkpoints.
Where the method needs your judgement
MoSCoW sorts requirements into categories; it does not calculate value or remove bias. ProductPlan’s learning guide highlights inconsistent scoring, missing stakeholder input and team preferences as potential weaknesses. The labels help only when the reasoning behind them is sound.
Use the same evidence for every request
Ask about customer impact, risk, effort, dependencies and the cost of waiting. Do not demand evidence from one department while accepting another department’s preferences as facts.
Rank within each category
Several Shoulds may compete for the same capacity. Agree their relative order using a consistent value-versus-effort discussion; the category alone cannot choose between them.
Inspect dependencies
A seemingly optional technical or operational task may enable a Must. Trace that dependency, challenge the proposed solution and choose the simplest safe way to satisfy the outcome.
Agree how disputes are resolved
Name the accountable decision-maker and invite the people with relevant customer and delivery knowledge. Record the rationale so the same debate does not restart every week.
A requirement should come with a reason
In your planning tool, record: requirement → priority → reason → acceptance criteria → owner → dependencies → review point. Keep this lightweight enough that the team actually maintains it.
Illustrative entry
Requirement: send new orders to the operations team. Priority: Must. Reason: orders cannot be fulfilled if the team does not receive them. Acceptance: a submitted test order arrives with the correct customer, items and quantities. Owner: the agreed operations lead. Dependency: a verified order-notification channel. Review: before release acceptance.
If a new request becomes a Must, revisit the whole delivery agreement. Silently relabelling it does not resolve the extra work.
04 / Choose the work. Then make it visible.
MoSCoW sets priority. Kanban shows progress.
Priority and status answer different questions. A Must can still be blocked. A Could can be finished. Keep the priority label on each task, then move the work through a simple board.
To do
Agreed work waiting to start.
In progress
Work actively being delivered.
Done
Work that meets its acceptance criteria.
Give tasks an owner, make blockers visible and agree a realistic limit on work in progress. Finish work before starting more. Use the board to expose delays, not simply to collect activity.
Questions teams usually ask
Does Won’t have mean we are rejecting the idea forever?
No. It means the requirement is outside this delivery. Record why it is deferred and when it may be reconsidered. Some ideas will never justify the effort; others will matter later.
Are Should haves automatically version two?
No. They are valuable candidates for the current delivery once the Musts are protected. They can be postponed if necessary without destroying the core outcome.
Should we count features or estimate effort?
A list of small items and a list of major integrations can have the same item count but very different workloads. Check effort, dependencies and uncertainty rather than assuming each requirement consumes equal capacity.
Can MoSCoW work outside software?
Yes. Use it for a service launch, a plant-maintenance initiative, an event or a process change. The acceptance criteria and consequences of omission must match that context. Safety and compliance are not optional conveniences.
Before you leave: choose one project.
Write its outcome and delivery date. List the requirements under the four headings. Challenge every Must. Agree what will not be included. Then ask the team: “If a new request comes in tomorrow, what are we willing to trade?”
The aim is not to deliver less value. It is to stop optional work from delaying the value that matters.