MoSCoW Must Die

The MoSCoW method for prioritising requirements or stories is both flawed and unsuitable for truly agile projects. I have seen many man hours burned attempting to categorise stories in this fashion by people, who frankly, should know better (including me). Do yourself a favour and steer well clear.

There’s a reasonable summary here: http://en.wikipedia.org/wiki/MoSCoW_Method

If your business is in any way typical of most organisations then the characteristic you will share with everyone is that there is always more to do than the available time allows. No organisation, no matter how large, can do everything it would like to do. In fact it is more serious than that. No organisation will have the time to do all the things it considers to be absolutely essential.

And here’s why.

You cannot rob Peter to pay Paul. Your current project will not be the last project. In fact, conceptually speaking any organisation is always engaged in one giant, never-ending project. In your current ‘project’, any time you spend on anything that is not absolutely critical is time you steal from the next project. Time, at least for the moment, cannot be altered and cannot be reclaimed. In the theoretical lifetime of you organisation there is only a finite number of days. You cannot get a wasted day back.

And this is why MoSCoW is meaningless. A Could Have, by definition, must never be implemented at the expense of a Should Have. A Should Have should never be implemented at the expense of a Must Have. Taking this to its logical conclusion means that you can never implement anything that is not a Must Have until all the possible (known and unknown) Must Haves have been completed.

Will the next project contain Must Have requirements? Yes, of course it will, therefore logically when you complete all the Must Haves in the current project you should immediately move to implement the Must Haves for the next as, by definition, they are more important than anything else.

As a side note this is one reason why many organisations find themselves in the situation where ‘everything is a Must Have’. Sponsors of stories or requirements quickly learn that any category other than Must Have will almost certainly consign their requirement to the dustbin despite the reassurances from Product Management. Therefore everyone games the system, creating elaborate and often spurious justifications as to why their particular requirement is essential.

So, MoSCow makes no sense, creates conflicts of interest and is also a time consuming activity with very little benefit.

The Alternative to MoSCoW.

I suggest you use only two classifications of story or requirement.

Important and Urgent.

Important and Not Urgent.

Everything else can be discarded immediately. There is no benefit in a third category. It is important that you communicate clearly to the wider business the real state of requirements. A third category (a Could Have, if you will) simply serves to give off the false impression that you intend to do something about it and as I’ve just explained, you will not.

Obviously both types of requirement, to be considered important, have been judged to be essential in that they are either profitable or non-profitable-but-necessary. But they differ in the following ways.

Important and Urgent requirements are those that have some form of time dependency i.e. they must exist by a fixed date. This date could be a variety of things. For example:

- An external dependency i.e. some other activity cannot start until this requirement is implemented

- A deadline for contractual reasons i.e. this feature must exist to meet some legal agreement

- Opportunity cost. The feature must exist before a competitor is expected to deliver something similar

- Marketing dates i.e. a feature must be delivered before a major marketing period such as Christmas or Chinese New Year.

- The next round of user testing i.e. you want the feature available for testing at the next organised session.

The list is possibly endless.

Important and Not Urgent are requirements with no hard deadline other than the desire to get them in the hands of customers at the earliest opportunity.

Important and Urgent requirements must always  be delivered before Important and Not Urgent.

Important and Urgent must be delivered in order of earliest date required.

Beyond those rules the order of delivery should be determined by value to the customer (and therefore value to your business). Ideally each should be released to the consumer as soon as they are complete or once there are a sufficient critical mass of requirements to justify the expense of a release. Remember that software that is not in the hands of the customer is the same as software that does not exist. It cannot start to pay for itself until it is released. This point is one I find most often overlooked by large organisations.

Note that the presence of time in this classification implies that all Important and Not Urgent requirements must become Important And Urgent before they are implemented. Remember the assumption I posited earlier. The demand for features is endless.

So, lets summarise.

You will have a steady influx of requested for new features.

For each new feature you will decide whether it is important, i.e. is it a Must Have in MoSCow parlance. This is the most difficult step. You must be brutal. Either this feature has a very strong case or it should be rejected. Often this can boil down to a decision from some Demi-God on the management team. That’s fine. Sometimes this is the best way to prioritise.

If its not ‘Must Have’ you will throw it away (literally; don’t even keep a copy) and inform the sponsor that this requirement will not be implemented. Don’t forget to explain why.

If it is you will identify a dependent date i.e. when must it be delivered by.

If you can then its Important and Urgent and will go on you backlog before any other item which has a later required date and after any item with an earlier required date.

If you can’t yet identify a date then it goes on your backlog, at the bottom, until you can.

Now republish your backlog with its projections of what will be available and when. If things don’t stack up then don’t worry. You are the Product Owner, its not your job to figure this stuff out. You have ensured that the backlog contains no ambiguity and everything is in the correct order. Let the Project Managers and the Management Team sweat this one out. They are either going to have to spend more money or revisit their business cases. You have provided the TRUTH and facts is facts.

This scheme is virtually foolproof, extremely simple, generates the least project risk, communicates the truth and minimises waste.

If you're using MoSCow, ditch it. If you're not then please, please under no circumstances be tempted.

Good Luck!