Using MoSCoW to prioritize ideas

I have been on a lot of projects in my time and I used to prioritise ideas or requirements as “high”, “medium” or “low” importance.

If people classified their requirement as low,however, we would record the requirement in a long list, thank them for their idea and then never talk about it again.  If they classified it as medium then we promised get to it in “phase 2”, which meant after we ran out of money.

People learned over time to classify all of their requirements as high priority so we started adding new classifications like critical or super ultra high, which didn’t help at all.

Once I got involved in agile projects I came across a new approach – “Moscow”, which stands for Must Have, Should Have, Could Have or Won’t have.

This seems to work better but some teams are now changing Won’t Have to Wish to Have – ie might happen.  Unfortunately some are also starting to say Must Have will happen first and Should Have will happen later while Could Have will be in “Phase 2”. 

So here is my interpretation of how to use Moscow to prioritise ideas. It works for stories and also for any other kind of need.

First define the problem you have (or opportunity or grand idea), then come up with some success criteria, risks, potential market or users, a scope and so forth. Now add your more detailed needs, requirements or stories.

Now to prioritise them:

1. Must Have means we must have this as part of the solution. It is a compliance requirement or a given.  If this one requirement represents 90% of the cost of the solution we would either kill the project or include the requirement.
2. Should have means we would be embarrassed not to have it. We could technically produce the solution without it but people would be surprised. For example our competitors or existing product might already do this.
3. Could have means anything else we could do.  But this does not always mean low priority.  Our competitors are pretty much bound to deliver the same Must Have and Should Have ideas as us. But our selection of which Could Haves to include or exclude (or deliver later) will define our competitive advantage – this is what differentiates us from the others. This is also the delighters that Kano refers to in product design – the unexpected things that surprise and delight customers.
4. Won’t Have means this will not happen.  It might be technically impossible, a taboo for our organisation or out of scope. It does not mean “might happen or would be nice”.  It means if you want this included in your solution then kill our project and try again, or talk to us about what we can do instead. Having this honest conversation early in the piece can lead to better expectation setting, better allocation of resources and overall better projects. On top of this the Won’t Have can also provide a constraint or differentiator that provides competitive advantage. For example a won’t have on the iphone was a keyboard. It might have been easier to build a phone with one but a clear understanding of that constraint helped the team provide a fully functioning touch screen that needed to fully meet the user’s (probably unknown) needs.