In a time-constrained project, it is critical to understand the relative importance & prioritisation of the work to be done in order to make progress & meet deadlines.
The MoSCoW method aids in this understanding of a project’s priorities. Whilst the practice of prioritisation is most commonly used on requirements & User Stories, it can also be applied to tasks, products, Use Cases, acceptance criteria, & tests.
In this article, we’ll take a deeper dive into this method of project prioritisation to give you a better overview & understanding of this often-overlooked practice.
What is the MoSCoW Method?
The MoSCoW method, also known as “MoSCoW prioritisation” or “MoSCoW analysis”, is a prioritisation technique.
The method is employed as a means to reach a common understanding with stakeholders on the importance they place on the delivery of each project requirement. The reason for this is to help develop a clear view of a client’s needs & priorities. This is necessary due to the often vague & bare list of requirements highlighted at the project’s start.
In using the MoSCoW methodology, those developing the project can avoid disappointing the client at the project’s end due to not having entirely understood their needs.
What Does MoSCoW Stand for?
The MoSCoW method, while sounding like it should offer some level of Russian intrigue, is an acronym derived from the first letter of each of four prioritisation categories:
M – Must have
S – Should have
C – Could have
W – Won’t have
Prioritisation of Requirements
It must be stated that all requirements are important; however, in order to provide the most impactful & immediate business benefits, the requirements must be prioritised.
When developing a project, a project team will treat the MoSCoW method as a list, seeking to deliver everything in the “Must Have” category first, before moving onto the “Should Have” second, then the “Should Have”, & finally the “Would Have”. In doing so, should the project’s timeframe be threatened, the last two category requirements (i.e. “Should Have” & “Would Have”) will be the first to be removed to free up time, energy, & resources.
Everything in this category meets the Minimum Usable SubseT (MUST) of requirements that the project guarantees to meet. These can be easily identified by following the guidelines below:
- Without this requirement, there’s no point in delivering on the target due date.
- Not having this requirement is illegal.
- It is unsafe not having this requirement.
- It is not possible to deliver a viable solution without this requirement.
Typically speaking, the “Must Have” category provides no more than 60% of the project’s overall effort.
When placing requirements in the “Must Have” category, it’s best to ask the question “what happens if this requirement is not met?” If the answer is “cancel the project as there’s no point in implementing it without this requirement”, then it’s most definitely a “Must Have” requirement. If there’s a way around this requirement for the project to still go live, then it can be placed within the “Should Have”, or even the “Could Have” categories.
Requirements placed within the “Should Have” category can be easily defined as the following:
- An important requirement, but not essential.
- It may be painful to leave out this requirement, but the end product is still viable.
- A workaround (perhaps just a temporary one) may be needed if this requirement is not met.
It can be challenging to identify what should be categorised as either “Should Have” or “Could Have”. A good way of identifying this is to review the degree of pain caused should this requirement not be met. For example, measuring the business value or the number of people affected.
Those requirements placed within the “Could Have” category are defined as:
- Requirements that are wanted, or desirable, but are less important than others.
- The impact felt should it be left out is less than those placed in the “Should Have” category if they too were to be left out.
The requirements found in this category tend to be the main area of contingency. This is because these requirements will be delivered in their entirety in a best-case scenario. This means that if problems arise & the deadline is jeopardised, these requirements will be the first to be dropped from the timeframe.
It’s also important to remember that classifying a requirement as “Should Have” or “Could Have” doesn’t mean it won’t be delivered; rather, it means delivery isn’t necessarily guaranteed.
The requirements placed in this category are those in which the project team has agreed will not be met (at least during this timeframe). As such, they are recorded in the Prioritised Requirements List, where they aid in clarifying the project’s scope. This is done to prevent them from being informally reintroduced at a later date. This also helps in managing client & project expectations by stating that these requirements will simply not be included in the final product – but this does not mean that they won’t/can’t be added at a later time.
Having a coherent list of requirements within the “Won’t Have” category can be very effective in maintaining focus on the more important requirements found in the other categories.
The MoSCoW method is often used with timeboxing, where a deadline is fixed so that the focus must be on the most important requirements. Due to the nature of the method, it’s most commonly used in agile software development approaches such as Scrum, rapid application development (RAD), & DSDM.
The method also overcomes issues associated with a simpler approach to prioritisation. Some common examples of such approaches include the use of “High”, “Medium”, & “Low” labelling & simple sequential tags (e.g. 1,2,3,4,…). However, these approaches fall short of the MoSCoW method due to having unclear definitions & no clear indication as to what a client can expect come the project’s end.
As such, the MoSCoW method’s specific use of “Must Have”, “Should Have”, “Could Have”, or “Won’t Have” provides a clear indication of the level of importance for a particular requirement as well as what’s to be expected upon completion.
Downsides of the MoSCoW Method
While the MoSCoW method has proven to have great practical implications for requirement prioritisation, like with most things, it has some downsides.
For starters, as previously mentioned with requirement priority labelling, it can be challenging to get into the flow of determining what should be categorised as what (i.e. is something a “Should Have”, or a “Could Have”?). Plus, it does not always help when deciding between multiple requirements with the same priority (you’d need a subset of priority labelling within each category & that just becomes confusing & unnecessary).
There can also be ambiguity over the timeframe, especially with “Must Have” requirements. It needs to be made clear whether something should be scheduled for this release or a later one.
Lastly, by not including all relevant stakeholders, some requirements can either be miscategorised or overlooked entirely. As such, ensuring that all interested parties have been included before the project’s kick-off is a must in order to not fall into the trap of delivering something that’s only 90% complete.
As you can see, the MoSCoW method is very practical for small Agile teams. While there are many varieties of task prioritisation methods, the MoSCoW method meets in the middle of simplicity & functionality.
Like with most things, it can take some getting used to, especially moving from project to project where the deliverables (& the team) will change. However, with practice, it’s a method that leads to improved time management & team organisation, as well as greater client satisfaction & project success rates.
What do you think about the MoSCoW method? Have you had any experience using it?
Let us know your thoughts in the comments below!
The Zenkit Suite is an ideal solution for project management, database creation, team collaboration, & more.
Discover more about the Suite in our Knowledge Base.