MoSCoW Prioritisation

What this tool does

CM8-255 is a working MoSCoW prioritisation register. You list the requirements for a release, sort each into Must have, Should have, Could have or Won't have this time, and put an effort estimate against it. The tool does the arithmetic that turns a list into a plan: what each category is consuming, whether the Must-haves have taken over, whether it fits your capacity, and which unstarted item gives the most value for the least work.

Each record is one requirement, and one file can hold several releases — name each consistently and filter to the one you are working on. Everything runs inside this file: no account, no upload, no network request.

The one rule that makes MoSCoW work

MoSCoW is easy to describe and easy to ruin. It survives or fails on one rule:

The failure mode is universal: everything becomes a Must, because "Must" is read as a status rather than a definition and because calling an item a Should feels like telling its sponsor their work does not matter. At that point you have not prioritised anything — you have made a list, and a list has no flex in it. When an estimate proves optimistic it gives you nothing to trade; you can only slip the date, cut quality quietly, or overrun. Prioritisation exists so that there is something to give up when the plan meets reality. The test that rescues a workshop is to ask of every proposed Must: what happens on the day we go live without it? If the honest answer describes annoyance or extra manual work, that is a Should. If it describes a broken transaction, a breach of an obligation, or a product nobody can use, it is a Must.

The four categories, and the question that sorts them

• Must have — Does delivery fail without it? Legal duties, contractual commitments, the core function the release exists to provide. Every Must here needs a written justification, because one that cannot be justified in a sentence is usually a Should.
• Should have — Is it painful to omit, but is there a workaround? Real cost to leave out, but a way to live without it for a while: a manual process, a spreadsheet, a person answering the phone. This is where most genuinely important work sits.
• Could have — Would we drop it without argument if the schedule tightened? Desirable, low pain if omitted. The pressure valve: in the plan on the explicit understanding that these go first.
• Won't have this time — Have we decided, deliberately, that this is out? Not rejected forever, but recorded as excluded from this release.

Write the justification for every category, not only the Musts. The value of MoSCoW is not the four labels — it is the argument that produces them, and the record of it six months later.

The Must-have ceiling

The widely repeated guidance in the frameworks that popularised MoSCoW is that Must-haves should account for well under two-thirds of a release's effort — commonly expressed as around sixty per cent, leaving a real contingency in Should and Could that can be surrendered without failing. The ceiling in Settings defaults to 60% and drives the Must-have effort share tile, which turns red above it.

Treat this as a rule of thumb, not a law. Nothing enforces it, and there are honest releases where the Must share is higher — a regulatory deadline, a forced migration, a first release that has to do one thing or nothing. The ceiling is a prompt at the right moment: if the Musts consume nearly all the capacity, nothing is left to trade the moment anything slips.

Note the denominator. The share is Must effort divided by committed effort — Must plus Should plus Could — because Won't-haves are not in the release and including them would flatter the figure.

Won't have: the most valuable category

Won't have is the category teams skip, and the one that does the most work. Writing down what you are not doing converts a vague expectation into a recorded decision, and it is the only defence against scope creep that survives a change of personnel: "we never agreed to that" becomes a line in a document with a reason next to it. It also manages expectations honestly — a sponsor who can see their request written down, deferred and explained, is easier to work with than one whose request simply disappeared. An empty Won't column usually means the difficult conversations were postponed, and they reappear as change requests at the worst possible moment.

Effort estimates and capacity

MoSCoW without effort estimates is decoration. Categories tell you what matters; effort tells you whether it fits. Estimate in one unit — days or points, consistently — and set the capacity in the same unit. Capacity is the realistic figure: what is left after leave, support work and meetings.

The Effort committed tile compares committed effort against that capacity. An over-committed plan is not a warning; it is a decision waiting to be made. Something will come out of the release — the only question is whether it comes out now, deliberately, in a room with the people who care about it, or in the last fortnight under pressure, chosen by whoever happens to be looking at the backlog. The first is prioritisation. The second is what prioritisation was supposed to prevent.

Value per effort, and where it stops

Each requirement carries a business value from 1 to 5 and an effort estimate; the tool divides one by the other. A high ratio is a cheap win, and the chart ranks the top twelve so they are easy to find.

Inside a category it is an excellent tie-breaker. Two Shoulds of similar value, one costing three days and the other twelve: do the three-day one first, and the twelve-day one is the obvious candidate to move if the release tightens. The "best value not started" tile surfaces the highest-ratio in-scope item nobody has begun — often something small sitting behind larger work for no reason.

Dependencies

Each requirement records what it needs first. Dependencies cut across priority and regularly break it: a Could-have that a Must-have depends on is not really a Could-have, and a Must-have whose dependency sits outside the release is not deliverable at all. Check each time the list changes that nothing of higher priority depends on something of lower priority, and that no dependency points at a Won't-have. Either means the category is wrong, not that the dependency is inconvenient.

Re-prioritise between releases, not during them

Categories are agreed for a defined release and then left alone. A list re-argued every week gives the team no stable target, and the argument is always won by whoever spoke most recently. New work arriving mid-release goes into the next release unless it is genuinely a Must — and if it is, something else comes out to pay for it, decided at the same meeting.

At the release boundary, do the whole thing again from the top. Won't-haves are not automatically promoted; they come back into the conversation with everything else. Keep the old release under its own scope name — that history makes the next round faster.

Where this sits alongside other methods

MoSCoW answers "is it in?" — it does not rank items against each other on multiple criteria. To choose between competing options, a weighted decision matrix scores each against agreed, weighted criteria. To decide which of many small items to do first, an impact-effort matrix plots value against cost. Use MoSCoW for the shape of a release, the others to order the work inside it.

The formulas

Won't-have effort is excluded from committed effort and from the Must share, and shown separately so the size of what you have descoped stays visible.

FAQ

Everything on my list really is a Must. Now what? Do not argue the labels — ask what happens on go-live day without each one, and write the answer in the justification box. Items whose answer is "extra manual work for the support team" re-sort themselves.

Should Won't-haves count against my capacity? No. They are excluded from committed effort and from the Must share, but still shown on the charts and in the Scope health table.

What if I defer a Should mid-release? Set the status to deferred, and if it is genuinely out, change the category to Won't have as well. A deferred item left in Should or Could keeps its effort in the committed total and overstates the plan.

Does a high value score make something a Must? No — value and category are independent on purpose. A high-value item the release survives without is a Should; a dull, low-value item you are obliged to provide is a Must.

Saving your work

Requirements, settings and the report header are written to this browser's local storage as you type. That storage belongs to one browser on one computer: another browser, a private window or a clean-up tool will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work. Reset asks twice, then erases everything stored.

Accuracy & disclaimer

The arithmetic is simple and the tool does it faithfully: it sums effort by category, divides, and compares the result with the capacity and ceiling you set. Everything that matters sits underneath it. The categories are the decisions people made in a room; the tool records them and cannot tell you whether a Must is genuinely a Must, whether a Should was labelled down to make the numbers work, or whether the estimates are more than hope.

The ceiling is a rule of thumb, not a standard and not a guarantee. A plan inside the ceiling and inside capacity can still fail on bad estimates, missing requirements or dependencies nobody wrote down. This is a prioritisation and scope-recording aid, not project management advice.