A MoSCoW prioritisation example, worked on twenty real requests

Most MoSCoW prioritisation examples show four buckets with three items in each and no arithmetic. This one runs the method twice over the same twenty requests, with two different bucketing rules, and prints the person month totals both times.

The interesting result is that five of the nine requests the first rule called Must aren't Must under the second one, and the first rule is the one almost everybody actually uses.

What does a MoSCoW example look like when it is worked?

Twenty requests, each carrying the votes behind it, the monthly revenue of the accounts that asked, and an effort estimate in person months. The same twenty are used by every post in this cluster, so the methods can be compared, not described.

There's a board with requests, votes and effort estimates on it if you want to see where the inputs come from, and the demo is open without an account.

The twenty requests

Total revenue represented is $83,200 a month, and the total effort if everything were built is 20.25 person months.

Pass one, MoSCoW by importance

The rule almost everybody uses, stated explicitly so it can be checked. Must is anything with $4,000 or more of revenue behind it. Should is anything with $2,000 or more, or twelve or more votes. Everything else is Could.

Must is nine of twenty, which is 45% of the list, and it consumes 11.25 of the 12 person months in the quarter.

Nothing is in Won't. That's what the rule produces, not an accident of this dataset, because a rule based on importance has no mechanism for refusing anything. Everything is important to somebody, so nothing is ever a Won't.

A Must bucket at 45% of the list isn't a prioritisation. It's the original list with a label on the top half.

Pass two, MoSCoW by spending a capacity

Same twenty requests, different rule. Four person months for each of Must, Should and Could, filled best revenue per person month first, and whatever doesn't fit is Won't.

Must. API rate limit increase, Webhook on status change, CSV export of the weekly report, Saved filters, Bulk status changes, Two factor authentication, Tag colours.

Should. Merge duplicate requests, Private boards, Roadmap embed on our own site, Email digest for admins.

Could. Single sign on, Import from a spreadsheet.

Won't. Custom fields on requests, Weekly digest email, Slack notifications, Scheduled exports, Comment threading, Mobile layout for the board, Dark mode.

What changed between the two passes

Five of the nine Musts from pass one aren't Must in pass two. Single sign on, which has the most revenue behind it of anything on the list at $11,200 a month, falls to Could, because it costs three person months and three other requests deliver more revenue per month of work between them.

Dark mode, which has 31 votes and is the most requested thing on the board by a wide margin, is in Won't. It carries $400 of revenue, which is 0.5% of the total, against 15% of the votes.

Neither of those is obviously right. What matters is that the second rule produces an answer you can argue with, and the first one produces an answer nobody can argue with because it hasn't refused anything.

The trap in the third letter

Could is where the method fails quietly.

In pass one, Could had three items and Won't had none, which means nothing was refused and Could is just a politer Should. In pass two, Could is two items against seven in Won't, and the difference is that the second rule had to stop somewhere.

If your MoSCoW pass produces an empty Won't, you haven't prioritised. You have sorted.

How to run this on your own list

Write down the capacity first, in whatever unit you estimate in, before looking at the requests. Then fill the buckets against it. Doing it in that order is the whole method, and doing it the other way around is how Must becomes half the list.

The inputs you need are the ones in the table above, being something approximating demand, something approximating value, and a rough effort. Precision in any of the three buys almost nothing. The ordering is stable to quite large errors, and a request being fifth or seventh rarely changes what you do this quarter.

How do you do this without a tool?

A spreadsheet with the four columns above, a capacity number at the top, and a bucket column you fill in from the top down until each capacity is spent.

The column that's hard to fill is the revenue behind each request, because it means knowing who asked and what they pay. That's the column most lists don't have, and it's the reason the first rule gets used instead of the second.

How does this product do it?

Requests carry the people who asked, and those people carry whatever you know about them, including the revenue on the account. So the weighted vote count is the revenue behind the request, not the number of voices, and it sits beside the plain count rather than replacing it.

Each card also carries an effort estimate, and the board can be ordered by the priority that demand and effort produce, which is the pass two ordering above without the spreadsheet.

The revenue weighted voting page covers the weighting, and what MoSCoW prioritisation is covers the method itself.

The method, step by step is the procedure this worked example follows.

14 days, a card at signup, then $9 or $39 a month.