MoSCoW method
The MoSCoW method is a four-step approach to prioritizing which project requirements will provide the best return on investment (ROI). MoSCoW stands for must have, should have, could have and will not have -- the o's were added to make the acronym more pronounceable.
The MoSCoW method is used across a variety of business disciplines. It allows everyone involved in a project to know what work needs to be completed first and how that work will help 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 information technology (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 that will be required for each project element. This knowledge will improve the team's time management, make the project more manageable, increase the likelihood of it being completed by its deadline and optimize the 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 that will be used for prioritization. Plans for settling disagreements should also be established.
Next, teams should decide what percentage of resources will be assigned to each category. For example, 20% of the resources could be allocated to the could-have requirements, while 40% is given to must-haves and 30% is given to should-haves.
Once the requirements have been gathered and agreements have been reached between the business and stakeholders, then the teams can start assigning requirements to each of the following four categories:
M -- Must have. This first category includes all the requirements that are necessary for the successful completion of the project. These should be non-negotiable elements that provide the minimum usable subset (MUST) of requirements.
Must-haves can be defined as:
- 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 will not deliver an effective solution without this requirement.
If there is any way to work around a particular requirement, then it should be considered a should-have or could-have element. It is important to note that assigning requirements to the should-have and could-have categories does not mean the element won't be delivered; it just reveals that it is not necessary to completion and, therefore, is not guaranteed.
S -- Should have. This second category of requirements is one step below must have; it can be used to 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 should-have requirements are not included in the final product, then the product will still function. However, if should-have elements are included, then they will 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.
A should-have element can be distinguished 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.
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 to be deprioritized -- must-have and should-have requirements will always take precedence.
Could-haves can be defined as:
- A desirable element, but an unimportant one.
- Leaving out this requirement will impact the product less than leaving out a should-have element.
W -- Will not have. This final category includes all the requirements that have been recognized as not a priority for the project's timeframe. 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 will not be included in a final product. Furthermore, this category is beneficial in preventing scope creep -- or the tendency for product or project requirements to increase during development beyond what was anticipated.
Some requirements in the will-not-have group will eventually be reprioritized and worked into future projects; others will never be used. To differentiate between these types of elements, subcategories can be created within the will-not-have group to identify which requirements should still be implemented and which can be ignored.
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 -- should be prioritized and which can be put on hold. These decisions can be used to make an Agile project schedule that allows 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 method can be used to resolve disputes and form agreements with stakeholders.
- The analysis can be used to ensure a minimum viable product (MVP) is produced.
- The method can be used to set priorities at different levels of the development pipeline.
- Categorizing requirements relies on the expertise of the team.
- The method can be used for both existing and new projects.
In addition, the MoSCoW method allows users to assign specific percentages of resources to each of the four categories. This action will ensure resources are effectively managed and it will optimize productivity analysis.
Criticism for the MoSCoW method
Criticism for the MoSCoW method includes:
- There is uncertainty surrounding will-not-have requirements and whether they are left out of the release or the entire project.
- There's no way to prioritize requirements within the same category.
- There's no real 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, then the prioritization may become subjective and inefficient.
History of the MoSCoW method
The MoSCoW method has its roots in the Dynamic Systems Development Method (DSDM) -- an Agile project delivery framework that aimed to improve rapid application delivery (RAD) 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.
