MoSCoW method

What is the MoSCoW method?

The MoSCoW method is a four-step approach to prioritizing which project requirements provide the best return on investment (ROI). MoSCoW stands for must have, should have, could have and will not have -- the o's make the acronym more pronounceable.

A variety of business disciplines use the MoSCoW method. It enables everyone involved in a project to know what work to complete first and how that work helps increase revenue, decrease operational costs, improve productivity or boost customer satisfaction. On the business side, it can help stakeholders frame discussions about the importance of specific product features when choosing a software vendor. On the IT side, the MoSCoW method plays an important role in Agile project management by helping project teams prioritize story points.

Furthermore, prioritizing requirements enables project teams to understand the amount of effort and resources each project element requires. This knowledge improves the team's time management, makes the project more manageable, increases the likelihood of completion by deadline and optimizes ROI.

The MoSCoW method is also known as MoSCoW analysis, MoSCoW prioritization, MoSCoW technique and MoSCoW rules.

Prioritization of requirements

Before implementing the MoSCoW method, businesses must ensure the teams involved in the project and other stakeholders agree on the project objectives and the factors they use for prioritization. They should also establish plans for settling disagreements.

Next, teams should decide what percentage of resources they assign to each category. For example, they could allocate 20% of the resources to the could-have requirements, while giving 40% to must-haves and 30% to should-haves.

Once the teams and stakeholders gather requirements and reach agreements, then the teams can start assigning requirements to each of the following four categories.

1. M: Must have

This first category includes all the requirements that are necessary for the successful completion of the project. These are non-negotiable elements that provide the minimum usable subset of requirements.

Statements that are true for must-haves include the following:

• There is no point completing the project by its target deadline without this requirement.
• The final product or software would not be compliant or legal without this requirement.
• The final product or software would not be safe without this requirement.
• The final product or software does not deliver an effective solution without this requirement.

If there is any way to work around a particular requirement, teams should consider it a should-have or could-have element. Assigning requirements to the should-have and could-have categories does not mean the team won't deliver the element; it just reveals that it is not necessary for completion and, therefore, is not guaranteed.

2. S: Should have

This second category of requirements is one step below must have. It can prep requirements for future release without impacting the current project. Should-have elements are important to project completion, but they are not necessary. In other words, if the final product doesn't include should-have requirements, then the product still functions. However, if it does include should-have elements, they greatly increase the value of the product. Minor bug fixes, performance improvements and new functionality are all examples of requirements that could fall into this category.

Teams can distinguish a should-have element from a could-have element by assessing the amount of pain caused by leaving the requirement out. This is often measured in terms of the business value or the number of people affected by its absence.

3. C: Could have

This category includes requirements that have a much smaller impact when left out of the project. As a result, could-have requirements are often the first ones teams deprioritize -- must-have and should-have requirements always take precedence as they impact the product more. An example of a could-have is a desirable but unimportant element.

4. W: Will not have

This final category includes all the requirements the team recognizes as not a priority for the project's time frame. Assigning elements to the will-not-have category helps strengthen the focus on requirements in the other three categories, while also setting realistic expectations for what the final product does not include. Furthermore, this category is beneficial in preventing scope creep -- or the tendency for product or project requirements to increase during development beyond what the team anticipated.

The team can eventually reprioritize some requirements in the will-not-have group and work them into future projects; others are never used. To differentiate between these types of elements, teams can create subcategories within the will-not-have group to identify which requirements they should still implement and which they can ignore.

MoSCoW method for Agile

The Agile project management methodology breaks projects into small sections called iterations. Each iteration focuses on completing specific project elements in work sessions called sprints -- typically lasting two to four weeks. The MoSCoW method is frequently used within Agile project management to determine which elements -- including tasks, requirements, products and user stories -- the team should prioritize and which can be put on hold. These decisions make an Agile project schedule that enables teams to rapidly deploy solutions, more efficiently use resources, increase their flexibility and adaptability to changes, and more quickly detect issues.

Advantages of the MoSCoW method

The MoSCoW method is easy to use and understand. It can help individuals with prioritization, but it more greatly benefits project teams. Other advantages include the following:

• Resolves disputes and form agreements with stakeholders.
• Ensures a minimum viable product is produced.
• Sets priorities at different levels of the development pipeline.
• Enables categorizing requirements to rely on the expertise of the team.
• Can be used for both existing and new projects.

In addition, the MoSCoW method enables users to assign specific percentages of resources to each of the four categories. This action ensures resources are effectively managed ,and it optimizes productivity analysis.

Criticism of the MoSCoW method

However, there are some drawbacks with the MoSCow method, including the following:

• There is uncertainty surrounding will-not-have requirements and whether they are left out of the release or the entire project.
• There's no clear way to prioritize requirements within the same category.
• There is no reasoning for why one requirement is a must-have and the other is a should-have.
• If an organization's decision-making process excludes collective leadership, prioritization may become subjective and inefficient.

History of the MoSCoW method

The MoSCoW method has its roots in the dynamic systems development method -- an Agile project delivery framework that aimed to improve rapid application development processes.

Software development expert Dai Clegg created the MoSCoW method while working at Oracle, the multinational computer technology corporation. Clegg initially designed the prioritization technique for timeboxed projects and initiatives within releases.

Editor's note: This article was reformatted in 2023 to improve the reader experience.