The MoSCoW method for prioritization

The MoSCoW method is a highly widespread prioritization method which was popularized by Dynamic Systems Development Method (DSDM). The term MoSCoW has nothing to do with the capital of Russia. It is an acronym derived from the first letter of each of four prioritization categories – Must have, Should have, Could have and Won’t have.[1] The two “O” are added to make the word pronounceable.

Must have: This category contains requirements or features that are absolutely mandatory. Those are fundamental to the system (being a product or a service). If any of them are neglected, the system will certainly not work or will have no value for the customer.

Should have: These features are important, ideally, we should have them for the system to work correctly. If they are not there, a workaround may be possible, but it can be costly or cumbersome. Yet, they are not mandatory and therefore do not have the highest priority. Simply put, they don’t have much impact on delivery success right now, though they must be implemented soon enough (after the “must-haves”).

Could have: These are useful additions (often small-scale improvements) that add tangible value. These are “nice-to-have” requests. In general, they do not take considerable resources, but they are not essential to implement either. Their absence won’t affect almost anything, or at least wouldn’t impact the release negatively.

Won’t have (sometimes also known as “would like to have, but not this time”): These items are not worth the investment (of time, money, energy) and are unlikely to make the cut (at least not in the near future). These requirements are of the lowest importance and can be easily omitted (definitely considered out of scope for the first release) or rescheduled for future releases.

When prioritizing requirements in a project, DSDM recommends no more than 60% effort for “must-haves” requirements and a sensible pool of “could-haves”, usually around 20% effort (see Figure 1, Balancing priorities using the MoSCoW prioritization technique, below). Anything that is higher than 60% effort for the “must-haves” poses a risk to the success and predictability of the project, unless the environment and the used technology are well understood, there are minimal external risks/dependencies and the team is experienced and well established. Note that we are talking about a balance based on estimated effort of requirements (i.e. the expected time it takes to implement the prioritized features) and not total number of requirements. When calculating effort for a specific timeframe (e.g. first release), “won’t haves” are excluded, as they are considered out of scope for this timeframe.[2]

Figure 1: Balancing priorities using the MoSCoW prioritization technique (recommendation by DSDM[2])

Let’s take a simple practical example. How can you categorize the features required to manufacture a child’s bicycle?

Must have: two wheels ; a frame

Should have: brakes for safe stopping; pedals; ability to adjust the saddle to accommodate growth; safety cover for the chain; stabilizers or the ability to fit them when needed (the last two features can also be classified as “could-haves” depending how essential they are for the child/parents)

Could have: bell or horn to alert others in proximity; attractive color of the bike; front suspension; Presta valves for inflating tires

Won’t have: valve caps to cover the tires valve; Bluetooth bike speaker

Even though it may seem strange not to have the pedals and the brakes in the “must have” category, in reality they are not mandatory for a child’s bike. By definition a bike is two-wheeled transportation device, so it must certainly have two wheels and a frame to link the wheels together, but everything else is subject to discussion and negotiation. For example, small kids can learn to ride a bike by simply using their feet, so no pedals and brakes are really needed. This simple example also shows that there is often a disconnect between expectations and requirements. People often have high level of expectations, but high expectations are different from must-have requirements which are mandatory and non-negotiable.

Let’s now look at the advantages and disadvantages of the MoSCoW method.

• Simplicity. The MoSCoW method is one of the simplest prioritization techniques. It does not require searching for detailed data or making complicated calculations. So, it is easy to master and use because it is based on simple principles. Using this prioritization scheme in a product management context promotes mutual understanding between product people (product managers and product owners) and stakeholders. It is also a great method to resolve conflicts and to bring stakeholders to consensus. Prioritizing work using MoSCoW is fast and transparent.
• Agility for flexible scheduling and implementation. Since this prioritization method has no strict time limits for the implementation, except for the “must-have” category (items there should always go first and be implemented as soon as possible), it allows for flexible implementation timeframes per feature. Therefore, a team can easily adjust feature deliveries or releases on favorable terms based on agreement with customers/stakeholders.

The MoSCoW technique is very simple, but such simplicity comes with some pitfalls.

• The technique lacks a clear consistency of implementation and lacks specific planning per feature. Even though priorities can be easily and quickly set, the MoSCoW method prioritizes the backlog items in four categories (in a similar fashion to the Kano model, covered in my previous article, which also prioritizes features in different categories), so it does not introduce any sequencing of features/backlog items and lacks specific planning. This makes it quite challenging for product people to decide on the exact priority of a feature compared to another one within the same category. At the end of the day, this drawback might put the entire release at risk.
• MoSCoW classification rules can be subjective and this creates imbalance between the absolutely required (must have or mandatory) and slightly desirable. Often, the blurred lines between categories make it hard to decide in which category a feature should go into, specifically when we talk about “must-have” and “should-have” lists. But it is sometimes also the case between “should-haves” and could-haves”. This happens due to the subjectivity of requirements. Therefore, features or stories allocated to the different categories should be approached with great thought and care and the chosen categorization should be agreed with (or well explained to) all stakeholders.

The MoSCoW method is probably the simplest and most widespread prioritization scheme for new product development, and more specifically for small products. But as we saw above, this technique also has its disadvantages and is not always effective. For instance, if you have a complicated backlog with many time-sensitive releases, consider choosing other prioritization method or complementing MoSCoW with another more accurate or comprehensive technique.

On the other hand, it is quite reasonable to use MoSCoW when prioritizing work for small (and not too complex) products, which does not have many technical limitations. The MoSCoW requirements help product people and teams take a strategic, orderly approach to prioritization. This method is great for avoiding wasted time, arguments and misdirection.

In my next article I will talk about the Eisenhower matrix. Meanwhile, if you want to know more about prioritizing using the MoSCoW method, please feel free to contact me.

[1] Griffiths, M. (2012). PMI-ACP Exam Prep (2nd ed.). RMC Publications Inc.

[2] Agile Business Consoritum (n.d.). Chapter 10: MoSCoW Prioritisation. Retrieved from agilebusiness.org