What is a MoSCoW Analysis? Definition, Use Guide, and Analysis

Table of Contents

Prioritization and organization are two essential elements in creating a successful project and are also things that are inherently harder to achieve online. While prioritizing elements can be hard online, it doesn’t have to be. The Moscow analysis is a great tool for teams to collaborate on through online whiteboards and has takeaways that are applicable to a variety of different projects and teams.

In this article, we will define the Moscow analysis and talk about what makes it so helpful to teams everywhere. If you are interested in reading some of our other template guides, you can check out our most recent guides on design thinking and using a business model canvas here.

What is a Moscow Analysis?

A Moscow analysis, also known as Moscow prioritization, is defined as an organizational framework that helps clarify and prioritize features or requirements for a given project. By creating boundaries for the priorities, teams are able to narrow their focus and create direct and achievable goals.

Moscow is an acronym that stands for the four categories that various features can be sorted into. These categories are: Must have, Should have, Could have, and Won’t have These four categories determine the prioritization of the corresponding features and are a marker of their importance to the overall success and continuity of the project.

• Must-haves: These are the essential requirements that must be included in the project or product. If any of these requirements are not met, the project or product cannot be considered successful.

• Should-haves: These are important requirements that should be included if possible. They are not absolutely critical but add significant value to the project or product.

• Could-haves: These are requirements that are nice to have, but they are not critical. They can be considered if time and resources allow but can be deferred if necessary.

• Won’t-haves: These are requirements that are explicitly out of scope for the current project or product. These requirements are not currently under consideration.

While the Moscow analysis is most often used to organize a project and its required elements, it can also be used in other scenarios. For example, Moscow prioritization can be applied to better align a team with its values and expectations. It can also be used to prioritize takeaways and next steps from an important meeting. Its main goal is the help visualize the prioritization of the tasks at hand.

These use cases demonstrate the flexibility of the Moscow prioritization to break down important requirements into simple prioritized areas, whether it be for team expectations or a project sprint.

Moscow Analysis Use Guide

As previously stated, the Moscow analysis consists of four major elements. These categories are explained below alongside some questions to guide what should be included in each category. For the sake of simplicity, we will use a project prioritization for reference.

Must Have

This section is where you think about the core features that are necessary to the success of the project. Must have features are things that, if absent, would compromise the project as a whole. Without these features, the project would have an entirely different function and wouldn’t serve the intended purpose.

Must have features, while being the most important things to consider, should not account for every detail that will be present in the final version. The features in must have, should have, and could have should all be major considerations to be included in the project, so try and be very specific with the features you add in each section.

Some prompting questions to ask in this section could be:

• What features are absolutely essential and cannot be replaced?
• If removed, would the project achieve the same purpose?
• Will the delivery of the project be a success without this feature?

Should Have

Should have is where the project begins to become more nuanced in its prioritization. Should have features include those that are supplemental to the must have features, things customers have vocalized interest in, and other features that would make meaningful additions to the project.

Should have features should be thought of as just a step below must have. These features, while important, could be pushed to a later release while the must have features are absolutely essential. Without these things, the project will still work, but it will be better with them.

Some prompting questions to ask in this section could be;

• How does this feature compare to the must have features? What about the could have features?
• What is a helpful but not required feature?
• How would the project function if this feature is omitted?

Could Have

Could have features are often misunderstood and get lumped with random possible additions. This section is meant to highlight features that you want to include but aren’t sure if they will be possible.

Could have features are even a step lower on the prioritization of should have features due to either time or substantive restraints. These are features that would be nice additions, but might not directly impact the core function of the product.

Some prompting questions to ask in this section could be:

• What would be a useful tool to add that isn’t a priority?
• What is something that you’d like to add in the future?
• How would this feature impact the overall product?

Won’t Have

Won’t have is one of the most important sections in the analysis. It defines all of the features and points that specifically will not be included in the project release. This section is critical because it narrows the scope of the project greatly and helps define the boundaries that must be followed to achieve a successful project.

In order to have a helpful won’t have section, you need to plan not only the project you’re working on but future projects and parallel endeavors as well. By thinking about what comes in the future and what exists outside of the current release, you are able to narrow the scope of the current project.

Some prompting questions to ask in this section could be:

• What features will be purposefully left out of this project?
• What is being avoided or postponed for a future release?
• What features fall outside of this releases specific scope?

Learn more: SWOT Analysis Framework

How To Do A Moscow Analysis

MOSCOW analysis helps teams make informed decisions about what to prioritize and what can be deferred or excluded, leading to more effective project or product development. Here’s how to perform a MOSCOW analysis:

• Identify Stakeholders: Gather the key stakeholders and decision-makers involved in the project or product development. It’s essential to have a clear understanding of their needs and expectations.

• List Requirements or Features: Make a comprehensive list of all the potential requirements or features that have been proposed for the project or product. This list can come from user stories, feature requests, or other sources.

• Categorize Requirements: For each requirement or feature, categorize it into one of the four MOSCOW categories (Must-have, Should-have, Could-have, or Won’t-have). You can do this collaboratively with the stakeholders, using their input to make informed decisions.

• Prioritize Must-Haves: Focus on the “Must-have” category and ensure that these requirements are prioritized above all else. These are the non-negotiable elements of the project.

• Prioritize Should-Haves: Once the Must-haves are defined, move on to the “Should-have” category and prioritize these based on their relative importance and impact on the project or product.

• Consider Could-Haves: Evaluate the “Could-have” category and decide which of these features or requirements are feasible to include, given the available resources and time.

• Exclude Won’t-Haves: Ensure that the “Won’t-have” category is clearly communicated and understood. These are the features or requirements that will not be addressed in the current project or product.

• Document the Analysis: Record the results of the MOSCOW analysis in a document or spreadsheet so that all stakeholders have a clear understanding of the prioritization decisions.

• Review and Iterate: Periodically review and update the MOSCOW analysis as the project or product evolves. Changes in scope or stakeholder priorities may necessitate adjustments.

Learn more: What is PESTEL Analysis?

Conclusion

Using a Moscow analysis is one of the best ways to improve the alignment of a team and understand the prioritization of the project at hand. While these templates are mainly used for product management, they are extremely versatile and can be applied to many different scenarios.

Hopefully, this guide has been helpful, and if so make sure to check out our other posts around online whiteboards and visual collaboration if you want to learn more about how to interact and collaborate online.