MoSCoW prioritization method

Introduction

The MoSCoW technique is a very powerful agile prioritization tool that helps you deliver what really matters first, but at the same time protecting quality.

If you want to understand how it really works and how to identify the ‘eureka’ moment when everyone gets it, then view the videos below. They are a few years old now, but everything talked about in the webinars still applies today.

Videos: MoSCoW prioritization

In the first video, Keith Richards, the Founder of agileKRC and Lead Author and Chief Examiner for Agile Project Management (AgilePM) and DSDM Atern, and Lead Author of PRINCE2 Agile explains the basics of MoSCoW prioritization, its relationship to the 80:20 rule, the 60:20:20 ‘rule of thumb’, and advanced prioritization.

Download PDF

In the second video, Keith discusses why you need to prioritize and why you should use MoSCoW.

In the third video, Keith discusses the MoSCoW method in the context of the granularity of requirements, and uses the analogy of boulders, rocks, and gravel for high, medium, and low level requirements.

Unanswered questions

At the end of the video recording there were quite a few questions asked by attendees that I didn’t get the chance to answer in the webinar. So, we have included the questions and answers here.

Q1/ The 60:20:20 rule is nice, but bloat sometimes means finding out something is just bigger than you thought (e.g. technical issues emerge). How do you deal with having to adjust scope when your 60% turns out to be 101% of time?

This is a fact of life and is why having features that you can drop out acts as a contingency for the project. A well-run and well scoped project should be able to handle this quite normally but the example you are giving shows that the project was badly estimated. It appears that the project needed to use nearly twice as much time as had been intended. The use of timeboxing and realising that there was so much the de-scoping going on would force you to ‘fail fast’ … and remember failing fast is good if you are going to fail.

Q2/ Could you outline the perfect project for Agile, and the perfect project for PRINCE2?

I would be reluctant to answer this question because I do not believe you should think this way. PRINCE2 is an approach to project management and agile is a very broad term that encompasses (primarily) a series of delivery techniques, but also project management. I believe the question you should be asking is how much agile do I use on this project? Unless of course it is not a project and then you would treat it simply as business as usual (BAU).

Q3/ Are there any free MoSCoW tools that you would like to recommend using on projects?

The simplest free tool you can use is a spreadsheet application. Using a low-tech solution such as a whiteboard with index cards or post-it notes is also good. For more complicated situations where you may need to satisfy audit requirements then you might try looking at particular tools. My general advice regarding tools though, is to see what you have already got and do not ever let tools drive your process.

Q4/ At the start of the project should the business/BA/PM agree the definitions of each MoSCoW priority – i.e. Must = does it deliver the business case etc?

The simplest answer to this question is yes. Everyone needs to know what is meant by a Must, Should and Could. Linking it to the business case can be quite complicated so go carefully here. Linking each requirement to some formal business value is quite tricky but has a lot of advantages going forward. If in doubt my advice is to do what the streetwise MoSCoW guide advises and that is ‘keep it simple’.

Q5/ How do you handle “Shoulds” becoming ‘Musts’ as the stakeholders change their minds?

Again, this is a fact of life and you should embrace change because it is going to happen. I would suggest you need to look at why a Should has become a Must as this may mean the project objective is changing which could be a cause concern, or the moscowing was not done correctly in the first place. Priorities do change but finding new Musts is something that can be quite painful. However, remember you do have contingency in the Shoulds and Coulds to cater for this

Q6/ I once saw a demo of a product called DOORS which used a method of comparing requirements to prioritise (e.g. is #55 more important than #33) – does not strictly define the Musts but would you see any benefit in this technique?

I like this question because I get this question quite often. There is some merit in comparing requirements but surprisingly from my experience not that much. Again, keep it simple, a Must is a Must, a Should is a Should and a Could is a Could. Further to this point it is worth noting that you cannot have a Must that is more important than another Must.

Q7/ I’m about to introduce Agile into an Ad agency that’s never heard of it before… as Kanban. Any advice as to where to start?

Crikey! That is a very big question. In very simple terms you need to start with understanding what you are trying to achieve with agile because you need to be aware it is a means to an end and not an end in itself.

Q8/ In software projects on average, what % of features are used? Is the answer useful to tell clients?

I think this is a very interesting figure to give to your clients because the general feeling from some research which you will find on the Internet is that in the region of 25% of features are not used at all and a further 25% are barely used. Irrespective of the exact figures this does show that when you are looking for contingency on a project – the scope is the best place to go as opposed to time, money or compromising on quality.

Q9/ What are your thoughts on using value to get to MoSCoW? For example, SAFe advocates WSJF (weighted, shortest, job first). Or Business Value Model? Or ROI? Should these “value” metrics be part of prioritization?

I believe that this is a good idea although it is quite advanced. I would suggest to anyone that they learn to walk first before they run. Generally speaking return on investment (ROI) is a good indicator to value. Take care with concepts such as WSJF because they may not be appropriate in a project context whereas it is fine for BAU.

Q10/ What tools similar to Atlassian JIRA do you know which supports MoSCoW priorities handling out of the box?

I hope the earlier answer addresses this one.

Where do you stand on relative priorities for Shoulds? e.g. It’s not a Must but I really want it more than the other Shoulds.

Take a look at my response to an earlier question similar to this but specifically I find that the customer or business engaged on a project automatically handles these relative priorities and in the real world you rarely if ever need to do any relative prioritisation in advance.

Q11/ You talk about MOSCOW against time, but can’t it also be applied against budget where budget is more of a limitation than time?

Yes you can do this and some people refer to a concept called ‘cost boxing’. However, one of the strongest weapons in the armoury of agile is to create immovable deadlines that focus everybody’s minds and delivers a working cadence. There is also a very close relationship between time and money hence the expression ‘time is money’.

Q12/ While you mention (MoSCoW) dependencies and grouping of these, it shouldn’t be confused with product user stories which follow INVEST in that a user story is not dependent on another – yes?

I agree that these two groupings or lack of groupings i.e. independence are not the same thing. User stories should be independent of each other so that they can be worked on separately. But the functional groupings that I mentioned during the webinar relates to bunches of user stories that relate to the same thing such as the ordering process or the payment process. Sometimes these are badged as ‘epics’ but be careful not to oversimplify this concept.

Q13/ How frequently do you recommend to review the priorities/re-prioritization, in particular in the situation like you have 300 requirements in a project/release backlog?

I may have answered this one during the webinar. Prioritization is something that is a continuous process. It happens on a daily basis as the understanding of the project grows and the requirements become clearer and therefore change. I would not prescribe a specific time interval other than the notion that in effect you are doing it all the time.

Q14/ If you have 60% musts at the project level does this mean that the customer needs to agree to potentially 40% of the features/benefits not being delivered?

Yes that is absolutely correct. However, if they did lose 35% of their project they think they might be a little disappointed all other things being equal. It is reasonable under normal situations for a customer to expect to receive all of the Musts all of the Shoulds and a fair amount of the Coulds.

MoSCoW method guide

Download the Streetwise Guide to MoSCoW

What is the MoSCoW prioritization method?

The MoSCoW prioritization method is an acronym for “Must have”, “Should have”, “Could have”, and “Won’t have”.

The MoSCoW method was developed by Dai Clegg in the late 1990s and is based on the Pareto principle, also known as the 80/20 rule. This principle states that roughly 80% of the effects come from 20% of the causes.

MoSCoW is a prioritization technique that helps teams to categorize project requirements or features based on their importance. This allows teams to focus on delivering the most critical features first and deferring less important features until later.

MoSCoW prioritization is often used in Agile approaches because Agile projects typically have shorter development cycles and require frequent re-prioritization of requirements or features.

MoSCoW prioritization helps to ensure that the most important features are delivered first, which can be critical for meeting project goals and timelines.

Why use MoSCoW prioritization?

The MoSCoW prioritization method is used because it allows teams to focus on delivering the most important features first, which can be critical for project success. By prioritizing requirements or features, teams can ensure that they are delivering the most critical features first, which can reduce the risk of project failure.

Additionally, the MoSCoW method can help teams to manage scope and avoid feature creep. Feature creep occurs when additional requirements or features are added to the project scope, which can cause delays and increase costs.

By using MoSCoW prioritization, teams can keep the project scope under control and focus on delivering the most critical features.

When to use MoSCoW prioritization?

MoSCoW prioritization is typically used in Agile approaches, where projects have shorter development cycles and require frequent re-prioritization of requirements or features. However, the method can be used in any project where prioritization is required.

The MoSCoW method is particularly useful when there are limited resources or when there are time constraints. By focusing on delivering the most important features first, teams can ensure that they are making the most efficient use of their time and resources.

Classification

The MoSCoW method provides a simple and effective way to prioritize requirements. The technique involves placing requirements into four categories: Must have, Should have, Could have, and Won’t have.

Must have

These are the critical features that must be delivered for the project to be successful. If these features are not delivered, the project is likely to fail.

Should have

These are important features that should be delivered, but are not as critical as the Must have features. If the Should have features are not delivered, the project can still be successful, but it may not meet all of its objectives.

Could have

These are features that would be nice to have, but are not essential. These features can be deferred until later if resources are limited or if there are time constraints.

Won’t have

These are features that will not be delivered in the current project cycle. These features can be deferred to a future project, or they may not be required at all.

MoSCoW step-by-step guide

To use the MoSCoW method, follow these steps:

1. Identify project requirements or features.
2. Categorize each requirement or feature into one of the four categories (Must have, Should have, Could have, or Won’t have).
3. Review the categories and ensure that the most important features are in the Must have category.
4. Create a development plan that focuses on delivering the Must have features
5. Once the Must have features have been delivered, move on to the Should have features. If resources are limited, the Could have features can be deferred until later.
6. If new requirements or features are added to the project, categorize them into the appropriate category and re-prioritize the features as necessary.
7. Review the categories at the end of each development cycle to ensure that the project is still on track and that the most important features have been delivered.

Example of the MoSCoW method

Here is an example of how the MoSCoW method can be used to prioritize features for a software development project:

Must have:

• Ability to log in and out of the application.
• Search functionality.
• Ability to create and edit user profiles.
• Ability to purchase products.
• Ability to view order history.

Should have:

• Ability to save products to a wishlist.
• Ability to rate and review products.
• Social media integration.
• Mobile app compatibility.
• Multiple payment options.

Could have:

• Personalized product recommendations.
• Loyalty program integration.
• Live chat customer support.
• Integration with third-party shipping providers.
• Advanced search filters.

Won’t have:

• Virtual reality shopping experience.
• Augmented reality product visualization.
• Voice-activated commands.

In this example, the Must have features are the most critical and must be delivered for the project to be successful. The Should have features are important but can be deferred if resources are limited. The Could have and Won’t have features are nice to have, but are not essential for the project.

Summary

The MoSCoW method is a prioritization technique used in Agile approaches to categorize project requirements or features based on their importance.

The MoSCoW technique allows teams to focus on delivering the most critical features first, which can be critical for achieving project success. The method is particularly useful when there are limited resources or when there are time constraints.

To use the MoSCoW method, project requirements are categorized into four categories: Must have, Should have, Could have, and Won’t have. The most important features are prioritized in the Must have category, while the Should have, Could have, and Won’t have categories are used to prioritize less critical features.

By using the MoSCoW method, teams can ensure that they are delivering the most important features first and avoiding feature creep, which can cause delays and increase costs.

To learn how to use MoSCoW in more detail, the method is taught on both the Agile Project Management courses and PRINCE2 Agile courses.

Infographics