MoSCoW prioritization, also known as the MoSCoW method or MoSCoW analysis, is a popular prioritization technique for managing requirements. The method is commonly used to help key stakeholders understand the significance of initiatives in a specific release.

The acronym, MoSCoW, stands for 4 different categories of initiatives: must-haves, should-haves, could-haves, and will not have at this time. Sometimes, the “W” in MoSCoW is used to stand for “wish” instead of “will not have right now.”

History of the MoSCoW Method During his tenure at Oracle, software development expert, Dai Clegg, created the MoSCoW method. The technique was later donated to the Dynamic Systems Development Method (DDSM). Clegg initially designed MoSCoW as a prioritization framework for time-boxed projects. Specifically, for initiatives within releases. However, MoSCoW’s uses today are more broad, as the method has been adapted by various practitioners. A detailed account of how to use MoSCoW prioritization in its original context is outlined in the DDSM handbook.

How MoSCoW Prioritization Works Before running a MoSCoW analysis, a few things need to happen. First, key stakeholders and the product team need to get aligned on objectives and prioritization factors. Then, all participants must agree on which initiatives to prioritize.

At this point, your team should also discuss how they will settle any disagreements in prioritization. If you can establish how to settle disputes before they come up, you can help prevent those disagreements from holding up progress.

Finally, you’ll also want to reach a consensus on what percentage of resources you’d like to allocate to each category.

With the groundwork complete, you may begin determining which category is most appropriate for each initiative. Let’s break down each category in the MoSCoW method further.

MoSCoW Prioritization Categories Must-have initiatives As the name suggests, this category consists of initiatives that are “musts” for your team. They represent non-negotiable needs for the project, product, or release in question. For example, if you’re releasing a healthcare application, a must-have initiative may be security functionalities that help maintain compliance.

Anything in the “must-have” category is considered mandatory for the team to complete. If you’re unsure about whether something belongs in this category, ask yourself the following.

What happens if we release without this? Is there a workaround or more simple way to accomplish this? Will the release/project/product work without this initiative? If the product won’t work without an initiative, or the release becomes useless without it, the initiative is most likely a “must-have.”

Should-have initiatives Should-have initiatives are just a step below must-haves. They are important to the product, project, or release, but they are not vital. If left out, the product or project still functions. However, if they are included, they add significant value.

“Should-have” initiatives are different from “must-have” initiatives in that they can be slated for a future release without impacting the current one. For example performance improvements, minor bug fixes, or new functionality, may be “should-have” initiatives. Without them, the product still works.

Could-have initiatives Another way of describing “could-have” initiatives is nice-to-haves. “Could-have” initiatives are not necessary to the core function of the product. Compared with “should-have” initiatives, they have much smaller impact on the outcome if they are left out.

So, initiatives that are placed in the “could-have” category are often the first to be deprioritized if a project in the “should-have” or “must-have” category ends up larger than expected.

Will not have (this time) One benefit of the MoSCoW method is that it places several initiatives in the “will-not-have” category. This helps manage expectations about what will not be included in a specific release (or other time frame you’re prioritizing for).

Placing initiatives in the “will-not-have” category is one way to help prevent scope creep. If initiatives are in this category, the team knows they are not to be a priority for this specific time frame. Some initiatives in the “will-not-have” group will get prioritized in the future, while others are not likely to happen at all. Some teams decide to differentiate between those by creating a subcategory within this group.

When to use the MoSCoW Method for Prioritization MoSCoW prioritization is an effective prioritization method for teams who would like to include representatives from the whole organization in their process. Capture a broader perspective by including participants from various functional departments.

Another reason you may want to use MoSCoW prioritization is it allows your team to determine how much effort goes into each category. Therefore, you can ensure that you’re delivering a good variety of initiatives each release.

While in its initial iteration, the MoSCoW method was intended for time-boxed projects only, it can be modified and made effective beyond the scope of simple release planning.

Source: moscow