The Moscow Method: A Comprehensive Guide to Prioritization in Project Management

The Moscow Method is a powerful prioritization technique used in project management, business analysis, and software development to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. It is also known as Moscow prioritization or Moscow analysis. This comprehensive guide will explain the Moscow Method, how it works, and provide examples to help you better understand the various categories and application of this technique in your projects.

Table of?Contents

• Introduction to the Moscow Method
• Background and Origins
• Prioritization of Requirements
• Moscow Prioritization Categories
• How the Moscow Technique Works in Agile Development
• Conducting a Moscow Analysis
• Understanding the Relationship Between Moscow and Business Vision
• Criticism of the Moscow Method
• Tips for Assigning Priorities
• Conclusion

Introduction to the Moscow?Method

The Moscow Method is an acronym derived from the first letter of each of the four prioritization categories:

• M — Must have
• S — Should have
• C — Could have
• W — Won’t have this time

The interstitial O s are added to make the word pronounceable. While the O s are usually in lower-case to indicate that they do not stand for anything, the all-capitals MOSCOW is also used.

This prioritization method is used to reach a common understanding with stakeholders on the importance they place on the delivery of each requirement. It helps the team to focus on the most important requirements and ensures a successful project outcome.

Background and?Origins

The Moscow prioritization method was developed by Dai Clegg in 1994 for use in rapid application development (RAD). It was later extensively used with the dynamic systems development method (DSDM) from 2002 onwards.

Moscow is often used with timeboxing, where a deadline is fixed so that the focus must be on the most important requirements. It is commonly used in agile software development approaches such as Scrum, rapid application development (RAD), and DSDM.

Prioritization of Requirements

All requirements are important; however, to deliver the greatest and most immediate business benefits early, the requirements must be prioritized. Developers will initially try to deliver all the Must have, Should have, and Could have requirements, but the Should and Could requirements will be the first to be removed if the delivery timescale looks threatened.

The plain English meaning of the prioritization categories has value in getting customers to better understand the impact of setting a priority, compared to alternatives like High, Medium, and Low.

The categories are typically understood as:

Must have

Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure. MUST can also be considered an acronym for the Minimum Usable Subset.

Should have

Requirements labeled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must have, they are often not as time-critical, or there may be another way to satisfy the requirement so that it can be held back until a future delivery timebox.

Could have

Requirements labeled as Could have are desirable but not necessary and could improve the user experience or customer satisfaction for a little development cost. These will typically be included if time and resources permit.

Won’t have (this?time)

Requirements labeled as Won’t have have been agreed upon by stakeholders as the least-critical, lowest-payback items, or not appropriate at that time. As a result, Won’t have requirements are not planned into the schedule for the next delivery timebox. Won’t have requirements are either dropped or reconsidered for inclusion in a later timebox.

Moscow Prioritization Categories

Before the Moscow analysis can begin, all participants need to agree on which initiatives will be prioritized. It’s essential to discuss how to resolve disagreements to prevent them from holding up progress during this preparation stage. This can help prevent issues from happening in the first place.

Once the framework has been established, it is time to start identifying the appropriate categories for each project. Here are the definitions and explanations of each of the Moscow prioritization categories:

Must have

Musts are defined as initiatives that are critical to the success of a project or product. These are usually non-negotiable and can be used to describe specific functionalities or solutions that need to be implemented.

The “must-have” category is challenging to define. Before you start, ask yourself if something is truly necessary in this category.

Should have

Although “should have” initiatives are not essential to a product or project, they may add significant value. A “should-have” initiative is different from a “must-have” initiative, which means it can be scheduled for a future release.

Could have

“Could haves” are initiatives that are not necessary to the core of a product. Projects that are placed in the “could have” category are often the first ones to be deprioritized when another project takes longer than expected.

Will not?have

The Moscow method places several initiatives in a “will not have” category. This method allows you to manage expectations about what will not be included in a release or another timeframe.

Putting initiatives in the “will not have” category can help prevent scope creep. This category shows the team that the project is not a priority at this specific time frame.

Some initiatives are prioritized in the “will not have” group, while others are likely to happen in the future. Some teams then decide to create a subcategory for these initiatives.

How the Moscow Technique Works in Agile Development

In agile development, particularly those following agile software development approaches, there is always more to do than there is time or funding to permit (hence the need for prioritization).

For example, should a team have too many potential epics (i.e., high-level stories) for the next release of their product, they could use the Moscow method to select which epics are Must have, which Should have, and so on; the minimum viable product (MVP) would be all those epics marked as Must have. Oftentimes, a team will find that, even after identifying their MVP, they have too much work for their expected capacity. In such cases, the team could then use the Moscow method to select which features (or stories if that is the subset of epics in their organization) are Must have, Should have, and so on; the minimum marketable features (MMF) would be all those marked as Must have. If there is sufficient capacity after selecting the MVP or MMF, the team could then plan to include Should have and even Could have items too.

Conducting a Moscow?Analysis

In this section, we will look at how to perform a Moscow analysis, including writing Moscow requirements and assigning priorities to each requirement.

1. Lay out your product requirements

Although Moscow prioritization should be used early in the product management cycle, it shouldn’t be your first step. You need to have product requirements laid out before you can start organizing those requirements by priority. So the sooner your team can lay these priorities out, the better.

This step, as with all steps of Moscow prioritization, should be completed collaboratively by both the product team and stakeholders.

2. Define your prioritization levels

As mentioned, the Moscow model consists of four components: must-have, should-have, could-have, and won’t-have this time. Though the title of each category makes its purpose pretty clear, it’s important to have each tier clearly defined.

3. Organize your requirements into priority?levels

Once you have your requirements laid out and your priority levels clearly defined, it’s time to sort the requirements into priority levels.

The “Must-have” requirements should be straightforward to identify as these are the aspects your project cannot function without. For the other tiers though, it might be useful to consider some other factors when determining which requirements fall into which category:

• Time constraints
• Team skillset
• Budgetary constraints
• Team workload
• Cross-team collaboration

4. Refine and?optimize

At this point, your team should be done with the initial phase of categorizing all of the project’s requirements by priority. However, this doesn’t mark the end of the Moscow process. Each time a milestone is completed, the remaining milestones should be (briefly) reevaluated.

Understanding the Relationship Between Moscow and Business?Vision

The starting point for all projects is the business vision, which is associated with a set of prioritized requirements that contribute to the delivery of the vision. The Moscow priorities are necessary to understand the Minimum Usable Subset and the importance of individual requirements. The Business Visionary must ensure that the requirements are prioritized, evaluated in business terms, and delivered to provide the ROI required by the Business Case, in line with the business vision.

Criticism of the Moscow?Method

Despite its effectiveness, the Moscow method has faced some criticism:

• It does not help in deciding between multiple requirements within the same priority.
• There is a lack of rationale around how to rank competing requirements: why something is must rather than should.
• Ambiguity over timing, especially on the Won’t have category: whether it is not in this release or not ever.
• Potential for political focus on building new features over technical improvements (such as refactoring).

Tips for Assigning Priorities

• Ensure that the business roles, particularly the Business Visionary and the Business Analyst, are fully up to speed with why and how Moscow prioritizes requirements.
• Consider starting with all requirements as Won’t Haves and then justify why they need to be given a higher priority.
• For each requirement that is proposed as a Must Have, ask: ‘what happens if this requirement is not met?’ If the answer is ‘cancel the project; there is no point in implementing a solution that does not meet this requirement’, then it is a Must Have requirement. If not, then decide whether it is Should Have or a Could Have.
• Ask: ‘if I come to you the night before Deployment and tell you there is a problem with a Must Have requirement and that we can’t deliver it — will you stop the Deployment?’ If the answer is ‘yes’, then this is a Must Have requirement. If not, decide whether it is Should Have or a Could Have.
• Is there a workaround, even if it is a manual one? If a workaround exists, then it is not a Must Have requirement. When determining whether this is a Should Have or a Could Have requirement, compare the cost of the workaround with the cost of delivering the requirement, including the cost of any associated delays and any additional cost to implement it later, rather than now.
• Ask why the requirement is needed — for this project and this Project Increment.
• Is this requirement dependent on any others being fulfilled? A Must Have cannot depend on the delivery of anything other than a Must Have because of the risk of a Should Have or Could Have not being delivered.
• Can this requirement be decomposed? Is it necessary to deliver each of these elements to fulfill the requirement? Are the decomposed elements of the same priority as each other?

Conclusion

The Moscow Method is a powerful prioritization technique that can help project managers and teams successfully deliver projects on time and within budget. By understanding the importance of each requirement and assigning priorities accordingly, teams can focus on what truly matters and ensure a successful project outcome. While the method has faced some criticism, its effectiveness in agile development and its ability to manage stakeholder expectations make it an indispensable tool for project management.