The short version
- Six steps, and the first one is writing down the capacity.
- Fill Must against the capacity, not against how important things feel.
- If Must is half your list, the rule you used was importance.
- A spreadsheet with a capacity in cell A1 is the whole tool.
The MoSCoW prioritisation method is six steps. The first one is the one everybody skips and it's the reason the method usually fails.
How do you run MoSCoW requirements prioritization?
The list can be requirements or feature requests and the six steps below don't change, because the method was written for requirements work and a request is a requirement that somebody outside the team wrote.
- Write down the capacity, before looking at the list.
- Get every request into one list with a rough effort on each.
- Fill Must against the capacity you wrote down, not against how important things feel.
- Fill Should against the next slice, Could against the one after.
- Everything that doesn't fit goes in Won't, with a reason.
- Add up the person months in each bucket and check the total against the capacity.
Step six is the check that makes the rest honest, and it takes a minute.
There's a queue carrying effort estimates if you want to try it, and the demo is open without an account.
Doing this in a tool rather than a spreadsheet? Twenty one feature request tools and the eight units they bill on. The unit decides the bill, not the headline price.
Step 1, write down the capacity first
One number, in the unit you estimate in, decided before you look at what people want.
The reason this has to come first is that the alternative is unfalsifiable. Once you've read the list, every estimate of capacity is influenced by how much you would like to fit, and the buckets become a description of your optimism.
If you've four developers and a three month quarter, the number isn't twelve person months. Subtract support, bugs, leave and the work that arrives without asking. Half of the nominal figure is a common honest answer, and using the nominal one is the second most common way this method fails.
Step 2, one list with an effort on each
Rough is fine. Small, medium and large, converted to numbers, is enough.
Precision buys almost nothing here. The bucket boundaries are stable to quite large errors, and a request being 0.5 or 0.75 person months rarely moves it across a line. What does move things is missing requests, so the list being complete matters much more than the estimates being good.
Step 3, fill Must against the capacity
Take the requests in the order your ranking gives you and put them in Must until the capacity for Must is spent.
Whatever ranking you use, use one. Revenue per person month, demand over effort, or a stakeholder's ordered list. The method doesn't supply a ranking and pretending it does is how the meeting turns into an argument about which items feel essential.
Steps 4 and 5, keep filling and then refuse
Should and Could get their own slices. Everything else is Won't.
Won't is the output. A pass that produces an empty Won't hasn't prioritised, because nothing was refused, and the list is exactly as long as it was when you started.
Write one sentence of reason on each Won't. Not for the record, but for the person who asked, who is entitled to know that the answer is no rather than being left to infer it from silence over six months.
Step 6, the arithmetic
Add up the effort in each bucket and compare it to what you wrote down in step one.
Here's what the check catches. Run the method on twenty requests with a rule based on importance, not capacity, and this is the result.
| Bucket | Requests | Person months |
|---|---|---|
| Must | 9 | 11.25 |
| Should | 8 | 7.00 |
| Could | 3 | 2.00 |
| Won't | 0 | 0.00 |
Must is 45% of the list and consumes 11.25 of a 12 month quarter, leaving nothing for Should, and Won't is empty. Every one of those three facts is a failure, and all three are invisible until somebody adds up the column.
Run the same twenty against a stated capacity of four person months per bucket, best revenue per unit of effort first, and this is the result.
| Bucket | Requests | Person months |
|---|---|---|
| Must | 7 | 4.00 |
| Should | 4 | 4.00 |
| Could | 2 | 3.75 |
| Won't | 7 | 8.50 |
Five of the nine requests the first rule called Must aren't Must under the second. The full pass, with every item named, is on a MoSCoW prioritisation example.
What to do when Must is half the list
It means the rule was importance, not capacity. Three fixes, in order of how much they help.
Run step three against the capacity. Usually enough on its own.
Split the big items. A three person month Must is often one person month of the thing people actually asked for and two of the version you would prefer to build.
Ask what happens if a Must isn't done. If the answer is that the release still ships and somebody is annoyed, it's a Should. This question, asked out loud, moves about a third of most Must buckets.
The mistakes
No capacity. Covered above, and it's the only one that matters.
Bucketing by who asked. Then MoSCoW is a seniority ranking with four labels.
Leaving Won't empty to avoid the conversation. The conversation happens anyway, later, with less time to react.
Running it again every week. MoSCoW is for a fixed scope against a fixed capacity. A continuous product wants a ranked queue.
How do you do this without a tool?
A spreadsheet, a capacity written in cell A1 before anything else, an effort column, a bucket column, and a row of sums at the bottom.
The sums are the part people leave out, and they're the part that makes the exercise real.
How does this product do it?
Each card carries an effort estimate, so the person month totals in step six are available, not reconstructed. Requests carry the people who voted for them, and those people carry the revenue behind their accounts, so the ranking in step three can be demand, revenue, or the priority that demand and effort produce.
Denied is one of the five default columns, with the reason on the card, which is the Won't bucket made permanent and visible to the person who asked, not recorded in a spreadsheet they will never see.
The revenue weighted voting page covers the weighting.
What MoSCoW is covers the four buckets and what each one commits you to.
14 days, a card at signup, then $9 or $39 a month.
