MoSCoW Method

Not all of your product backlog entries will have the same urgency and priority levels. You might need some for the coming milestone or launch, while you can push back others for a different time frame. Managing the prioritization of these tasks is key to handling a limited time and resource pool. 

One of the most popular prioritization frameworks is the MoSCoW method, and it can help you quickly determine the relative value and urgency of each task.

In this glossary article, we define the MoSCoW Method, its parts, and how to use it, as well as take a look at its strengths and weaknesses as a framework.

What is the MoSCoW Method?

The MoSCoW Method is a prioritization framework that groups product tasks and initiatives according to how relevant and urgent they are, considering the current sprint or milestone. Dai Clegg, a software development specialist at Oracle, first developed it in 1994.

Clegg meant for MoSCoW to be used in timeboxed projects. These are projects of fixed length with set deliverables and deadlines. The MoSCoW agile method would then go on to be used as part of the DSDM agile framework starting in 2002.

The MoSCoW Method prioritizes features that significantly and immediately contribute to your business goals. If resources are limited, push the lowest-priority features can back and reschedule in favor of higher-priority goals.

MoSCoW is an acronym that stands for the four priority categories that the method uses: “Must-Have,” “Should-Have,” “Could-Have” and “Won’t-Have”. It’s also known as MoSCoW analysis or MoSCoW prioritization. 

MoSCoW Method Categories

The four MoSCoW categories prioritize requirements based on two criteria: 

1. How important they are to the product’s immediate goals
2. How time-sensitive they are

Must-have

Must-have requirements are absolutely critical to the current release or milestone. If a single must-have requirement is missed, then the project is considered incomplete. Essentially, any item that you categorize as “must-have” is a non-negotiable part of the current sprint or release. 

For example, a video streaming product service will include the actual video playback feature as a must-have requirement. If it doesn’t include this feature, the product is functionally useless to its users.

Should-have

Should-have requirements are also very important and add plenty of value to the project. However, they aren’t essential to the product’s functionality, nor do you have to urgently complete them in the current timeframe.

Because of this, you can choose to leave them out of the current release, if you need to prioritize must-have features instead, or if you have limited resources. Then you can reschedule your should-have features for a future release.

In the above example of a video streaming product, a feature that lets users resume playback at the same point across all their devices would be a should-have. It’s a highly competitive feature that virtually all streaming services have. However, it won’t break the service if you leave it out of your initial V1 launch.

Could-have

Could-have requirements are non-essential parts of the product that would have a much smaller impact if you didn’t include them in a release. You can reschedule them if should-have or must-have initiatives need more time and resources to finish.

One example of a could-have feature in the hypothetical streaming example is the ability to set playback speed. Some users enjoy the option to watch movies or TV series at a higher speed, like 1.5x or 2x normal playback speed. However, few services have this feature, and most people wouldn’t mind too terribly if it was missing. 

Won’t-have 

Won’t-have requirements are the ones that you’ve decided are out of scope for the current sprint or release. Including a feature in the won’t-have list means that you’re explicitly writing it off as a task that your team is not going to work on at this time.

It’s important to note that won’t-have features will not stay in this priority level forever. Indeed, they may eventually become should-haves or even must-haves in future development milestones. This is why the won’t-have category is also sometimes known as “won’t-have this time.”

Advantages and Disadvantages of the MoSCoW Method

Before you decide to use the MoSCoW agile method for your product, it’s important to know where it provides the greatest benefits, and what its weaknesses are.

Let’s take a look at some of its pros and cons:

Advantages

More Detailed Rationale

The MoSCoW method is a great replacement for any simple prioritization method that looks at each task as high, medium, or low priority. Such generic prioritization schemes don’t actually give any good reasoning behind why you’ve assigned a particular priority level to a feature. You’d have to describe each point in detail if you’re explaining it to a stakeholder. 

Simple Prioritization Categories

On top of this, having too many priority levels can make it difficult to determine where a feature fits. With MoSCoW, there are clearly defined reasons why each item belongs in each category.

Clear Priority Order

Another advantage is that the MoSCoW method creates a clear order of priority. This means that product teams always know which items to deprioritize first to make way for top-priority items. This clarity also helps build a consensus among stakeholders as to what really is important to the next milestone. 

By having to look at each backlog item in the context of MoSCoW, you get a better idea of the urgency and relevance of each task.

Disadvantages

Everything Can Seem Important

MoSCoW is by no means a perfect prioritization framework. One significant weakness is that oftentimes, the majority of requirements will be treated as must-haves. This can miss the point of prioritization, which is to put focus on securing big and urgent wins with limited resources on hand. 

One tip to resolve the above is to work backward: Start by setting every requirement as a won’t-have, and ask stakeholders to justify why their priority level should be elevated. Key questions include:

• What will happen to the product if we don’t fulfil this requirement?
• Will the product work without this feature?

If the project will fail or be functionally useless to its users without the feature, then it’s a must-have. Otherwise, further discussion will reveal whether it’s a should-have, could-have, or won’t-have.

Competing Product Backlogs

Another disadvantage is that the MoSCoW method may not help prioritize the backlogs of products that are competing against other products with multiple, similarly important features. Another type of prioritization framework, like the Kano model, which considers each feature on the basis of maximum customer satisfaction, might be better for this scenario.

The MoSCoW Method: Making the Most of Your Time

The MoSCoW Method allows you to clearly identify what your team should be working on right now, and what can be rescheduled for later development. This makes it a powerful tool for projects with limited time and development resources.