Learning Loop Playbooks Learning Loop

Product management, User experience, Engineering

MoSCoW Prioritization

A technique used to prioritize requirements or tasks based on their importance, with the categories of Must Have, Should Have, Could Have, and Won't Have.

Also called: MoSCoW Method, MoSCoW Analysis, MoSCoW Technique, MoSCoW Matrix, MoSCoW Model, MoSCoW System, MoSCoW Technique of Prioritization, and MoSCoW System of Prioritization

See also: Affinity Mapping, Blind Voting, Card Sorting, Decider Vote, Dot Voting, Fist to Five, Five-Fingered Consensus, Heatmap Voting, Note and Vote, Parking Lot, Perfection Game, Playback, Red:Green Cards, Return on Time Invested, Roman Voting, Safety Check, Silent Storming, Stack Ranking, Straw Poll, Timeboxing, ICE Scoring Model, RICE Scoring Model, RACI Matrix, Weighted Shortest Job First (WSJF)

Relevant metrics: Completion of must-have requirements, User satisfaction, Completion of Project timeline, Return on Investment (ROI), and Re-prioritization

In this article

What is MoSCoW Prioritization

MoSCoW Prioritization is a technique used in Product Management and User Experience to prioritize requirements. It is an acronym for Must Have, Should Have, Could Have, and Won’t Have. Must Have requirements are those that are essential for the product to be successful. Should Have requirements are those that are important, but not essential. Could Have requirements are those that are desirable, but not essential. Won’t Have requirements are those that are not necessary for the product to be successful.

The letters stand for:

  • Must Have. The Minimum Usable Subset
  • Should Have. Important But Not Vital
  • Could Have. Wanted But Less Important
  • Won’t Have this time.

Where did MoSCoW Prioritization come from?

MoSCoW Prioritization is a prioritization technique used in project management. It was first developed by Dai Clegg and Richard Turner in the mid-1990s. The technique is used to prioritize requirements and tasks in a project, and is based on the idea that not all requirements are equal in importance. The categories are used to help prioritize tasks and requirements, and to ensure that the most important tasks are completed first. The technique is used in many industries, including software development, product management, and project management.

The MoSCoW rules

One of the key benefits of using the MoSCoW technique is that it provides a more nuanced approach to prioritisation than simple weighted scores. For example, simply using high, medium, or low classifications can be problematic, as it may not be clear what those categories mean or how they relate to the project’s overall goals. Likewise, using a simple sequential numbering system can create needless arguments over which tasks are more or less important.

By contrast, MoSCoW’s four categories provide a clear indication of the relative importance of each task or feature, without getting bogged down in unnecessary details. The Must Have category ensures that the most critical tasks are addressed first, while the Should Have and Could Have categories allow for flexibility in prioritisation as needed. Finally, the Won’t Have this time category allows teams to acknowledge that some features or tasks may need to be put on hold or abandoned altogether.

Must Have

In the MoSCoW technique, Must Haves represent the minimum set of requirements that the project must deliver in order to be viable. These are the non-negotiables that cannot be left out, as they are essential for the project to meet its goals. Defining Must Haves can be done by asking the question: “What happens if this requirement is not met?” If the answer is that the project would need to be cancelled or would not be able to meet its objectives, then it is a Must Have requirement.

“What happens if this requirement is not met?”

Examples of Must Have requirements include those that are legally required, those that ensure safety, and those that are critical to the functionality of the solution. Without these Must Haves, there would be no point in deploying the solution on the intended date, and the project would be rendered useless.

It’s important to note that Must Haves are not just nice-to-haves or optional requirements. They are the backbone of the project, and without them, the project cannot succeed. Therefore, it’s essential to identify and prioritize these requirements first.

Should Have

Should Have requirements are those which are important but not crucial. Their exclusion may cause some discomfort, but it does not render the solution unusable. These requirements can be achieved through some form of workaround, such as managing expectations, making do with an existing solution, or additional paperwork. The workaround may only be a temporary solution, but it allows the project to continue to function.

When assessing whether a requirement is a Should Have, one should measure the level of discomfort caused by not meeting it. This measurement can be done by analyzing the impact on business value or the number of people affected by the requirement’s absence.

Could Have

In the MoSCoW method, Could Have requirements are considered as those that are desired but less crucial than the Must Have and Should Have requirements. They are not necessary for the project to be considered complete, but they can still provide value if they are delivered.

Since Could Have requirements are less critical, they provide the main pool of contingency. This means that in the event of problems and time constraints, Could Haves are usually the first items to be dropped or pushed back to later phases. They are considered as the requirements that would only be delivered in their entirety in a best-case scenario.

To identify Could Have requirements, it’s important to prioritize them based on their level of impact if left out compared with Should Have requirements. These requirements may provide some value if delivered, but their omission does not significantly impact the viability of the project.

Won’t Have this time

Won’t have represents the requirements that will not be delivered as part of the current timeframe. Despite their negative connotation, Won’t Haves can be a powerful tool in managing the scope and expectations of a project.

By recording Won’t Haves in the backlog, the project team can avoid informally reintroducing them later on. This helps to clarify the project’s scope and prevents scope creep, which can lead to delays, cost overruns, and poor quality outcomes.

Furthermore, Won’t Haves can help to keep the focus on more important requirements. By clearly defining what won’t be delivered, the project team can prioritize their efforts and resources on the Must Haves, Should Haves, and Could Haves that are most critical to the project’s success.

Prerequisites

To get the most out of the MoSCoW technique, it’s important to approach it with a clear understanding of your project’s goals and requirements. This means taking the time to identify the most critical tasks and features, and ensuring that they are placed in the Must Have category.

It’s also important to regularly review and update your priorities, as circumstances may change over the course of the project. By using the Should Have and Could Have categories, you can make adjustments as needed while still maintaining focus on the most important tasks.

Finally, it’s important to communicate your priorities clearly to all members of your team. By using the MoSCoW categories, you can ensure that everyone understands what tasks are most critical, and what level of effort should be allocated to each task.

Adopting the MoSCoW method as a team

As development teams face a range of constraints, including budgetary limitations, team skillsets, and competing needs at the company, the method can come in handy. Depending on the context of your team, the method can help you in different ways.

Prioritizing based on budgetary constraints

When a development team is limited by a tight budget imposed by the company, using MoSCoW can help to determine which tasks are must-haves and which are should-haves. By working with product managers, the team can use MoSCoW to decide on the most important initiatives, and then use their budget as a guide to determine which tasks they can realistically complete.

Prioritizing based on the team’s skillsets

In cases where a cross-functional product team lacks the experience or expertise to complete certain tasks, the MoSCoW method can help to score those tasks accurately. If the product roadmap calls for functionality that the team cannot build, this limiting factor can be taken into account when using MoSCoW to prioritize tasks.

Prioritizing based on competing needs at the company

Cross-functional teams can sometimes find themselves competing with other company priorities, which can make it difficult to prioritize tasks effectively. In these cases, the team can use MoSCoW to determine which aspects of their desired release represent must-haves, and temporarily backlog everything else. By doing so, the team can focus on the most critical tasks while also addressing the competing needs of the company.

Measuring the success of MoSCoW prioritization

To measure whether Moscow prioritization was effective, you can use the following metrics:

  • Completion of must-have requirements. The primary objective of Moscow prioritization is to ensure that must-have requirements are completed first. Therefore, one of the most important metrics to measure the effectiveness of Moscow prioritization is whether all the must-have requirements were completed on time.
  • User satisfaction. The effectiveness of Moscow prioritization can also be measured by the satisfaction of the end-users. The must-have requirements are usually the most critical ones for the end-users. Therefore, if the end-users are satisfied with the product, it indicates that the Moscow prioritization was effective.
  • Project timeline. Another important metric to measure the effectiveness of Moscow prioritization is the project timeline. If the project is completed within the planned timeline, it suggests that the prioritization was effective. By prioritizing the must-have requirements, you can ensure that the most important tasks are completed first, which helps to keep the project on track.
  • Return on Investment (ROI). The effectiveness of Moscow prioritization can also be measured by the return on investment (ROI). If the product meets the customer’s needs and generates a good return on investment, it indicates that the prioritization was effective.
  • Re-prioritization. Finally, if the project requires re-prioritization due to changing circumstances or new information, it suggests that the initial prioritization was not effective. Therefore, if there is no need for re-prioritization, it indicates that the Moscow prioritization was effective.

Limitations of the MoSCoW Prioritization method

Despite the popularity of MoSCoW prioritization, there are potential drawbacks to consider before adopting the approach. In this section, we explore some of these limitations.

Inconsistent Scoring Process Can Result in Misplaced Tasks

One common critique of MoSCoW prioritization is the lack of an objective ranking methodology for evaluating initiatives. To overcome this, your team must implement a consistent and reliable scoring system for all initiatives, such as the weighted scoring method that measures each initiative against a set of standard cost and benefit criteria. MoSCoW helps your team group items into the appropriate buckets (Must Have, Should Have, etc.), but doesn’t prioritize items within each bucket.

Not Including All Relevant Stakeholders Can Lead to Misplaced Items

To determine which initiatives are must-haves and which are should-haves, your team needs a comprehensive understanding of the product context. Involving all stakeholders, such as the sales team, in the prioritization process can help ensure that initiatives are accurately categorized.

Team Bias Can Undermine MoSCoW’s Effectiveness

MoSCoW prioritization does not include an objective scoring mechanism, which can lead to team members prioritizing initiatives based on personal opinions. This poses a risk of mistakenly believing MoSCoW as an objective way of measuring items, resulting in biased decisions. To minimize team bias, it is crucial to establish an objective and consistent framework for ranking all initiatives.

You can address these limitations by combining MoSCoW prioritization with other prioritization techniques and continuously evaluating and refining the process.

Best Practices for Using MoSCoW Prioritization

To gain maximum benefit of the MoSCoW approach, consider these key steps.

Select an Objective Scoring System

It is important to understand that MoSCoW prioritization only helps your team group items into different categories. To determine which item belongs in which category, you will need a separate ranking methodology. There are many ranking systems to choose from, including weighted scoring, value vs. complexity, Kano model, buy-a-feature, and opportunity scoring.

Seek Input from Key Stakeholders

To ensure that you are placing each initiative into the correct category, your team needs valuable insights and context. At the beginning of the MoSCoW method, identify which stakeholders can provide the necessary information. For example, you might involve the sales team to understand how prospective buyers view a new feature, or the executive staff to understand the overall business goals.

By involving all relevant stakeholders, you can make informed decisions and identify potential opportunities or threats that your team might miss.

Share Your MoSCoW Process with Your Organization

The MoSCoW method is an excellent way to demonstrate your organization’s prioritization of initiatives for your products or projects. Sharing your team’s prioritization strategy across the organization can help you build company-wide consensus and demonstrate why you made certain decisions.

In addition, communicating your team’s prioritization process can help you set expectations and increase transparency. When stakeholders from other departments see your methodology for choosing one initiative over another, they will understand that your team has carefully considered and weighed all decisions.

By sharing your prioritization strategy, you can also encourage stakeholders to provide feedback and identify potential flaws in your methodology. If any stakeholders disagree with your decisions, they will understand that they need to provide evidence to change your course of action.

Relevant questions to ask
  • What is the purpose of using MoSCoW Prioritization?
    Hint The purpose of using MoSCoW Prioritization is to prioritize tasks based on their importance.
  • What are the criteria for prioritizing tasks?
    Hint The criteria for prioritizing tasks include Must, Should, Could, and Won't.
  • What is the timeline for completing the tasks?
  • What resources are available to complete the tasks?
  • How will the results of MoSCoW Prioritization be evaluated?
    Hint The results of MoSCoW Prioritization will be evaluated based on the completion of the tasks in the order of priority.
  • What are the risks associated with using MoSCoW Prioritization?
    Hint The risks associated with using MoSCoW Prioritization include the possibility of tasks being overlooked or not completed in the order of priority.
  • How will the results of MoSCoW Prioritization be communicated to stakeholders?

You might also be interested in reading up on:

People who talk about the topic of MoSCoW Prioritization on Twitter
Relevant books on the topic of MoSCoW Prioritization
  • Dynamic System Development Method Handbook by Benjamin J. J. Voigt (2004)
  • Mastering the Requirements Process: Getting Requirements Right by Donald G. Reifer & Suzanne Robertson (2009)
  • Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise by Dean Leffingwell (2011)
  • Scaling Software Agility: Best Practices for Large Enterprises by Dean Leffingwell (2007)
  • Software Requirements, 3rd Edition by Karl E. Wiegers (2013)
Sources

Want to learn more?

Receive a hand picked list of the best reads on building products that matter every week. Curated by Anders Toxboe. Published every Tuesday.

No spam! Unsubscribe with a single click at any time.

Community events
Product Loop

Product Loop provides an opportunity for Product professionals and their peers to exchange ideas and experiences about Product Design, Development and Management, Business Modelling, Metrics, User Experience and all the other things that get us excited.

Join our community

Made with in Copenhagen, Denmark

Want to learn more about about good product development, then browse our product playbooks.