MoSCoW Prioritization

MoSCoW Prioritization

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.

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

1. 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 a 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.”

2. 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.

3. 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.

4. 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.