MoSCoW Anxiety

According to Wikipedia MoSCoW is a prioritization technique and a core aspect of agile software development. Its purpose is to focus a team on the most important requirements, for example to meet a deadline.

I know of many project teams that struggle using this technique because their stakeholders are unwilling to do the prioritization or accept the technique itself. If you have participated on a project where all requirements were classified as must have, I am sure you know what I mean.

What can you do when this happens to you? Well, valid options that might come to mind are run and hide and performing a coup for a decent Product Owner. However, before you go to extremes you might want to try another option first.

Basically what we have here is a kind of anxiety, MoSCoW anxiety if you will.  Anxiety? Yes!  In my experience many stakeholders simply become afraid they will not get what they have asked for when they are asked to classify requirements below the must have level. This makes perfect sense when you reckon that many projects deliver only a (small) part of the promised functionality and a lot of stakeholders have felt let down by IT at least a number of times.

What can we do to overcome MoSCoW anxiety? Key to the solution is Use-Case 2.0 Principle #3:  Focus on Value.

First of all stop talking about MoSCoW and why you need it; for example for meeting deadlines, release planning. Next ask yourself: what is in it for them? Things they probably do care about are: maximization of business value, sound decision-making and protecting their investments, business case or bonus.  So, we are going to sort our requirements to make this happen.

Now we need a value driven sort mechanism. Whatever is used to document the requirements, state requirements, features, user stories,  use-case slices or even implicit requirements, they are always there for a reason: benefits, in whatever form or shape (Stakeholder Needs, Benefits, Outcome).

Let’s imagine you are building a Sales Application with the following benefits:

  • Increased sales volume
  • Increased cross-selling
  • Less paperwork

These are only 3 items, but even if there were 10, it should not be that hard to have them prioritized by the stakeholders because we acknowledge that they want them all and they can get them all.  Key is to explain we need to know which ones are more important than others as part of risk management. You want them to be able to make the right decisions during the development in case something goes wrong , when they change their mind or when they are forced to make changes. Ask questions like : “Imagine we are faced with a 50% budget cut, what should we have focused on to make sure we  can still deliver something valuable.” It is just like buying a car. Is color more important over comfort? Or is cost effectiveness more important than fun? You can do this in a workshop, for example by dividing 10 points over the set benefits.

The next step is to build a cross-reference between the requirements (in this case use-case slices) and these benefits.  It is best to do this together with your stakeholders as well. See the example below.

MoSCoW Anxiety

And with the cross-reference in hand, we can determine an (initial) ordering based on the following order of priority: 1) More Sales, 2) Less paperwork and 3) More cross-selling. By doing that we get the following revised ordering of the use-case slices. Also see the example below.

MoSCoW Anxiety

When you have come this far, you have probably enough credits to ask your stakeholders to think of the smallest set use-case slice that still contributes towards the most of these benefits. And when you can, you have identified the must have requirements for the project. There are a few other things we can add to this approach and solve related problems but that is something for another post.