A MoSCoW prioritization example, worked on twenty real requests

Most MoSCoW prioritization 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 prioritization. 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 the company 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 prioritized. You have sorted.

When does a MoSCoW pass go stale?

Faster than anybody expects, and the thing that ages it is not time.

A MoSCoW pass is a photograph of three inputs: what people are asking for, what you can build in the window, and what the business needs. Every one of those moves. The letters do not, because nothing in the method reruns itself, and a list of musts written against a capacity you no longer have is worse than no list because it looks current.

Three events should end a pass early.

The capacity changed. Somebody left, somebody joined, or the window moved. Pass two above was built by spending a fixed capacity, so a different capacity produces a different answer and none of the letters carry over.

The demand behind an item moved. A should that has quietly collected thirty new votes since the pass is not a should any more. This is the one worth watching, because it happens continuously and produces no event anybody notices.

The revenue behind an item moved. Two requests tied on headcount are not tied if one is carried by customers who have since upgraded and the other by customers who have since left. On a board that weights a vote by what the voter pays, that reordering happens in the numbers before anybody reruns the pass, which is the earliest warning you get.

The practical rule is to rerun the pass at the start of each window rather than on a calendar, and to treat a letter older than one window as a suggestion rather than a decision.

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 buckets are the easy half; your capacity number is the half nobody else can fill in. The MoSCoW tool and xlsx template totals each bucket's share of effort and flags Must past 60%, so the second pass above takes minutes. The prioritization matrix file sorts the same table by two axes instead of into four buckets.

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 VoteFirst 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 what the people behind a request are worth to you rather than how many of them there are, and it sits beside the plain count rather than replacing it. It is a whole number and not a currency amount. The revenue figure on a tier is a separate number that is shown to you and never multiplies anything, because the moment a weight is computed from a currency amount a rounding difference can reorder your roadmap.

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 prioritization 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.