MoSCoW Method: How to Prioritize (With Examples)

What is the MoSCoW method?

The MoSCoW method is a prioritisation technique that groups requirements into four categories so a team and its stakeholders can agree on what a delivery must contain, what it should contain, and what it will not contain this time. The letters stand for Must have, Should have, Could have, and Won’t have; the two O’s exist only to make the acronym pronounceable.

Dai Clegg developed it in 1994 while working on rapid application development, and the DSDM consortium later built it into its agile project framework as the standard approach to scope management. That lineage matters. MoSCoW was designed for a fixed timebox, where the date is protected and scope flexes. Used without a deadline, it loses most of its force.

The output is not a ranked list. It is a negotiated agreement with four explicit boundaries, one of which — Won’t have — is a written promise about what the team is not doing.

What do the four categories actually mean?

Each category answers a different question. If two items pass the same test, they belong in the same category, and one of them is probably misclassified.

Two tests do most of the work.

The failure test for Must have. Ask what happens if the item is missing on launch day. If the answer is “we would be embarrassed” or “the sponsor would complain”, it is not a Must. If the answer is “the product cannot legally operate” or “the core user journey stops”, it is.

The workaround test for Should have. A Should have is important but has a substitute: a manual process, a spreadsheet, a support script, a later release. If no workaround exists, the item is a Must. If the workaround is cheaper than building the feature now, the item stays a Should.

Won’t have deserves more respect than it usually gets. It is the only category that prevents scope creep in writing, and the only one that gives a stakeholder a clear answer. A release plan with no Won’t list is not a plan; it is a wish list with formatting.

> Important note: MoSCoW categories are relative to a specific timebox and date. “Multi-currency is a Won’t” means “not in the March release”. If that is not written down, someone will hear “never” and someone else will hear “next month”.

Why does the 60% effort rule matter?

Because a plan where Must-haves consume 100% of capacity has no room for the estimate being wrong. DSDM guidance recommends that Must-have requirements take no more than about 60% of the effort in a timebox, with a sensible pool of Could-haves around 20%, which leaves roughly 20% for Should-haves.

The percentages are not a law of nature. They are a contingency design. If the Must list fills the whole box, any slippage forces a choice between missing the date and cutting a Must — exactly the crisis the method was meant to prevent. A 60% cap leaves room to absorb a bad estimate, a late dependency, or a sick team member without renegotiating the release.

Example: a six-week release with 900 hours

A product team has five developers at 30 productive hours a week for six weeks. Capacity is 900 hours. The Must list is estimated at 780 hours, or 87% of capacity.

The team has three options: move 240 hours of work to Should, add capacity, or accept that the date is a guess. Moving the admin refund tool (120 h) and audit log export (100 h) to Should brings Must effort to 560 hours, close to the cap, and frees 220 hours of contingency. That is 2.4 weeks of a four-person team — enough to absorb a realistic slip without a crisis meeting.

Notice that nothing was cancelled. The work moved to a later timebox, which is a decision stakeholders can live with, unlike “we will try to fit it in”.

How do you run a MoSCoW session?

A useful session takes 90 minutes, not a week. The sequence matters more than the tool.

1. Fix the timebox first. State the delivery date and the capacity in hours or person-days. Without those two numbers, the exercise becomes a debate about wishes.
2. List candidates in plain language. One line per requirement, written as a deliverable or user outcome. “Reporting” is not a requirement; “export a filtered task list to CSV” is.
3. Estimate before classifying. A category without an effort number cannot be tested against the 60% rule. Use rough ranges if needed.
4. Classify silently, then compare. Each participant marks items privately for two minutes, then the group compares. Silent first passes reduce anchoring by the loudest voice.
5. Test every Must against failure. The facilitator asks the failure question out loud for each item. This is where the list usually shrinks by a third.
6. Write the Won’t list and read it back. Explicit agreement on exclusions is the deliverable nobody expects and everybody needs.
7. Check the effort split. Sum each category. If Must is above 60%, move items until it is not — or change the date and say so.
8. Record the assumptions. Note who agreed, on what date, and what would bring an item back into scope.
9. Revisit at every boundary. A category agreed in January is evidence, not scripture. Re-run the test when a dependency moves or a risk lands.

Example: 34 requirements, one afternoon

A financial services team listed 34 requirements for a compliance release. The first vote produced 21 Must-haves — 62% of the items and 91% of the effort. The facilitator applied the failure test item by item.

Ten items survived as Must. Eleven moved to Should because a manual control already existed. Eight became Could. Five went to Won’t, including a dashboard redesign that had been requested by a single stakeholder.

The release shipped on the promised date. Two Should items made it in; the dashboard redesign was scheduled for the following quarter, in writing, with a date. The political cost was one uncomfortable conversation, held once, instead of six weeks of quiet slippage.

How do you stop everything becoming a Must?

You make Must expensive. The category should carry a consequence, not a preference.

Three tactics work in practice:

Ask for the failure story. “If this is missing, describe the failure in one sentence.” If the sentence is vague, the item is not a Must. The discipline of saying it aloud filters most of the list.

Make the sponsor choose. When a sponsor insists on twelve Musts, show the effort total and ask which two Should items they would rather drop to keep the date. The question moves the conversation from importance to trade-off.

Publish the split. Put the effort percentage in the release brief. A Must list at 85% of capacity is a visible risk, and visibility is usually enough to get it reduced.

There is also a structural cause worth naming: MoSCoW has no tie-breaker inside a category. Two Musts that both fail the test still compete for the same hours. When that happens, add a second lens — cost of delay, risk reduction, or a simple 100-point vote — rather than promoting one item to a fake category.

How do you handle a change request mid-release?

Treat every change request as a category question, not a favour. The request is either a new Must that displaces something, a Should for the next timebox, or a Won’t with a recorded reason.

The useful discipline is to price the four possible responses before the meeting: swap, extend, add capacity, or refuse. A worked case makes the trade-off concrete.

The case. In week four of the six-week release above, a compliance officer requests an additional audit field. The estimate is 80 hours. Weekly capacity is 150 hours, so the work is just over half a week. The loaded internal rate is $120 an hour.

The swap is usually the right answer, and it is only visible because the categories and estimates already exist. Without them, the conversation becomes “can you squeeze it in?”, which produces an optimistic yes and a silent quality cut.

Two rules keep this honest. First, a new Must requires a named item to leave the Must list; the list does not grow. Second, the decision and its cost go into the change log, so the next timebox starts from evidence rather than memory.

How does MoSCoW compare with RICE, WSJF, and Kano?

MoSCoW classifies scope; the others rank it. That difference decides which one you need.

A practical combination is MoSCoW for the scope boundary and WSJF or cost of delay for ordering inside the Should bucket. The categories answer “in or out”; the score answers “first or second”.

Use MoSCoW alone when the question is contractual: what does version 1.0 include? Use a scoring model alone when the question is sequencing: which of these 30 improvements comes next? Using MoSCoW to sequence a long backlog produces four lists and no order.

What are the limitations of MoSCoW?

• No ranking inside a category. Ten Musts tell you nothing about sequence. Pair it with a scoring method when order matters.
• Ambiguous timing for Won’t. “Not this release” and “not ever” sound identical in a meeting and mean different things in a contract.
• Susceptible to politics. Vocal stakeholders push items into Must. Silent classification and the failure test reduce this, but do not remove it.
• Biased toward features. Refactoring, security hardening, and documentation rarely have a passionate sponsor, so they drift into Could or out of the list.
• Requires estimates. Without effort numbers, the 60% rule is theatre.
• Not a substitute for a business case. Four categories cannot tell you whether the release is worth doing at all.

None of these is fatal. They are reasons to use the method with a facilitator, a timebox, and a second lens for ordering.

What are the common MoSCoW mistakes?

• Classifying before estimating. Categories become opinions instead of constraints.
• Skipping the Won’t list. The most useful output is the one most often omitted.
• Treating categories as permanent. Scope agreed in January is not scope agreed in March.
• Letting the sponsor set Musts alone. The team owns feasibility; the sponsor owns consequence. Both are needed.
• Confusing Should with “nice to have”. A Should has real value and a workaround. A Could is optional.
• Reporting categories without effort. A slide with 20 Musts and no hours hides the risk it claims to manage.

Where does MoSCoW live after the workshop?

A prioritisation that exists only in a slide deck decays within two weeks. The categories need to sit next to the work: a field on each task, a filter on the board, and a view that shows the effort split by category.

That is the part most teams underestimate. Doitify’s boards, task detail, and workload views keep the category next to the work, so the Must list can be tracked through the sprint and the release report instead of being retyped into a spreadsheet. Transparency: Doitify is our product, and we only describe what it does. If your team already tracks scope elsewhere, a tag and a saved filter will do the same job.

The test is simple: can a new team member see, without asking, which items are Must and how much capacity they consume? If not, the prioritisation is documentation, not management.

Conclusion

The MoSCoW method is valuable for one reason: it forces a group to say out loud what it is not doing. The four categories are simple enough to use in a client meeting and strict enough to survive an audit, provided you estimate before classifying and cap the Must list at a realistic share of capacity.

Use it with a fixed date, a written Won’t list, and a second method for ordering inside the buckets. Then keep the labels visible where the work happens. A prioritisation nobody can see is a meeting that happened, not a decision that holds.

If this post on MoSCoW method was helpful, you might also enjoy Project Management KPIs: Metrics Every Manager Should Track and Free Change Request Template.