Prioritisation techniques in detail: MoSCoW and the Value/Risk Prioritisation Matrix

Let’s discuss these techniques in more detail.

MoSCoW

MoSCoW is one of the most basic and commonly used prioritisation frameworks. It is quick, effective and easy to use. You organise your ideas or features into 4 categories:

• Must: tasks that are important and urgent, relating to things that are vital to the success of your product
• Should: important tasks that are not as essential or urgent as the tasks in the ‘must’ category
• Could: tasks related to desirable features that you may be able to address in future, but that are not currently important or urgent
• Would not or Will not: tasks or features that you will probably never get to complete. This could be due to time constraints, cost, or practicality, or simply because the features in this category are unnecessary.

The first letters of these words (M, S, C and W) give the framework its name, MoSCoW, not the capital city of Russia – this is just a fun (if potentially confusing) coincidence!

Advantages

MoSCoW is a popular method because it is easy to use and directs the team towards building the MVP, as the features in the ‘must’ category are the essentials that the product needs to work. MoSCoW also helps product managers to create roadmaps, as the categories can easily be mapped onto a Now, Next, Later or other roadmap format.

The simplicity of MoSCoW also helps teams communicate with non-technical stakeholders, such as senior management.

Disadvantages

Using MoSCoW can sometimes lead to confusion as there is no way to prioritise tasks within the categories. For example, there might be 3 essential tasks in the ‘must’ category that are all of equal importance – how do you decide which to do first? There is also no real way of judging time and how long these tasks will take.

It can also sometimes be difficult to explain the criteria for the categories themselves. For example, there may be conflicting opinions within the team or organisation as to what is an essential feature that needs to be in the ‘must’ category and what is important but not essential and therefore belongs in ‘should’.

Prioritisation Matrix

A prioritisation matrix is a more structured approach than MoSCoW, but it is still simple and easy to use. There are many different types – we will use the value/risk matrix as an example.

Value/Risk Matrix

A value/risk matrix helps you to measure the perceived value of a feature or idea against the potential risk to your team. ‘Risk’ here refers to things like the time the task will take to complete, the potential cost or the ability of your team to successfully execute the task.

Matrix from Hygger.

There are different ways to use a value-risk matrix. It is up to you to decide whether risks should be taken or avoided. In this example, the high-value, high-risk tasks are being prioritised in the ‘do first’ category and the high-value, low-risk tasks are in the ‘do second’ category. High-value, high-risk features can be developed first as they deliver the most value and completing them eliminates significant risks. In other cases, it might be better to prioritise the high-value, low-risk tasks, so that you can complete them successfully, perhaps to show early results to key stakeholders. Low-risk also means that there is a minimal chance of wasting time, effort or money while completing these tasks. If you decide to avoid risky items and focus on value, you may be able to develop a large part of your product before you encounter any major problems or roadblocks – but this could mean doing a lot of work and then encountering something that may derail the whole project. On the other hand, if you focus on high-risk items first to get them out of the way, you may end up doing a significant amount of work on features that end up being less valuable. The other two categories are more static. Low-value, low-risk tasks will need to be done eventually, but they are not priorities – the features that generate value should be prioritised. Low value, high-risk tasks should probably always be avoided. It is very unlikely that the risk is worth taking, and you might end up wasting time and losing money that could have been dedicated to higher value tasks.

Advantages

A value/risk matrix is a simple way of evaluating tasks that is easily understood by team members and stakeholders. As with MoSCoW, it clearly divides tasks so that the team can understand their priorities and focus on delivering value.

The matrix format is very flexible. You can use a prioritisation matrix to evaluate many different variables, such as impact, effort, cost, time, fit with goals, urgency, and more. For example, an impact/effort matrix would measure the impact or value of a proposed feature against the effort (time, resources, energy) it would take to build.

Disadvantages

Similarly to MoSCoW, there is no way to prioritise within the categories – if multiple features are judged as ‘high priority’, how do you decide which to do first? For this reason, a value-risk matrix may be less useful when there are lots of features being proposed.

Judgements of value may also be incorrect and tasks that were initially deemed low risk can end up taking more time and effort than anticipated. To avoid these possibilities becoming bigger problems for the team, product managers should be continually reassessing their prioritisation to respond to any change in circumstance.