MoSCoW Prioritization

No, we aren't talking about Russia or their Capitol. We are exploring quite a few techniques that some may not be aware of when trying to prioritize the infinite list of ideas a business can generate vs. the finite amount of time and capacity to do them. Over the next couple of months, I thought I would share some of the more common techniques that I come across in live-use with organizations. It is really best to think of these techniques as facilitation techniques. Don't just take the answers they give you, use the answers to foster discussion and collaboration with your stakeholders.

First lets talk about the word Prioritization. I am not a huge fan of the word because its root is "prior" meaning only one before. How many times have you been in an organization and the stack/rank priority of work has 30 1's and 50 2's? I would prefer to say the work is "ordered" which conveniently the definition of prior also says can be the case. The word ordered seems more fluid and subject to change which is what we embrace in uncertainty. I think it is really difficult to stack-rank business value. Anyway, people use the term often, so we can keep using it LOL.

Prioritization is an important process for product teams working in an Agile/Scrum environment. There are several prioritization techniques. Let's talk about a technique called the ‘Moscow Prioritization” product teams can use to prioritize work with stakeholders.

What is prioritization, and why is it important?

Not every feature, task, or idea is equally important / offers the best value to the customer and the business's return on investment (ROI). Without the right prioritization, there is no clear path to achieving the business vision. Prioritization is the process that evaluates the importance of the features, tasks, or ideas to form the best roadmap so that teams can eliminate unnecessary and unimportant work from the beginning and deliver what matters most to the customer and the business in the right order.

What is the MoSCoW Prioritization technique?

Developed by the Software development expert Dai Clegg in 1994, The MoSCoW method is a popular prioritization technique that works for any project within a specific time allocated period. The word ‘MoSCoW’ is an acronym that represents four prioritization categories:

• M - Must have
• S - Should have
• C - Could have
• W - Won't have

The word includes ‘o’ characters solely to make it pronounceable. Dai Clegg first used this method to prioritize work in his development teams when he was working at Oracle. Since then, the method has been widely used in many use cases.

How can product teams use the MoSCoW Prioritization technique?

Using this technique, product teams prioritize their items (features, tasks, bug fixes, and new initiatives) into four prioritization categories. The product team can get together, pick each item they have identified that should go in the next release, and discuss which category each of them should ideally be put into.

Before doing this exercise, it is important to have a clear understanding of projects’ objectives and based on what they need to prioritize. For example, should you consider system performance critical for this specific period because you will have a high user load? What are the key areas of the product that provide the most business revenue? Should you consider the teams’ skillset for prioritization, etc.?

Most importantly, they must agree on how many items should be in one category, handling any possible disputes, and how much budget and resources they can allocate for each category. After you agree with each member on these important facts, you are good to start the actual prioritization process. Pick one item at a time and then decide to which category it should belong.

Four categories of Prioritization

Must-have

The Must-have category must include items that ‘must be there for the product. They are usually non-negotiable or obvious that they are critical to implementing. For example, suppose you are developing an online learning and assessment management system. In that case, a student grading system is a must-have component. It is easy to identify such components by asking questions like ‘ if we do not provide this feature in this release, what will happen?”, “Is there a dependency of a particular component with this feature ”? If the answer boils down to the truth that it can fail the entire product or does not provide business value without it, it should be marked as a ‘must-have’ feature.

Should-have

The Must-have category needs to include items that are not as critical as Must-have features. The product can still operate without implementing them, but they provide additional business value or ROI. For example, suppose your product has search functionality and is not that fast, so customers are providing negative reviews. Therefore, you want to further improve its search performance. But without performance, the search still works. However, if you made it fast, you can guarantee great customer satisfaction and a positive impression of your product.

The product teams can ask questions like ‘How many users will be using this feature if we implement it in this release?”, “Do we have the necessary resources and expertise to implement this feature”?. Etc. Also, these are the features you can prioritize for the next releases.

Could-have

Could-have items are things that are not as important as ‘Should-have’ items. For example, suppose you want to integrate a new queue to send messages between another system in your product, replacing the old queue that does not provide many modern features. In that case, though it is not a customer-facing feature, it can affect the customer-facing feature that uses this queue if the time is insufficient to test the whole replacement.

Therefore, those features can be implemented if the team only has additional time and budget to work on them. Without this new replacement, the product is still working as expected, but the additional features you get with the new queue will help the system more resilient than now.

If the teams get many must-have and should-have features, then you can tag these could-have features to future releases.

Won’t have

These are the items that product teams can easily identify and do not add any value to the business and the customer. These are “out of scope” features that do not need to include in the current release or next releases until an important need arises to include them. For example, a minor bug fix does not impact their customer base but only for an internal reporting system. Thus, there is no impact on customers. Hence the product team can decide that this item will not have at this period. This category helps reduce the release's scope if there are capacity constraints.

Conclusion

There are numerous prioritization techniques product teams can use to make the prioritization process valuable and fruitful at the same time. I used to push back on these prioritization categories.; Must have, Should have, Cloud has and won't’ have. What was the difference between Should Have and Could Have? Understanding the original intention helps with the criticality, but I think most people still misunderstand the original intention. So while I don't use this in practice very often, it is popular.

In the end, whatever process allows the product team to ask important questions, assist them in identifying what items belong to each category to prioritize work, and finally eliminating less important work from the current release; is helpful. This method proves simple and easy to follow especially if we have nothing else. Stay tuned for another one in a few weeks!