MoSCoW Method of Prioritization explained
MoSCoW Method: This article explains MoSCoW Method in a practical way. Next to what it is (meaning, acronym and origin), and which advantages are connected to using this model, this article also highlights the MoSCoW Method requirements, including a practical example. You will also learn how applying this method will enable you and the team to reach deadlines in time. Enjoy reading!
What is the MoSCoW Method of Prioritization?
Prioritising is often challenging. Particularly when it comes the implementation of new ideas and / or technologies. Everyone in an organisation always wants everything to be done right away and that is practically impossible. There are several tools available to make prioritisation easier. The MoSCoW Method of Prioritization is one them.
The MoSCoW Method is a prioritization technique, which can be used in a variety of situations.
Origin and advantages of the MoSCoW Method
The method was developed by Dai Clegg, a developer working for the software company Oracle. Originally, it was used to categorize product features, derived from user stories. It was later used in the Dynamic System Development Method (DSDM). The method contains multiple prioritization categories, with labels for each requirement, making it easier to prioritise.
Even though the origin of this prioritize method is in software development, it is also highly applicable for agile project management, market launches, product releases, starting a new business or change processes.
With the MoSCoW Method, requirements are determined for the result of the project or product. It is about setting requirements by order of priority. The most important requirements need to be met first for a greater chance of success.
Meaning and acronym of the MoSCoW Method
Moscow is an acronym made up of the first letters. The two Os have been added to make the word ‘moscow’ readable, they don’t have any meaning themselves. The M stands for ‘Must haves‘, S for ‘Should haves‘, C for ‘Could haves‘ and W for ‘Won’t haves‘ or ‘Would haves‘.
The requirements when you start with the MoSCoW Method
It’s a good idea to first specify the requirements together with all team members before starting the MoSCoW Method. When determining the requirements, you should take into account what is important to all the stakeholders. Brainstorming with everyone involved will lead to good, qualitative requirements.
The requirements are prioritised to prevent them from becoming to expensive or unrealistic. The main goal is to come up with requirements that add the most value for the company. The project requirements are divided into one of the following categories:
M – Must haves
These are about the minimal requirements that are determined in advance that the end-result has to meet.
Without meeting these requirements, the project fails and the product won’t be use-able. They are a necessity for a workable product and there is no alternative. The ‘Must haves’ are essential. MUST is also explained as an acronym that stands for Minimum Use-able SubseTs.
As an extra exam assignment, University of Applied Sciences Automotive students have been asked to design a car that can at least drive (minimal requirements).
It’s okay if the car only has a chassis, without any bodywork. It’s about the construction of the individual parts and drive train to the combustion engine. In this case, the Must have is that they have a drivable car by the end of the academic year.
S – Should haves
These are additional and much desired requirements that have a high priority, but are not essential for a usable end product. The product will be usable even if these requirements aren’t met. When they are met, they will only add to the value of the product. Depending on the available time, you can always return to these requirements at a later time.
The University of Applied Sciences Automotive student might like to add a tow bar to the car (should have), but as long as the car can drive without the tow bar, their project will be successful. They can always add the tow bar at a later stage.
C – Could haves
These requirements can be considered if there’s time left. If not, it’s no problem and will not have a negative effect on the final result. The ‘Could haves’ have a lower priority than the ‘Should haves’.
This option will only be included if there really is more than enough time to make it work. This category is also referred to as ‘nice to have’; they’re more a wish than an absolute requirement.
The University of Applied Sciences Automotive students would perhaps like to install a tachometer in the car. It’s not an important (exam) requirement, but it’d be great if they manage to do it.
W – Won’t haves (and would haves)
These are about wishes for the future that are often impossible to realise or cost a lot of time. If it’s simply not possible, it’s best not to waste any energy on it.
If it is achievable, then a lot of time (and money) will have to be invested and it’s labelled a ‘Would have’. ‘Would haves’ are often followed upon at a later stage after the initial project is finished.
The University of Applied Sciences Automotive students don’t have to make a car that will actually drive on public roads.
It’s meant for study. If they do want to take it on public roads, it will need bodywork and comply with safety standards. It also involves getting approval from the Vehicle Standards Agency in elaborate process.
How to reach deadlines using the MoSCoW Method of Prioritization?
Correctly applying and sticking to the MoSCoW Method will lead to a clear way to lead a project. Everyone involved with the project will know what needs to be done first, when it has to be finished and why it’s important. By assigning priorities to requirements, a project becomes more manageable and it’ll be easier to meet the deadline.
Development and support of a project is also made easier by initially ignoring less important requirements. By focusing on the key requirements, you end up with a sell-able product that meets the minimum requirements. That way, must haves become unique selling points, which will benefit the buyer.
It’s Your Turn
What do you think? How do you apply the MoSCoW analysis in your project or organisation? Do you recognize the practical explanation or do you have more additions? What are your success factors for applying the MoSCoW Method?
Share your experience and knowledge in the comments box below.
- Baxter, R. (2004). Software engineering is software engineering. In 26th International Conference on Software Engineering, W36 Workshop Software Engineering for High Performance System (HPCS) Applications (pp. 4-18).
- Stephens, R. (2015). Beginning Software Engineering. Wrox Publishing.
- Hatton, S. (2008). Choosing the right prioritisation method. In Software Engineering, 2008. ASWEC 2008. 19th Australian Conference on (pp. 517-526). IEEE.
- Robson, W.A., Simon, Shena. (2014). Moscow in the making. Taylor & Francis Ltd.
How to cite this article:
Mulder, P. (2017). MoSCoW Method. Retrieved [insert date] from Toolshero: https://www.toolshero.com/project-management/moscow-method/
Published on: 05/12/2017 | Last update: 03/05/2023
Add a link to this page on your website:
<a href=”https://www.toolshero.com/project-management/moscow-method/”>Toolshero: MoSCoW Method</a>
We are sorry that this post was not useful for you!
Let us improve this post!
Tell us how we can improve this post?
One response to “MoSCoW Method of Prioritization explained”
Thanks for providing a concise and easily understandable explanation. The one thing that stood out to me however, is the example for the Should Have section. Tow bars are clearly “Could have” at best and in this situation would probably end up in the “Won’t have” bucket simply because there’s no justification for them at all on an experimental vehicle that will not be driven on a public road. To make this more believable I’d recommend changing the example for “Should Haves” to either: Seats – the vehicle should have a seat for the driver but as long as someone can drive it somehow it’s not critical. Or Steering Wheel – ideally the vehicle should have a steering wheel, but as long as it CAN be steered (perhaps by levers) then the project will pass. Otherwise, this is a really useful article. Thanks again.