The MoSCoW Method, also known as the MoSCoW prioritization or MoSCoW analysis, is a well-known technique for managing requirements.
MoSCoW is an acronym that represents four categories of initiatives:
- must-have,
- should-have,
- could-have,
- won't-have, in the sense that you won't get it right now.
What is the History of the MoSCoW Method?
Dai Clegg, a software development expert, created the MoSCoW method when he worked at Oracle. He developed the tool to help his product management team prioritize tasks during the release development process.
If you want more details about the why and the how, you can consult this page about MoSCoW prioritization.
How Does MoSCoW method Work?
Before conducting a MoSCoW analysis, several things need to happen. Firstly, key stakeholders and the product team must align on the objectives and prioritize factors. Next, all participants must agree on the initiatives to prioritize.
The team also needs to discuss how they will address any misalignments in product prioritization. If you can figure out how to solve disagreements before they arise, you can prevent these points from holding up progress.
Thus, you will also need to agree on the percentage of resources you want to allocate to each group.
Once this foundation work is over, you can determine which category is most relevant to each effort.
MoSCoW Prioritization Categories
1. Must-have category
As the name implies, this category includes " must-haves " initiatives for the team and project. They are the non-negotiable necessities for the project, services, or product you are working on now.
The "must-have" status requires the team to complete a mandatory task. To know if your choice is relevant, ask yourself the following questions.
If the product fails without that initiative or becomes unnecessary without it, it means that the action is most likely a "must-have."
2. Should-have category
Desirable initiatives are just one step lower than important initiatives. They are fundamental to the product, service, or project but are not critical. The product or project still works if they still need to be taken care of. However, initiatives can add significant value.
Should-have initiatives are different from must-have initiatives in that they can be scheduled for a future release without impacting the current release. For example, performance improvements, minor bug fixes, or new features may be "must-have" initiatives. Without them, the product still works.
3. Could-have category
Another way to describe "possible" initiatives is to describe them as pleasant. "Possible" means that they are not mandatory for the project's primary purpose. Nevertheless, compared with "necessary" initiatives, they have a far lower impact on the result if they are not taken into account.
Thus, initiatives placed in this category are frequently the first to be postponed if something new comes up.
4. Wont'-have category
One advantage of the MoSCoW method is that it assigns many initiatives into the "don't have" category. This category allows you to manage what the team will not have to include in a particular release or any other deadline you will prioritize later.
Placing items in the "not to have" category is a way to avoid slippage. If these initiatives are in this category, the staff knows they are not a primary focus for that specific period.
Some items in the "don't have" category will be a priority in the future, while others are not likely to occur. Some teams decide to differentiate these by creating a subcategory within this group.
How Can Development Teams Use MoSCoW?
The creator of the Moscow method Dai Clegg designed this method to help his team to prioritize tasks based on his team's limited time. Still, the MoSCoW method also functions when a development team faces restrictions other than time.
Prioritize based on budgetary constraints.
Suppose your project has a tight budget imposed by the company. The team will have to use the MoSCoW method to decide which tasks are the "must haves" and "want to haves" in collaboration with the product managers. A limited budget can become an excellent constraint to organizing the team workflow. The team can determine which items they can achieve.
Prioritize based on the team's skillsets.
A cross-functional product team might also be limited by its designers' or programmers' experience and expertise if the project roadmap calls for technology that the team needs, for instance. This constraining factor will play into scoring these elements in their MoSCoW analysis.
Prioritize based on competing needs at the company.
Other business priorities may also restrict cross-functional teams. The team wants to make progress on a new product launch, but the executive staff has set tight deadlines for other launches in the same time frame. In this case, the team can use MoSCoW to determine which aspects of the desired release are critical and temporarily put everything else on hold.
What are the disadvantages of prioritizing MoSCoWs?
While many product teams have prioritized MoSCoWs, this approach has potential pitfalls. Here are some examples.
1. A confusing scoring process can put tasks in the wrong categories.
A popular complaint against MoSCoWs is that they do not include an objective methodology for rating initiatives. Your team will need to bring that methodology to your review. The MoSCoW approach only ensures that your team implements a consistent scoring system.
2. Wrong stakeholders lead to putting items in non-relevant categories.
To determine which actions from your team are critical to your product and merely desirable, you'll need as much context as possible.
For example, you might need a member of your marketing team to let you know how vital a new feature is attractive to potential buyers.
One of the traps of the MoSCoW approach is that you may need to ask relevant stakeholders to make correct judgments about where to place each feature.
3. Team bias can affect the efficiency of MoSCoW.
As we saw above, there is no objective scoring method in MoSCoW, so your team members may need help with their opinions on particular situations.
One of the risks of using MoSCoW ranking is that staff may erroneously believe that MoSCoW itself is an objective way to measure the elements on their list. They discuss one initiative, agree that it is a "must-do" and move on to the next.
But your team will also need an objective and consistent framework for ranking all initiatives. This is the only way to minimize your team's bias for or against items.
To sum up - when is it interesting to use the MoSCoW Method?
The MoSCoW method can be used if you plan to involve various company stakeholders.
An additional benefit of using MoSCoW is that it enables you to determine how much effort to put into each topic. As a result, you can be sure that you address a good variety of issues in each release.