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.
The MoSCoW technique is very simple, but such simplicity comes with some pitfalls.
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