Use the MoSCoW Prioritisation Method to Sort Requirements

Defining the scope and features of a project is vital in project management. The proper definition of these key characteristics of the deliverables of the project allows your project team to focus on a well-defined goal and vision. Furthermore, time shouldn't be wasted on useless features to keep the project within the deadlines.

The MoSCoW prioritisation method is a useful tool to sort through the requirements of a project and determine which features should be implemented in the final release or product. Learning how to use this framework could save you time and efforts, while preserving the quality and focus of your project.

Keep reading to learn more about how to use the MoSCoW analysis, with its pros, cons and alternatives. And to top it all off, other useful matrices often used in agile project management are discussed below.

Just like other agile tools (such as SCAMPER), this method is based on a mnemonic: the term MoSCoW is there to remind you of action verbs. The MoSCoW technique was developed by Dai Clegg, who also played an essential role in the development of the first agile methodologies in the form of the Dynamic Systems Development Method (DSDM), one of the early agile frameworks.

This prioritisation method can be used for just about anything, but is most often employed for agile projects and software development to sort user stories and technical requirements. Its principles are simple: not all features of the project are essential to its success. There are features that the project:

• Must have (Mo)
• Should have (Sc)
• Could have (Co)
• Won’t have, at least for now (W)

There are many advantages that make this technique a valuable prioritisation technique. The MoSCoW framework:

• Makes the vision more apparent, as words are used instead of numbers or generic terms such as “High” or “Low” to define the priority. This allows the team to focus on what to deliver, rather than argue about meaningless priority levels.
• It doesn’t allow for indecision by including a “Medium” option, yet is flexible enough to give some leeway for debate regarding a feature if the team doesn’t agree from the get-go.
• It’s intuitive and easy to understand, even for non-specialists. This could be especially useful when communicating with stakeholders.

In short, this method keeps it simple, verbal and understandable. Are you sold yet? If so, learn how to make the most of this tool right about… well, now!

As we’ve seen, this tool is designed to decide what requirements are important and prioritise them using 4 labels.

This category is reserved for items that are essential to the success of the project. They cannot be replaced and define the project globally. Must-haves should include:

• All functionalities that are required for compliance reasons. Compliance requirements could be related to security and privacy, or be legal obligations.
• All functionalities that could not be overlooked or replaced without making the product unusable. These key requirements are required for the product or software to accomplish the basic tasks it was designed for.

To sum up, this category regroups anything that could make the product or software impossible to release or sell.

Some basic examples could include characteristics such as:

• The homepage in the case of a website,
• The wheels to build a bike,
• Security standards to create a professional application...

These features are slightly different from the first category. The final product does not need “should have” functionalities to be functional and usable. However, these should be implemented throughout the course of product development because they add significant business value.

For example, these initiatives could be:

• Implementing a search function on a website,
• Make the bike capable of being used on many terrains...

The “could have” features are functionalities that would be nice to have, meaning that it would add some business benefits to the project, but less so than “should have” features. They aren’t prioritised: they are kept in the backlog if enough time is available to implement them. However, if the features from the first two categories take longer to develop than expected, they would be postponed or cancelled first.

In some cases, it could be useful to conduct a business analysis to determine the degree of importance and priority of an item, as “should” and “could” are similar in some aspects.

… For now. This group is the most important to define the limits of the scope of your project. It regroups the features that are unlikely to ever be implemented, either because they provide little value to your business, or because they would take too much effort. Or both.

But nothing is set in stone, so a handful of these features could be prioritised later on if deemed useful. Some argue that good practice is to subdivide this category into two subsections, one being “will not have”, and the other “will not have this time”. This allows the team, Project Manager or Product Owner to see which items could be added to the sprint backlog if there is time left for a few sprints before the deadline.

Though the MoSCoW technique is a widely used and fairly popular prioritisation tool, it isn’t exempt from criticism.

• The verbal basis of this technique makes it more subjective than pure statistics. While it’s useful to reach a consensus and for communication purposes, some may find the “should have” and “could have” categories too similar.
• The “won’t have” category can be seen as ambiguous. You should either:
  • Make it clear from the start whether it will include features that won’t be part of a specific release or items that should be scrapped completely.
  • Subdivide the category to keep these two types of features separate.
• If you go with the “won’t have for now” option, make sure that the scope of your project stays in check, as adding too many low-value items would defeat the purpose.
• It provides no native way to distinguish prioritisation levels for items within the same category.

Each prioritisation method has its own pros and cons, but some could be best suited to your needs. Below are some of the most popular alternatives to the MoSCoW model:

• User Story Mapping
• The Kano Model
• The RICE Scoring Model
• The PriX Method
• Cost of Delay

Additionally, other useful matrices exist in agile project management to set priorities, either for urgent tasks with the Eisenhower Matrix or in stakeholder mapping with the Power/Interest Matrix.

The MoSCoW prioritisation technique is a useful method to help you define the scope of your project. It is an intuitive matrix designed to spark a debate around which features are vital, and which would add the most value to your project.

Setting the right amount of work to put in a project means getting your priorities straight first. Don’t overlook the prioritisation process to plan your sprints and manage stakeholder expectations with confidence. Are you ready to tackle the steps of your project in the right order?