Prioritization – Part 2: MoSCoW and Risk-Value

As introduced in the first blog, prioritization is difficult.  The first and most important question is “should we do this at all?”  Once you determine that an effort is worth doing, we have to figure out where it falls relative to the other things in the queue.  There are a number of tools that we can use in this effort.

MoSCoW

The first tool in our arsenal is from Dynamic System Development Method (DSDM) and it is an acronym for Must have, Should have, Could moscow_blog2have, Want.  The technical definition for each category is as follows:

Must have: all features classified in this group must be implemented, and if they are not delivered, the system would simply not work.

Should have: features of this priority are important but can be omitted if time or resources constraints appear.

Could have: these features enhance the system with greater functionality, but the timeliness of their delivery is not critical.

Want to have: these features serve only a limited group of users and do not drive the same amount of business value as the preceding items.

To put MoSCoW  in action, we pull a reference from our book, Introduction to Agile Methods.  In this example, we are looking at the payment methods that could be offered on a new eCommerce site.

Must have: ability to accept Mastercard and Visa

Should have: add American Express and Discover

Could have: add ACH payments for transactions directly through banking institutions

Want to have: add gift cards

By understanding where each feature falls relative to the MoSCoW parameters, the prioritization is much easier.

Understanding Risk

I have learned so much from Mike Cohn and the Risk-Value Relationship is another example.  From his book, Agile Estimating and Planning, Mike provides a thought-provoking idea about factoring the level of risk into the prioritization.  Mike suggests that you should always work on the Highest Value items first and that makes sense.  Whatever will deliver the most value to the organization – could be increased revenue, decreased costs, an improved user experience, etc. should be the highest priority.  Then he goes on so say that if you have two high value items and one is high risk and one is low risk, you should work on the high risk item first.  This may seem counter-intuitive initially, but it makes good sense when you think about it.  The high risk items probably have the most variability and may contain surprises.  Let the team dive into those items early in the project when you have the ability to pivot.  If you hold the high risk items until you are well into the project, you may find an unpleasant surprise and you may lack the time or flexibility to adequately deal with it.  I love this idea because it challenges conventional thinking.  Most people will instinctively shy away from a high risk item, but Mike suggests that you tackle it early.  Confronting the unknown demystifies it and allows you deal with whatever is learned in a constructive and logical manner.  Agile does not like surprises and a high risk item may be full of them.  Prioritize high risk items to the top of the list and you can easily manage them.

MoSCoW and the Risk-Value Relationship are two excellent tools to use in the prioritization process.  The next blog  focuses on the Kano Model and how it can be used to bring clarity to the difficult task of deciding what to work on first.  Thank you for reading this blog and I hope you found the information helpful.

Photograph from: http://adiamondinmoscow.com/

2 Responses to Prioritization – Part 2: MoSCoW and Risk-Value

  1. One thing that can help with prioritization is to prioritize the use cases and associated acceptance criteria before looking at features that will realize those use cases. It ensures you anchor your prioritization decisions in what provides value to the user and customer.

    Delivering value to your organization may be the end goal, but you have to deliver value to your customers to have a successful product and organization.

  2. I had never heard of MoSCow before I heard you present on this at Des Moines Agile Day. I can see how MoSCoW can really help determine where requests and priorities are in relation to each other.

    That is interesting what Mike Cohn has to say about the high risk items, “The high risk items probably have the most variability and may contain surprises. Let the team dive into those items early in the project when you have the ability to pivot. ” I understand what he is getting at here, but I have also heard others state the importance of getting “quick wins” so the team can build confidence.

Leave a Reply

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