Prioritising the MoSCoW Way
By Pam Ashby | 28 June 2018
One of the valuable aspects about Agile is that it is all at once an approach, a mindset, a framework and a set of tools. Whether you are a business leader, a software developer, a transformation expert, an HR professional or a marketer will influence how you use what Agile has to offer. Using it as a holistic perspective for the whole organisation is without doubt going to bring the best results, but it is possible to use specific techniques on their own as well. One of the most valuable is MoSCoW Prioritisation, and Jenny Bailey invited Consortium Director Andrew Craddock to explain its use in a recent Consortium webinar.
“Before MoSCoW everything in a project specification was a requirement,” Andrew reflects, “And everything had to be done! There was no concept of prioritisation in the 90s. The whole specification had to be delivered, even if this meant that extra time and budget had to be added onto the project. The result was that most projects went over time and over budget.”
Change is inevitable, and there has to be flexibility in some aspect of a project. Traditionally, time and budget were flexed to deliver the full requirements specified. Agile Project Management (AgilePM®) turned this on its head, fixing time and budget and allowing requirements to flex instead. The success of this depends on having an effective means of prioritising how important each specific requirement is. When something in the business changes, and a new requirement is suggested, how can we know what needs to be pulled out of the list so that cost and delivery time are able to remain the same?
MoSCoW stands for
Won’t have this time
“One of the absolute rules,” Andrew stresses, “is to respect the definition of Must.”
This seems to be how many of us go awry with MoSCoW and potentially end up with everything being a ‘Must’!
The Difference between MUST and SHOULD
Andrew explains that something should only be prioritised as a ‘Must’ if its lack would make the project unsafe, unusable or illegal. The acid test to determine if a requirement really is a must is to ask “if this single requirement can’t be met, should we cancel the project?” If the answer is “yes” then it probably is a ‘Must’ if the answer is “no” then it probably isn’t. So for a marketing campaign involving data capture, registration with the ICO (Information Commissioner’s Office) would be a ‘Must’. Without that the project would not be legal and it should not go ahead. Andrew tells us that it’s perfectly acceptable for a project to have no ‘Musts’.
Even though they aren’t ‘Musts’, a ‘Should-have’ requirement is really important. “These are the things that deliver the business case,” says Andrew. “They need to be carefully and dynamically prioritised focusing only on the business need and filtering out personal ‘I want’ perspectives.” MoSCoW has the benefit of aligning everyone around what delivers the most valuable benefit to the business. This protects the project from prioritisation based on individual rather than organisational needs.
The Concept of Contingency
Parkinson’s Law dictates that work expands to fill the time available for its completion. In traditional projects where contingency has been allowed, it always gets used. When requirements are prioritised with MoSCoW there is no specific contingency. The aim is to deliver all the requirements and flexibility is derived from varying the prioritisation; for instance, some ‘Could-haves’ may be relegated to ‘Won’t have this time’. Working in this way also avoids schedules being ‘padded’ to build in invisible contingency. In line with the principles of Agile working, MoSCoW allows for transparency and honesty about what can and cannot be delivered amidst changing circumstances. “MoSCoW avoids having that empty space for work to expand into” Andrew continues. “When an issue arises, you always have to have the conversation and discuss the real priorities. This helps to keep teams aligned with the project goals, and to keep everything under control.” He stresses that these are collaborative conversations so that so that priorities are changed with the business being fully engaged in the process.
“Above all,” he concludes, “Businesses want predictability. They need to know when benefits can be delivered so that they can start exploiting their value.” MoSCoW encourages collaborative effort – a whole business perspective and an attitude of ‘as soon as we can’ rather than ‘I want it now’.
Logged in members can listen to this whole discussion between webinar presenter Jenny Bailey and Consortium Director Andrew Craddock in Resources.
The material published in the Blog area of this website, is provided independently by our bloggers and any opinions expressed are those of the individuals and not necessarily of the Agile Business Consortium. The Agile Business Consortium does not accept any legal responsibility for any content or opinion published in the Blog area of this website.