Master User Requirements with MoSCoW Model Of Prioritization

Most apps we use today look pretty different in comparison to their initial releases. The same goes for your business and your users. New apps come and go and very few actually survive the competition. Some get sidelined, while others perish and this phenomenon has a lot to do with how the app-makers prioritize what to offer to the users. Agile Product Development teams know this is best. To figure out what to implement first, hoping for success, you can opt for a variety of prioritization models. This time we’ll be examining how the MoSCoW model of prioritization can help you achieve your goals.

Just think about Snapchat stories as an example…

Snapchat stories are one of the best examples of break-through features that the very inventor couldn’t stay intact with. Within 2 years of launching “stories” on its platform, Snapchat was rivaling Instagram’s own version of short-lived stories, that completely dethroned Snapchat. 

This happened because Facebook started capitalizing on the already established market for stories. The company prioritized new innovations in the concept, took user feedback seriously, and a few iterations later, it overtook the market.

The magic happened because of right prioritization. In this article, we discuss the MoSCoW Prioritization model for Agile Product Development teams. The model is lightweight and easy to adapt. Let’s dive into it!

Why is priorization key in agile product development?

When you’re building a product using the Agile methodology, it is often challenging to balance out product requirements with fulfillment capabilities. Most teams struggle to decide whether the features they’ve picked will actually be fruitful for the user, and for the business itself.

MoSCoW Prioritization Model in Agile Product Development offers a set of rules for smartly segregating requirements based on the impact of executing one requirement over the other. 

Development teams and key stakeholders can better understand the varying degrees of importance that the user requirements come with. They can use this knowledge to prioritize effort investment, timebox their projects, and work on mutually agreeable initiatives. 

How does the MoSCoW prioritization model work for agile product development?

In theory, the MoSCoW model is built of 4 prioritization categories; 

• Must 
• Should 
• Could
• Won’t 

Hence, the MSCW acronym derived loosely sounds like the city of Moscow, which we believe could have led to the coining of the term – MoSCoW. 

MoSCoW Prioritization Categories

The MoSCoW model lays down four categories under which the requirements are classed. 

• Must Have – Non-negotiable product needs that are critical for the product to work
• Should have – Initiatives with considerable significance but no pressing need to execute 
• Could have – Desired initiatives that can be worked upon but have low significance 
• Will not have – Initiatives that don’t add any quantifiable value to the project vis-a-vis the chosen time frame

It’s important to remember that all four categories use “time” and “viability” as the key factors.

A certain requirement may not be a “Must Have” today but may become so tomorrow. Similarly, as the project proceeds and gets more competitive, certain features that are “Should Have” today will become “Must Have” tomorrow.

MoSCoW Prioritization Example 

For instance, let’s say you want to build a User Login system for your application. The requirements gathered are as follows; 

• An interface for logging in 
• A database for storing login credentials
• A mechanism for handling authentication 
• “Sign in with Google” integration
• Reset Password Workflow
• One Time Password Authentication
• Single Sign-On for cross-platform connectivity 
• Microsoft Active Directory Integration
• Password hashing  

Now let’s arrange these requirements as per the MoSCoW model. 

We are able to identify the most pressing needs for the User Login system to work properly, and everything else that can be prioritized as per the timeframe.

You will notice that without implementing the “Must Have” requirements, the Login system simply can’t work. All other requirements are add-ons that can be picked as per the availability of time and resources. Also if the business needs demand, certain requirements can be bumped up the list.

So, how did we exactly decipher what requirements will go where in the MoSCoW prioritization table? Let’s have a closer look at it.

How Does MoSCoW Prioritization Work for Agile Product Development?

As discussed earlier, the MoSCoW model finds its application in the requirement finalization phase of the Agile Product Development lifecycle. Using this model, developers, designers, product managers, and project owners, brainstorm as to which requirements will qualify to be pushed in the cycle, and which will be held back.

As requirements pour in, they’re actively defined and redefined several times before the actual development begins. The MoSCoW model helps the team working on the product to figure out the priority in which the requirements will be fulfilled.The priority is mostly associated with a timeboxed release. If the release is due in 3 weeks, the team will pick requirements that the product owner (customer/client) wants at the end of the release.   

Let’s say if there are 10 requirements in total, it’s a general understanding that not all requirements will not have the same significance towards the release. The top requirements will be picked to deliver on the said requirements efficiently and productively.

The remaining requirements can be prioritized in the later releases, let’s say in version 2 or version 3 of the product. Therefore, the cycle will keep churning new requirements for each release and using MoSCoW, the team will hand-pick the most relevant ones to work on.

Now, how do you classify the requirements as per the MoSCoW model rules? Let’s find out.

Must Have 

Non-negotiable product needs that are critical for the product to work

Must Have requirements from the basis of the product. Without fulfilling these requirements, the product will totally lose its value. While settling on Must Have requirements, you can ask the following questions.

• Will the product meet its objective without it?
• Will the product be safe without it?
• Will the product be legal without it?
• Will the product be a viable solution without it? 

If all or any of the questions return “No”, then this requirement in question is a Must Have. Now, there can be debates on whether this requirement should be kept in the current release or the next one. To prioritize the same, you always need to look at the goals for the release. This kind of release planning can also be done using Story Maps. 

If the goals can’t wait, the requirement can’t wait either. In the User Login system example we used earlier, “Password hashing”, “Reset Password Workflow” are both Must Have requirements, but if other security measures are there to protect the passwords, you may want to push hashing to the next release.

Should have 

Initiatives with considerable significance but no pressing need to execute 

Should have requirements are usually the features that you will find in most applications that compete with your product, but are not super critical for you. While you would love to work on these requirements, you need to ask if you really should. More questions for filtering Should have requirements. 

• Is it among the core requirements of the product?
• Will leaving it out drown the product?
• Is there an alternative available for this requirement? 

If you answer the first two questions as “No” and the third one as “Yes”, you’ve found a Should Have requirement. It’s a good thing to have but if it comes to eliminating the requirement, it will not have a critical impact on the product. 

Could have

Desired initiatives that can be worked upon but have low significance

Could Have requirements sum up the things that have a relatively lower impact and they’d be welcome if they fit well inside the timeframe. If you don’t work on the Could Have requirements, there would be a little to no impact on the product. Ask these questions;

• It is desired but is it important for the release?
• What happens if this requirement is not fulfilled?
• Are there more pressing requirements lined up?

You are looking for “No” and “Nothing” for the first two questions and a “Yes” for the third one to satisfy a Could Have requirement.

The “Could Have” requirements shouldn’t be picked until the Must Have and Could Have requirements have been fulfilled. These are like those tempting bells and whistles that your product would look great with, but can absolutely do without.

Will not have 

Initiatives that don’t add any quantifiable value to the project vis-a-vis the chosen time frame 

Will Not Have requirements obviously point towards the thing that you shouldn’t expend time upon. It’s best to leave them off for the current release but keep them in hindsight for upcoming discussions.

• Is this requirement important at all?
• Does it contribute to any of the product’s objectives?
• Can it be called off without any impact on the product?

Again, if the first two questions return a “No”, and the third question is a “Yes”, you needn’t work on this requirement at all. Then why list it in the first place? This is done to keep an idea of how far the product can go, and what possible features it can have in the future.  

Planning the Release  

Now that we know the priorities of our requirements, we can start planning the release efficiently.

The Must Have requirements are fixed, which means you’ll have to allocate tasks and resources for meeting these requirements as per availability first. Usually, these requirements take up to 60-80% of the effort.

Then we move to the Should Have and Could Have requirements if there is space left to accommodate them. You can space about 20-40% effort for these requirements. 

Finally, the Will Not Have requirements will be there on the list but will not make it to the release. 

Top 3 Tips to Ace MoSCoW Prioritization Model 

1. Don’t Forget to Factor in the Uncertainties 

It’s important to remember that sprints and releases come with unforeseeable delays, obstructions, and bugs that may push the product timeline. Therefore, the prioritization will undergo changes at the end of each release. 

The prioritization can’t be carried out on a hard deadline basis. The creators of MoSCoW meant to keep the releases highly timeboxed but you can do without that as well. What’s more important is the wisdom to move priorities when needed.    

2. Use an Agile Product Development Tool

Not adopting an Agile Product Development Tool early on is a rookie mistake that most product owners do.It may seem like you can manage it using sticky notes and a whiteboard but as the product grows complex, you run out of space.

A specialized Agile Software Tool such as StoriesOnBoard can facilitate both product planning and project execution. It comes with several features for communication and task tracking that Agile software teams can heavily benefit from.

You can manage your team, control the project timeline, and use Agile-friendly features such as Kanban Boards for building productivity into your product, right from the start.  

3. Learn to Decompose Requirements

Do you feel as if all the requirements are “Must Haves”? Worry not, it happens with most teams. A quick solution to this problem is smart decomposition. 

You decompose high-level requirements into smaller sub-requirements and then evaluate the priority. A larger requirement may look like a Must Have but would be too difficult to execute at the same time.

This quandary is solved when you break down the requirement into achievable segments and prioritize among those. This way, you’ll not overburden the deadline and will not make lengthy compromises.

Conclusion

The most successful of products owe their prowess to the team behind them. The market is extremely competitive in terms of how quickly can a product evolve and if it evolves in the right direction. The whole business can crumble even with all the right resources if the product follows the wrong priorities. 

MoSCoW model of prioritization for Agile Product Development provides a simple yet effective framework for making wise priorities. It’s up to you to decide if you’ll pick requirements that cost you or save you.  

About the author: Nandini Sharma is the Assistant Marketing Manager at ProofHub, Agile Project Management Tool and Basecamp Alternative. Nandini brings close to a decade of experience in the field, and has successfully executed a number of brand building and marketing campaigns throughout her career. A specialist in the field of marketing, Nandini is well-versed with technical know-how, and always stays on top of the latest trends in the digital world. You will find her constantly putting marketing strategies into motion with perfection. Over the years, she has triumphantly created a wide base of the audience on a number of popular online platforms. When she is not busy in penning down out-of-the-box marketing ideas, she can be found channeling her creativity into art and craft activities.