MoSCoW Prioritization

What is MoSCoW prioritization?

MoSCoW is an acronym defining four prioritization categories: Must-have, Should-have, Could-have, and Won't-have. The o’s are only included to help with pronunciation.

MoSCoW prioritization solves one of the main problems of less robust prioritization tools by laying out specific definitions for each level of priority.

When something is in the "must-have" level of MoSCoW, for example, it's immediately clear to everyone on the team that this feature cannot be overlooked during the project's development. 

In this guide, we’ll look at how product teams can prioritize using the MoSCoW framework, how to do a MoSCoW analysis, and how to write MoSCow requirements. Let’s get into it.

Origins of the MoSCoW framework

In 1994 Dai Clegg was consulting on software development at Oracle. Teams were using RAD (Rapid Application Development) but had limited time, which prompted Dai Clegg to develop the MoSCoW rule to help prioritize development tasks during product releases.

The MoSCoW rule became popular in the agile project delivery framework DSDM (Dynamic Systems Development Method) in the early 2000s. DSDM attempts to improve RAD development.

One strategy is fixing the cost, quality, and time requirements at the start of the project. MoSCoW fits the bill.

As agile has grown in popularity, the value of MoSCoW rules for decision-making has become apparent. MoSCoW is now a widely used method of prioritizing within the agile framework.

eBook

Mastering Prioritization

Read now

How does MoSCoW work in agile?

The MoSCoW method plays a significant role in agile development. The technique is built on the agile model of project management.

Agile development's focused, iterative nature forces teams to ruthlessly refine the requirements down to only what’s necessary for a particular iteration. MoSCoW dovetails with this process nicely. 

For example, a Minimum Viable Product (MVP) is made up of only requirements that are “Must-haves.”

In agile development, the requirements need to be reassessed after each iteration and when new user stories arise.

Unlike DSDM, agile development’s focus on changing user requirements and constant course corrections makes the MoSCoW rule a regular exercise rather than a one-off task done and set in stone.

Each of the agile project elements can be prioritized into must, should, could, and won’t-haves to allow teams to rapidly deploy solutions, efficiently use resources, and integrate these new or changing requirements.

In an agile development environment, the MoSCoW definition of “Won’t haves” can be thought of as “Won’t have for now,” acknowledging that current iterations focus on a subset of requirements and future iterations will include more features.

MoSCoW also helps when agile development forces teams to focus on the highest priorities by limiting time and resources using tools like Scrum or Timeboxing, forcing activities into a fixed timeframe.

Other agile techniques that include users in the design process are restricted by the time users can afford to aid in development. MoSCoW can help prioritize the users’ time and efforts on the key features.

How do you do a MoSCoW prioritization?

Now you know a bit more about what MoSCoW prioritization is, let’s look at how to put it into practice: what are the rules for MoSCoW prioritization, and how do you perform a MoSCoW analysis? Here are the steps and best practices for conducting your own MoSCoW prioritization.

Download now: Get our 5-minute guide on how to use the MoSCoW Prioritization Technique

First, we start with writing the MoSCoW requirements.

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-haves, should-haves, could-haves, and won't-haves. Though the title of each category makes its purpose pretty clear, it’s important to have each tier clearly defined. 

So how do you write each of these MoSCoW requirements and decide which tasks belong in which tier?

Must-have

These product features should be the easiest to determine. If you were designing a car, these would be tires, the engine, and fuel. If you're creating a budgeting service, then you might consider the ability to integrate with a user's bank account a must-have component. 

In other words, these are the minimum requirements for your project — they are non-negotiable. If you find yourself having a hard time determining which features to place in this category, simply ask yourself, "Will the project fail if this feature/milestone/component isn't met?" If the answer is "yes", then this is a must-have component. 

Should-have

Your project's should-haves are the features that are not essential to the project's success but will add substantial value nonetheless. These features are more focused on fulfilling customers' wishes and expectations, rather than meeting their basic needs. 

Returning to our car example, a should-have component would be the air conditioning system. This isn't required to make the car run, but a car without an air conditioner would be a tough sell. Like must-haves, you want to try and meet all of your should-have milestones by the end of the project. 

Could-have

This is the catch-all category for features that are neat, interesting, or fun, but that doesn't necessarily serve any greater purpose. These are the comfort items — the bonuses — of your product. You may notice that this area is where the most shifting happens during the project, with features moving from this category into won't-haves and should-haves. 

To determine if a feature is a could-have or a should-have, consider how it will impact the value of your product to customers. In most parts of the world, a car without air conditioning will be nearly impossible to sell as a "good" car. However, a car without a parking camera, though a handy feature, is unlikely to dramatically reduce the perceived value of the car. So, in this category, you'll put features that would sweeten the deal, but not make or break your product’s success.

Won't-have

Finally, we have the won't-haves. This category is likely to fill up with ideas as you get further along in the project development cycle. Essentially, this is where you put the features you would like to include in your product, but for some reason can't.

You either don't have the tech, talent, resources, or confidence to try and implement a certain component into your product. Instead of throwing this idea in some notebook and forgetting about it, you can place it here, where you can revisit it later. You may find that some of your could-haves and maybe even some should-haves are won't-haves due to unexpected limitations. 

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

Not only should features and ideas be placed in each level of the MoSCoW model, but a clear amount of allocated resources should also be agreed upon for each level. 

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. 

For example, you may have requirement X that falls under the could-have category during your initial MoSCoW meeting. Once you complete a few must-haves, however, you may look at requirement X differently, deciding that you do need to implement it more urgently, or that it doesn’t add any value at all. 

An element of flex is good during development, though you shouldn't change your MoSCoW model so dramatically that it becomes useless. The secret lies in finding a sweet spot between iterative assessment and a structured way of working.

eBook

Mastering Prioritization

Read now

Why MoSCoW prioritization is important

There are several reasons why the MoSCoW method is useful for creating a solid product. First, it helps you create a timeline for your product by determining what needs to be completed first. Everyone knows what the most important features are, giving the whole project a sense of clarity. 

Second, the MoSCoW approach is excellent for setting expectations, both for the team and the stakeholders. It gives investors a good idea of what they can expect from the product and a clear idea of what each feature will cost. 

Third, implementing MoSCoW into your workflow helps keep the vision for the product on track. When brainstorming with colleagues, stoking your creativity, and trying to push the boundaries, it's natural for your team to step outside of the product's requirements and limits. 

While this is good for the drawing board, it's not so good when you're actively developing the product. MoSCoW provides everyone with a clear checklist of what they need to accomplish. as opposed to a vague and multi-faceted vision.

Does MoSCoW prioritization work?

The short answer? Of course, it does! Take it from the prioritization experts, MoSCoW is as effective as it is simple to perform. 

When used correctly, MoSCoW prioritization can help teams better understand the work ahead. It offers an easy but powerful way to contextualize the value of a task or feature so you can make an informed decision about its inclusion. 

MoSCoW prioritization is so effective because it’s incredibly simple to use. It’s less vague than numerical prioritization methods, meaning even newcomers to prioritization can get involved. And the more people you can include, the better your project will go because every person brings their unique insight, helping your team make better decisions. 

Criticism of the MoSCoW framework

As much as the airfocus team loves the MoSCoW framework, not everyone feels the same way. 

Some managers find MoSCow a little too ambiguous. In particular, the “won’t have” category fails to establish if elements that fall into it will actually be used. This has a knock-on effect when performing MoSCoW prioritization, as managers are eager to ensure their requirements don’t fall into that category. This can delay business-critical functionality and distracts from the focus of adding value for real users. 

Managers may also mistreat this prioritization method as a way to secure extra budget or resources. Rather than truly prioritizing items, they’ll insist that items in the “should,” “could,” and “would” columns are going to be delivered and use the extra resources as a buffer in case they overspend on the “must-haves.” This tends to backfire when higher-ups expect features that haven’t been developed and insist they be delivered. 

The MoSCoW method can leave you high and dry when prioritizing categories. Sure, you have an idea of what items should be pursued, but there needs to be further prioritization of each category to ensure you build the product correctly.

MoSCoW also requires a lot of discussion around each item to ensure enough context is given to the prioritization decision. This requires getting together with the right people, including stakeholders, and spending plenty of time contextualizing items.

However, despite these pitfalls, MoSCoW is still an excellent prioritization tool, and it doesn’t hurt to try it out!  

Tips for prioritization using the MoSCoW framework

The MoSCoW framework is fairly simple to use, making it a great tool for teams of any level. Here are some top tips to ensure your MoSCoW prioritization is even more effective. 

• Make sure all key members of the team are present, including stakeholders

• Try to find a separate time to address any concerns or conflicts

• Set deadlines for the tasks you decide on to ensure they are completed

• Make sure to list every task

• Allocate resources to each task before MoSCoW prioritization 

• Establish ways to avoid HiPPO (Highest paid person opinion)

• Keep the customer in mind throughout the process

• Set strict requirements for each category