Moscow is not just a city in Russia

grayscale

The scenic, historic city of Russia, would probably come into your mind when you hear the word ‘Moscow’. Would you be surprised to learn that Moscow is not just the capital of Russia but also a very important prioritization technique that is used to decide what should be built and shipped in project deliveries all around the world?

How it all started

The MoSCoW technique/method also known as MoSCoW analysis/prioritization was initiated by Dai Clegg, a software development expert during his tenure at Oracle. Originally, the MoSCoW method was designed for time-boxed projects as a prioritization framework. 

You must be wondering, ‘what’s a time-boxed project?’. These are the projects which have a previously agreed period of time during which a person or a team works steadily towards completion of a goal/s

Typically, when considering a fixed timeline, it’s important to identify the relative importance of work that is required to be completed whilst making progress and keeping deadlines in mind. One of the most important decisions that a team has to make in a project is to decide ‘What’, ‘When’ and ‘Why’. Getting this right is paramount to being effective in impactful delivery. This is where prioritization plays a major role. Prioritization can be used for requirements, user stories, tasks, tests and acceptance criterias. 

However, currently the usage of this MoSCoW method has broadened widely and has been adapted by many users across multiple domains. 

The MoSCoW method in simple terms 

Let’s take a look at what the MoSCoW  method is and what we can do with it.  

MoSCoW in simple terms, is a prioritization technique that helps in identifying and managing priorities. It is specifically used as an aid in projects when prioritizing requirements. 

Here’s what MoSCoW stands for – 

The use of MoSCoW in requirement prioritization

Among the numerous things that can be prioritized using the MoSCoW  technique, the focus of this article is on how it can be leveraged to support requirement prioritization and the role that each of these rules play in when used in the requirement prioritization process. 

Must Have – Like the word suggests,  the requirements that fall under this category consists of the Minimum Usable Subset (MUST) of requirements that the project is assured to deliver which are typically mandatory and non-negotiable for the product, project or release. 

For example, when considering a release for a banking application, some must-have requirements might include security functionalities in order to maintain compliance.

The requirements that belong to this category can be easily identified by asking yourself the question ‘what happens if this requirement is not met?’. If the answer is ‘the project/release would be useless without this in place even if we deliver on time’ then it can be considered as a ‘Must Have’ requirement. 

Should have –  These requirements are merely a step below the above mentioned ‘Must have’ requirements.  Though meeting these requirements can be considered to be important to the product, project or release they are not vital to be met. Even if these requirements are left out, the product/project will still be able to function. However, if these are included, a significant value will be added. 

The main difference between ‘Should have’ and ‘Must have’ requirements are that the ones that belong to the ‘Should have’ category can be pushed back to be addressed in a future release without impacting the current one. 

Some examples of these include minor bug fixes and performance improvements.  

For example, a ‘Should have’ requirement when considering a transportation application such as Pickme or Uber would be to have the option to rate and provide feedback on the driver and the overall experience. 

Could have – The requirements that fall under the ‘Could have’ category are also referred to as ‘nice-to-haves’ and considered as ‘desirable but less important’. These are not necessary to the core functionality of the product/project when compared with the ‘should have’ requirements and these can be considered to be taken up only if there is extra time and budget allocated. Typically, When a problem occurs in the project and the deadline is at risk, the requirements that are placed in the “could-have” category are often the first to be deprioritized since they have much smaller impact on the outcome if they are left out.

For example, when considering an online clothing store, a ‘Could have’ requirement would be to provide information regarding the specifics of the material. Without this the user will still be able to find the clothing item they are looking for but having this will provide more options to the user to make their choice. 

Will not have –  These are requirements which the project team has agreed to not be delivered within the considered timeframe. Identifying and categorizing requirements into the ‘Will not have’ category is one way to help prevent scope creep. Some of the requirements  in the “will-not-have” group will get prioritized in the future, while others are not likely to happen in the foreseeable future. A subcategory within this can be created in order to identify these requirements. 

For example, integrating a virtual assistant or a chat bot in the website for an online store could be considered as a ‘Will not have’ requirement. 

Which category each requirement belongs to depends greatly on the domain, stage of the product, the vision of the product and many other factors. 

Tips and recommendations

Now that we have covered the MoSCoW  rules, before the actual requirement prioritization process can take place there are a few things that need to happen. 

  1. Firstly, the product team and other relevant stakeholders need to discuss with one another and get aligned on project objectives and prioritization factors. 
  1. Then, all participants must agree on which initiatives to prioritize. This step is  extremely important as it will prevent disputes and disagreements in prioritization before they take place which might lead to hindering the project progress. 
  1. Finally, it is also important to reach a consensus on the percentage of resources that will be allocated to each category which will make it easier when conducting the requirement prioritization and deciding on what requirements can be considered for each category. 

Is the MoSCoW method for everyone? 

You might be wondering, ‘is the MoSCoW  method suitable for any kind of project?’. The answer is not all the time. Even though this is a simple and quite effective method of prioritization, it might not always work well with projects that have a very complicated backlog with numerous time sensitive releases. 

However, if you are on the lookout for a well recognized and widely approved technique for prioritizing requirements, using the MoSCoW method is a great place to start. Even if you wish to explore different techniques to see which works BEST for your project, this is a fairly easy and comprehensible technique to experiment with.

Happy prioritizing!

Hashinika Manathunge

Business Analyst 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.