What is MoSCow technique?
The MoSCoW method is a prioritization technique used in management, business analysis, project management, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement; it is also known as MoSCoW prioritization or MoSCoW analysis. MoSCow Prioritisation Technique plays a key role in Agile Project Management. In an Agile project it is vital to understand the importance of different things. This is because time is a fixed resource, so prioritisation is applied to requirements, tasks, products, user cases, etc. Be very careful, this is not Agile technique (include Scrum, Kanban, XP and so on) however this technique is widely used in Agile. There are some questions in almost all certifications regarding MoSCoW technique.
Prioritization of MoSCoW requirements
All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver all the Must have, Should have and Could have requirements but the Should and Could requirements will be the first to be removed if the delivery timescale looks threatened.
These provide the Minimum Usable Subset (MUS) of requirements which the project guarantees to deliver. This may be defined using some of the following:
Cannot deliver on target date without this
No point in delivering on target date without this; if it were not delivered, there would be no point deploying the solution on the intended date
Not legal without it
Unsafe without it
Cannot deliver the Business Case without it
Ask the question, “what happens if this requirement is not met?” If the answer is “cancel the project – there is no point in implementing a solution that does not meet this requirement” then it is a Must Have requirement. If there is some way round it, even if it is a manual workaround, then it will be a Should Have or a Could Have requirement. Downgrading a requirement to a Should Have or Could Have does not mean it won’t be delivered, simply that delivery is not guaranteed.
Important but not vital
May be painful to leave out, but the solution is still viable
May need some kind of workaround, e.g. management of expectations, some inefficiency, an existing solution, paperwork, etc.
A Should Have may be differentiated from a Could Have by reviewing the degree of pain caused by it not being met, in terms of business value or numbers of people affected.
Wanted or desirable but less important
Less impact if left out (compared with a Should Have)
Won’t Have this time
These are requirements which the project team has agreed it will not deliver. They are recorded in the Prioritised Requirements List where they help clarify the scope of the project and to avoid being reintroduced ‘via the back door’ at a later date. This helps to manage expectations that some requirements will simply not make it into the delivered solution, at least not this time around.
MoSCoW (Must Have, Should Have, Could Have, Won’t Have this time) is primarily used to prioritise requirements, although the technique is also useful in many other areas. Atern recommends no more than 60% effort for Must Haves for a project, with 40% Shoulds and Coulds. Anything higher than 60% poses a risk to the success and predictability of the project, unless the environment is well understood, the team is established and the external risks are minimal.