Of course this is nothing to do with the Russian city of Moscow, but images for prioritisation do not inspire much emotion, please forgive me for trying to capture attention.
MoSCoW prioritisation
This is commonly used in the agile environment, particularly during planning and during a sprint.
Simply put:
MUST - this is something that must be done, without it we will probably fail.
SHOULD - this is something that is important and should be done, but we won’t fail without it.
COULD - this is something we could do if we have time.
WON’T - this is something we won’t be doing at all because at this time we don’t need it (out of scope in project terminology)
What could be easier than that?
The challenge comes with the definition of the word ‘should’
It means two things depending on the intonation.
We should do that, or, we SHOULD do that.
The first intonation of ’should’ would indicate it is ok not to do it, the second implies that we really really SHOULD do it.
This image of prioritising a ball point pen illustrates what we mean by SHOULD, if your project was to only deliver the ink refill (MUST) and NOT deliver the SHOULD, your project would have failed. Yes the customer could actually write something, but they would not be happy.
If you decide to use this prioritisation technique you need to make it very clear that the word should means, like in the pen example, that you SHOULD do it, otherwise the technique falls into disrepute quickly. This is because users and customers will rapidly learn that the chances of getting a should delivered are minimal and the could’s have no chance of ever being looked at, therefore they, quite reasonably, decide that everything becomes a must.
Agile improves on MoSCoW in other ways too, in particular having fixed time and cost. In other words zero time and cost tolerance, and this doesn’t mean that you can finish early either, allowing a sprint to complete early can have a detrimental effect on MoSCoW too.
If we have flexibility for time, this means we can finish a little bit late or a little bit early. PRINCE2 calls this time tolerance.
If we have a backlog of requirements to complete with several sprints, which is the normal manner in which scrums and sprints are used, we would naturally start with the MUST have requirements in the first sprint, then finish the must haves in the second sprint but include some SHOULD haves too.
This would normally mean we have some time at the end where we don’t have enough to complete another must have or another should have, some teams will then stop that sprint and start another one so that we can get more MUST’S and SHOULD’S done, and the COULD’s get pushed aside.
The alternative is they extend the sprint a little bit to get the next MUST or SHOULD in because they tend to be larger than the COULD’s
With that thinking, the could’s never get done, and MoSCoW falls into disrepute once again and the users are back to making everything a must have requirement.
ALSO, at the end of each sprint we want to have a sprint review and a sprint retrospective, if we allow the time to be flexible they get skipped too.
For more help and guidance to make any project office, simply more agile:
https://www.amazon.co.uk/dp/B0BH5477LM
This is basically what scrum states.
ReplyDelete