What is MoSCoW Prioritization?

MoSCoW prioritization, also known as the MoSCoW method or MoSCoW analysis, is a popular technique for determining the importance of tasks. The method is used to understand the significance of tasks within a specific software release. At Squares, we use this method during sprint planning and cost estimation, often alongside a Kanban board.

The acronym MoSCoW stands for four different categories of initiatives: Must Have, Should Have, Could Have, and Won’t Have.

M – Must Have

As the name suggests, this category consists of initiatives that are “mandatory” for your team. They represent the non-negotiable needs of the project, product, or release. For example, if you’re launching a healthcare app, a necessary initiative might be security features that ensure compliance.

Everything in the “must have” category is considered essential for the team. If you’re unsure whether something belongs in this category, ask yourself the following questions:

• What will happen if we release without it?
• Is there a workaround or simpler way to achieve this?
• Will the release/project/product work without this initiative?
• If the product won’t function without the initiative or the release becomes useless without it, the initiative is most likely a “must have.”

S – Should be

“Should be” initiatives are just a step below “must have” ones. They are important for the product, project, or release, but they are not essential. If omitted, the product or project will still function. However, if included, they provide significant added value.

“Should be” initiatives differ from “must have” initiatives because they can be planned for a future release of the application without impacting the current one. For example, performance improvements, minor bug fixes, or new features could be “should have” initiatives. Without them, the product still works.

C – Could be

“Could be” are requirements that are neither critical nor very important. They are often seen as nice-to-have features that would be great if they appeared, for example, in the situation of extra hours available or functionality that could be implemented ‘on the side.’ However, if they are not included, they will not have a significant impact on the project.

W – Won’t be

“Won’t be” refers to initiatives that we do not want to implement in the upcoming release but may be considered for implementation in the unspecified future.

Źródła: