The MoSCoW method: balancing needs and resources

In the course of a project, new requirements, goals and tasks keep emerging. On this basis important decisions have to be made that may or may not influence the project goal. Since projects are usually time-critical, the team will want to deal with the most important requirements for the project first. To find out what these are, the MoSCoW method can be used. It helps to prioritise the requirements in a meaningful way and to assess which ones should be worked on first. 

For this purpose, the method is divided into four requirements: Must, for essential requirements; Should, for non-critical requirements; Could, for irrelevant requirements; and Won’t, for requirements that may be used later. Must, Should, Could and Won't make up the acronym MoSCoW.

The most important category is the Must category. It contains all requirements that are essential to the success of the project and are non-negotiable. If these requirements were only partially implemented or even neglected, this would lead to the failure of the project. They represent the minimum requirements for the project.

The Should category is not critical to the success of the project. Nevertheless, the project can only be implemented with restrictions if the requirements of this category are not met. This shows that they are highly relevant and will be taken into account during implementation and possibly also incorporated as soon as all Must requirements have been completed, as these have priority. However, if this is not possible, e.g., due to time constraints, the Should requirements can either be moved to a new phase or implemented with a similar project. 

In the Could category, the requirements only have a low relevance, they are also called “nice to have”. These requirements are only processed if capacities are still available in addition to the Must and Should requirements. They should not be ignored, as they can sometimes also generate added value and should therefore be seen in context. Many of these requirements come from the stakeholders, but not all of them can be implemented. By placing the requirements in this category, stakeholders see that their ideas are not discarded and thus they are at least partially satisfied.

Requirements in the Won’t category are neither time-critical nor important for the project, but still technically interesting. They remain in this category until a new project phase begins in which they are reprioritised. 

To illustrate this, let's take a very simple example. If you imagine the production of a ballpoint pen, you could say that a Must requirement is that the pen should write. A Should requirement could be that the pen should have a company logo in the corporate identity colour. A Could requirement could be that the pen has something to attach to a pad and a Won't requirement could be that the pen is produced in different colours. This can be addressed after a certain level of success.

The method makes it possible to identify the requirements that are critical to the success of the project and thereby determine which requirements should be addressed first. In this way, it can be avoided that tasks are processed that do not actually have priority yet. Especially when the end of a Sprint or a phase is approaching, it is possible to assess what still needs to be done or which tasks should be avoided. But this method is not only helpful at the end of a Sprint or phase, but also at the beginning. Particularly at the start of a new project where a new product is being created, this allows the minimum requirements for the product to be prioritised so that it can be brought to market, and then updates can be issued with the other requirements. This also helps to work efficiently as time is saved by only spending it on the most important requirements first.

When applying the method, about 60 % of the requirements should fall into the Must category and the rest into the other categories. However, if it turns out that too many requirements fall into the Must category, this can lead to bottlenecks and delays. Trying to do too many things at once can lead to congestion because there are not enough people to do them all properly. Are there too many requirements and not enough time to meet them, or are the requirements wrongly prioritised? Depending on the answer to these questions, the project should be adjusted accordingly. However, this cannot be decided by the MoSCow method alone, which is discussed below.

The requirements for the Must and Should categories are very similar. For this reason, care must be taken not to confuse them, as overlooking a Must requirement that is essential to the success of the project can have serious consequences. Therefore, the question should always be asked whether this requirement can be fulfilled at a later date or whether the goal will then be missed. 

In this context, it should also be mentioned that the requirements must be processed in the order mentioned above, otherwise tasks will be overlooked that should have been completed long ago or tasks will be processed that do not contribute to the success of the project at all. 

Especially in an agile working world like Scrum, MoSCoW should be reviewed again and again. After all, when a Sprint is completed, a new Sprint Goal is set to which new requirements fit, or stakeholders have new requirements that they want to see implemented. Stakeholder requirements should not be ignored as they have a significant impact on the success of the project. However, requirements have different priorities during a project phase. So, if a requirement is not implementable at that time, it should still be included, either in the Could or Won’t category. This way, stakeholders know that the requirement has been heard and will be implemented or re-evaluated at a later stage.

As mentioned earlier, stakeholder requirements cannot and should not be ignored. However, they should always be seen in the context of stakeholder communication. Stakeholder analysis is about knowing how to deal with stakeholders and their needs. Risk management should also be used in the context of the method, or the results of risk management should be used in the prioritisation of requirements. Therefore, if the MoSCoW method is used, it should only be used in conjunction with other project management methods and frameworks, as this can improve its informative value. 

The scope of services agreed between client and contractor must also be taken into account. Because if there is a fixed deadline and a fixed budget, prioritising the requirements should lead to initially only completing the tasks that are in the Must area. If resources are then still available, further requirements from other categories can be dealt with.

The MoSCoW method is a good asset for prioritising project requirements. In combination with other methods, the right selection of requirements can be made. The requirements that are most important for the implementation of the project are dealt with first. This ensures that the team works efficiently, resources are used optimally, and the project is completed at the right time.