Today we are discussing MoSCow Prioritisation method. You can use the MoSCoW method to prioritise any tasks, personal or professional. If you are a student, you can too use the MoSCoW method to prioritise your tasks and study.
Prioritisation can be applied to requirements, tasks, products, use cases, user stories, acceptance criteria and tests.
A rule of thumb often used is that Must Have requirements do not exceed 60% of the effort and the remaining 40% of the effort should be split about evenly between Should Have and Could Have/Contingency planning.
The MoSCoW Rules
Must Haves provide the Minimum Viable Product (MVP) of requirements which the project guarantees to deliver. This may be defined using some of the following items:
- These are non-negotiables
- Can't deliver on target date without this
- Not legal without it
- Unsafe without it
- Can't 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 around 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.
Should Haves are;
- 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, or a little extra 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.
Could Haves
- Wanted or desirable but less important
- Less impact if left out (compared with a Should Have)
Won't Haves this time at all
- These are the 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.
These priorities should always be under review even during the project. If or any new work arises during the project priorities can be upgraded or downgraded as per the requirement.
MoSCoW method is also a great way to form conversations with your clients and discover what they want and what's the most important and least important item
According to Agile Business Consortium tips for assigning priorities are as follows:
- Start all requirements as Won’t Haves and then justify why they need to be given a higher priority.
- For each requirement that is proposed as a Must Have, ask: “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.
- Ask: “I come to you the night before deployment and tell you there is a problem with a Must Have requirement and that we can’t deploy it – will you stop the deployment?” If the answer is “yes” then this is a Must Have requirement.
- Is there a workaround, even if it is manual? If there is, then it is not a Must Have requirement. Compare the cost of the workaround with the cost of delivering it, including the cost of any associated delays.
- Ask why is the requirement needed – for this project and this increment.
- If there is a Business Case in sufficient detail, can it be used to justify the intended priority? If not, create one.
- Is there more than one requirement implied in a single statement? Are they of the same priority? Decompose the requirement!
- Is this requirement dependent on any others being fulfilled? A Must Have cannot depend on the delivery of anything other than a Must Have because of the risk of it not being there.
- Allow different priorities for levels of acceptability of a requirement. For example. “The current back-up procedures will be followed to ensure that the service can be restored as quickly as possible.” How quick is that? Given enough time and money, that could be within seconds. They may say that it Should happen within four hours, but it Must happen within 24 hours, for example.
- Can this requirement be decomposed? Is it necessary to deliver each of those components to fulfil the requirement? Are the decomposed elements of the same priority as each other?
- Tie the requirement to a project objective. If the objective is not a Must Have, then probably neither is the requirement relating to it.
- Remember that team members may cause scope creep by working on the fun things rather than the important things. MoSCoW can help avoid this.
- Does the priority change with time? For example, for an initial phase, it is a Could Have (Nice-to-have) but it will be a Must Have for the second increment.
- Prioritise defects/bugs, using MoSCoW.
- Prioritise testing, using MoSCoW.
- Use MoSCoW to prioritise your To Do list. It can be used for activities as well as requirements.
Criticism
Criticism of the MoSCoW method includes:
- Does not help decide between multiple requirements with the same priority.
- Lack of rationale around how to rank competing requirements: why something is must rather than should.
- Ambiguity over timing, especially on the Won't have category: whether it is not in this release or not ever.
- Potential for political focus on building new features over technical improvements (such as refactoring).
MoSCoW was developed by Dai Clegg of Oracle UK in 1994 and has been made popular by exponents of the Dynamic Systems Development Method (DSDM).
Sources:
https://en.wikipedia.org/wiki/MoSCoW_method
https://www.agilebusiness.org/content/moscow-prioritisation-0
https://www.projectsmart.co.uk/moscow-method.php
https://www.projectmanager.com/training/prioritize-moscow-technique
