What is the MoSCoW Method?

Often in the course of the MoSCoW method an acronym is spoken; since the lower-case letters serve only the readability, this is not completely correct, but by the use of the o’s the principle can be pronounced simply like the Russian capital.

The four categories of the MoSCoW method

What exactly do the four categories mean?

Must (have) – the category for “must” requirements. They are considered non-negotiable and should not conflict with other mandatory requirements. If you apply the Business Analysis Body of Knowledge – BABOK for short – they should also be complete, consistent, correct, implementable, modifiable, unambiguous and testable.

Should (have) – the category for “target” requirements. Ideally, requirements that end up in this category should also be implemented. However, since the priority is lower than for “mandatory” or “must” requirements, which always have to be implemented as a matter of priority, they may be implemented in subsequent releases or projects.

Could (have) – the category for “can” requirements. They can be implemented after the “must” and “should” requirements have been implemented. They are therefore also referred to as “nice to have”. In the event of time bottlenecks or resource conflicts, these requirements are first postponed or not realised.

Won’t (have) – the category stands for requirements that are not implemented. Alternatively, the W is also interpreted as Would – would be nice if it could soon be implemented – or Want – is desired, but in another project, project or release – interpreted. Basically it is recommended to document requirements within this category as well, because in this way it can be understood whether a seemingly new requirement has already been recorded. In addition, documented requirements can serve as a source in future projects.

In practice, both “must” and “should” requirements usually end up in further documents such as requirement specifications or business cases. “Could” requirements and requirements that cannot be implemented, however, usually remain in internal backlogs, lists or tools.

Advantages and disadvantages of the MoSCoW method

The MoSCoW method offers some clear advantages:

• There is a simple categorisation of requirements – ideally in coordination with the stakeholders. The use of the words Must, Should, Could and Won’t provides clarity about the meaning of the categories at all times.
• The classification of requirements (or goals, tasks, change requests, etc.) results in a natural order of implementation.
• The principle behind the method is very easy to understand, so that stakeholders and developers can easily find a common denominator.

On the other hand, the MoSCow method also has some disadvantages:

• The classification as such is relatively rough and does not provide any indicators of the order in which requirements are to be implemented within the individual categories. Therefore, at least the “must” and “should” requirements should be considered in more detail. Technical dependencies, effort, resources – there are some aspects that are useful for further sorting within the categories.
• In practice it happens again and again that a large part of the requirements are declared as “must” requirements. The classification of requirements into other categories leads at best to a later implementation, in the worst case they are not realised at all. Some guidebooks therefore recommend, for example, to declare a maximum of 60% of the requirements as “must” requirements; however, such suggestions are very short-sighted, because they do not change the worries of the requirements providers, they ignore any development capacities and of course do not answer the question “which requirements belong to the ominous 60%?
• As with many methods, it is a key date observation. Stakeholders can change their minds, technical challenges can arise, and new requirements or changes can be added – so it’s not uncommon for requirements to wander within categories.
• We are happy to recommend categorising according to the wishes and ideas of stakeholders. Here, however, there are other concepts, such as the Kano model of customer satisfaction, which take a more differentiated view of requirements. Companies should therefore consider combining different methods and principles in the course of analysis and prioritisation.

Notes:

There is an alternative interpretation of the lower case o’s: If they are understood as “or”, two opposing categories arise, i.e. Must or Should and Could or Would or Won’t.

Here you can find an Video about Agile in Practice: Prioritisation using MoSCoW.

And here you can find additional information from our blog:

t2informatik develops and modernises software as a service provider. Click here to learn more.