The MoSCoW prioritization in Agile is a very simple and effective way of prioritizing product features. Working as a product owner prioritizing is hard at the best of times. It is no easy task trying to keep the team happy, mange stakeholders expectations and do the best for the product.
The MoSCoW method is an approach I have used to prioritize product backlog into story map for upcoming sprints. It worked really well as in that scenario I was working with a team that was just formed to work on a new product. It essentially helped me define my minimum viable product. It was simple and effective.
There are times when you need to prioritize a product backlog where it doesn’t work very well especially when you have a defined product and its not as simple as defining the MVP. You need to take into consideration market demands, customer feedback, regulations, and dreaded technical debt.
History of MoSCoW
The MoSCoW technique is a prioritization method which was created by Dai Clegg who was a software developer for Oracle at the time. His vision for the design was to assist the people on his team to prioritize a variety of tasks throughout the development for the release of software products.
MoSCoW prioritization process uses four initiatives as a prioritization categories for keeping up with the requirements needed to complete a series of tasks. The prioritization tool prioritizes tasks in a hierarchy throughout any project.
- Must Have
- Should Have
- Could Have
- Won’t Have this time
While the MoSCoW technique isn’t original an agile project management technique it is consistently incorporated and plays a role in agile management techniques. This methodology breaks projects into sections known as iterations which is a single development cycle.
Must Have Requirements
Must Have requirements represent your products Minimum Viable Product. These are the essentials requirements that the product will need to launch.
They provide the maximum value.
These requirements should stand out above the rest as absolute critical requirements for the product or project,
Should Have Requirements
While a should have product feature would not necessarily be a requirement for a product to function, it is that the team has a common understanding that it is still an important feature that contributes to the product’s overall value.
To best determine if a product is a should have feature, ask yourself as product manager whether or not the program would still work without the feature being present.
After making that determination, identify if the loss of the feature does have significant impact. It is centered around fulfilling customer’s wants instead of their needs even though it does make a significant impact to user experience.
An example of this is having software that gives the option for users to have access website features offline.
Could Have Requirements
Could have features are considered as product features that are nice to have and contribute to product value when present, but do not affect the product value in its absence.
These features are not absolutely necessarily to have for a product to function nor would a customer miss them if they are not available.
They have lesser impact on the product and should not be prioritized over must have and should have features. An example of a could have feature would be a new chat feature throughout the website.
Won’t Have or Will Not Have
Won’t have is a method for putting ideas together to reference later, but it is not something that will be used on a product during this particular time.
These are features that you would prioritize the least. There are two categories within the won’t have initiative that you would assign feature to:
- Won’t Have This Time
- Will Never Have
Time and resources would not allow for these features to be used and may be considered in a different way for a future product. An example of this kind of feature in a website would be a search bar autofill bug fix.
Prioritize Product Backlog with MoSCoW Technique
You can choose the variable what you want to use MoSCoW for what you see fit. It doesn’t just need to be features. It rarely is as simple as just features usually there are a number of variables at play.
Product Features:
When prioritizing product features it should align with the product vision and product roadmap. The MVP MUST have a usable subset of basic features. It is critical to have a project success by delivering a feature that the user wants.
Project Budget Limitations:
If there is a budget that is limiting the development of a product, the MoSCoW method would make decisions on the must-haves and the should-haves and take consideration of the additional things based on what can fit into the budget.
Team Expertise:
The expertise of the team is another way to utilize the MoSCoW Prioritization in Agile. If the team does not have the skills necessary to complete the development of a product, it would be important to prioritize tasks based on what they are capable of doing.
Applying MoSCoW Prioritization in Agile
When beginning the analysis process of the MoSCoW Technique in Agile Software Development, it is important to follow these series of steps:
Identify Stakeholders
One of the reasons why it is important to identify the key stakeholder is to prevent the development from having too many individuals with a say in each stage. Having too many people with the ability to share input could allow for things to get chaotic quickly. Being proactive by putting a limitation to the amount of voices will streamline the process in a much more functional way.
Determine Arbitration
However, with the limited amount of product team involved in the process, disagreements will still find its way in the software development process. Having a system set in place to diffuse those disagreements and create a method to move forward is important. One recommended system for diffusing or preventing disagreements would be putting things up for a vote. This would present itself as a helpful guide for resolution or prevention.
Assign Team Resources
Assigning what resources goes where is vital to make sure that every product category gets the right amount of allocation in order to accomplish each necessary task. These allocation of resources can also be used to determine a proper timeline for completing tasks, and deciding how to properly record each task into a list to keep track of in the process.
Determination Product Timeline
The must-have tasks will likely take up 60% of the team’s time and effort while the could-have tasks take up about 20% of time and effort. This is best outlined here. After these things are done, your team will be able to begin prioritizing in a systematic way to maximize productivity.
Benefits of the MoSCoW Prioritization in Agile
The MoSCoW technique finds itself beneficial because it allows for you to create an appropriate structure for what to prioritize first. It can be used for projects that are already in development and new ones.
Set Priorities at Different Levels
This prioritization process can be used to set priorities at different priority levels of the development pipeline. Prioritizing the most important aspects of a product allows for everyone in your team to know what they are and it also gives them clarity in how to move forward.
Resolve Stakeholders Complaints
A vital benefit of this technique is that it presents ways for your team to take into consideration of as well as resolve the complaints that stakeholders have for particular portions of the product.
Minimize Agile Team Distractions
The MoSCoW technique also allows for expectations to be clear for investors. It showcases a method for knowing the costs for each feature that is being considered. Keeping a clear structure of priorities also allows for consistency and organization. This minimizes distractions as well as preventing the team from forgetting about the primary goals of the project.
Pitfalls of the MoSCoW Prioritization in Agile
While there are benefits to utilizing MoSCoW prioritization in agile, there are some disadvantages that presents itself through prioritization methodology.
Scoring Inconsistencies to Project Requirements
There are times where the scoring process of tasks within a project can be inconsistent which leads to them being placed in a category that it should be in.
Not Objective Means vs Opinions
The methodology does not have an objective means of ranking the initiatives. This brings uncertainty in features for instance that would be in the won’t have initiative that likely should have been prioritized differently.
Removing Key Stakeholder Input
Tasks can also easily be put into categories that it should be in when key stakeholders aren’t being informed or sought out for input. If stakeholders aren’t considered in this process, the team may prioritize a feature that is not favorable to them.
This can lead to significant issues down the road. These issues also can exist if there is absences in having leadership as a primary part of of the decision making process.
Product Team Bias
Since the methodology of scoring in MoSCoW prioritization in agile method isn’t objective, the bias of team members can prevent them from accurately assigning a task into the right group. This can find itself applicable with features that they like or dislike.
The team could unanimously agree that a feature should be placed in the should-have initiative because they are in favor of it, meanwhile their stakeholders would not consider it’s importance as being there.
