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!

Join us at one of our upcoming workshops!

In our CSPO and A-CSPO workshops, we spend quite a bit of time going over some prioritization techniques as well as hands-on use of them in the workshop.

Register Now!

Related Articles

Prioritizing with the Kano Model

Welcome! (or welcome back!). As promised we discussing a series of topics related to prioritization techniques. This one is definitely in my top 10 when working with my clients as well as being a Product Owner myself. Often our stakeholders have what I like to call "opinion data". I certainly...

Read More

How a Product Owner is Like a Business Owner

If you’ve ever wanted to own a business or think like a Chief Financial Officer (CFO), being a product owner has many similarities. A good product owner has to think carefully about how to spend money and what kind of return on investment she’ll get. In most companies, we forget...

Read More

How To Lead Innovation Workshops

As a product owner, it’s important that you’re always leading the team through product innovation ideas or your product can quickly become stale and boring! Without true innovation, your team just builds and builds, but doesn’t get to use their brains creatively, which can stagnant product innovation. In this article...

Read More

Stakeholder Identification and Management

Bringing the right stakeholders together and effective stakeholder management are essential requirements for leading a project to success. In Agile/Scrum, how can we identify the right stakeholders and ensure we are informing them at the rate/type of information they want?. This article attempts to answer these questions by discussing how...

Read More

Impact mapping: Business goals to product backlog

Are you struggling with how to create your product backlog? You have a business goal but you are still unsure how to continue? Let me introduce you to impact mapping and why this is beneficial for building a backlog based on your business goals in no time. Impact mapping is...

Read More

Reach-Impact-Confidence-Effort (RICE)

Welcome back (or just welcome) to our series on prioritization techniques. As I work with teams and organizations, I notice a huge component of planning missing in their endeavors; prioritization. I often say that a Product Owner's job is to maximize the amount business value delivered of a Scrum Team...

Read More