The short version
- Four buckets, and what an empty one tells you is the more useful half.
- Could is where the method goes wrong, for reasons that have nothing to do with the items in it.
- Without a capacity written down first, Must swallows the list.
- MoSCoW is good at making refusals explicit and bad at ordering inside a bucket.
MoSCoW prioritisation sorts a list into four buckets, being Must have, Should have, Could have and Won't have. The letters in the middle are there to make the word pronounceable.
The method's reputation is that it's simple. Its actual behaviour is that it produces a useful answer only when one condition is met, and the condition is almost never stated. You have to know the capacity before you start bucketing.
What do the four buckets mean?
Each bucket is a different commitment, and what an empty one tells you about your list is the more useful half.
| Bucket | What it commits you to | What it means if it is empty |
|---|---|---|
| Must | Without this the release is not worth shipping | You are not shipping anything essential, which is unusual |
| Should | Painful to leave out, survivable | You have not separated essential from important |
| Could | Would be nice, first to be cut | Nothing is nice to have, which is not true of any real list |
| Won't | Explicitly refused this time | You have not prioritised. You have sorted |
The last row is the whole method. Won't is the only bucket that does work, because it's the only one that says no, and a MoSCoW pass that produces an empty Won't has arranged the list without shortening it.
There's a queue with demand and effort on it if you want to try the method against something real, 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.
The trap in the third letter
Could is where the method goes wrong, and it goes wrong for a reason that has nothing to do with the items in it.
Could exists to hold the things you would do if there were room. That's a sensible idea and it depends entirely on there being a defined amount of room.
Without a stated capacity, "if there's room" is unfalsifiable, so nothing has to leave Could, so Could becomes the bucket where anything you didn't want to refuse goes to wait.
Within two cycles Could is longer than Must and Should together and nobody has looked at it since it was written. It's a backlog with a friendlier name, and it has absorbed exactly the refusals the method was supposed to force you to make.
The symptom is easy to check. If your Won't bucket is empty and your Could bucket is the longest one, the method did nothing.
What happens to Must without a capacity
The other half of the same failure.
Run the method on twenty requests with a rule based on importance, not capacity and Must comes out at nine of twenty, which is 45% of the list, consuming 11.25 person months of a 12 month quarter.
That figure comes from a worked example in this repository rather than from an assertion, and the full pass is on a MoSCoW prioritisation example.
A Must bucket at 45% is the original list with a label on the top half. It commits you to almost everything, which is the same as committing to nothing, and it's what an importance based rule always produces because everything on a request list is important to somebody.
The condition that makes it work
State the capacity first, in whatever unit you estimate in, before you look at the requests.
Then fill Must against that capacity, Should against the next slice, Could against the slice after that, and put everything that doesn't fit into Won't. The buckets stop being opinions about importance and become statements about how much room there is, which is what they were always meant to be.
Doing it in that order is the entire method. Doing it the other way round is how Must becomes half the list.
What MoSCoW is good at
Making refusals explicit. A named Won't bucket with reasons in it's more useful to the people who asked than silence.
Conversations with stakeholders. Four words that everybody already understands beats a score nobody can check.
Fixed scope with a deadline. The case the method was designed for, where the date isn't moving and the question is what fits.
What it is not good at
Ordering within a bucket. Seven things in Must aren't ordered by being in Must, and you still have to decide what to do on Monday.
Comparing across time. Must in this cycle and Must in the next are different standards unless the capacity was the same.
Anything continuous. A product that ships every week doesn't have a fixed scope to bucket, and a ranked queue is the better instrument.
How do you do this without a tool?
Four columns and a capacity number written at the top of the page before anything else. Fill from the top down until each capacity is spent.
The input that's hard to get is what each request is worth, because it means knowing who asked and what they pay. That's the column most lists don't have, and its absence is why importance gets used as the rule instead.
How does this product do it?
A request carries the people who voted for it, and each of those people carries whatever you know about them, including the revenue on their account. The weighted count is therefore the revenue behind a request, not the number of voices, and it sits beside the plain count rather than replacing it.
Each card carries an effort estimate, so the capacity arithmetic in the section above is available, not reconstructed. Declining is a column called Denied with the reason on the card, which is Won't made permanent and visible to the person who asked.
The revenue weighted voting page covers the weighting, and the MoSCoW method step by step covers running it.
14 days, a card at signup, then $9 or $39 a month.
