Tag Archives: value
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 
have, 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.
Building a Product Owner – Existing Backlog
Product Owners – like great products – must be developed. While some skills are innate, others must be learned and organizations tend to throw new Product Owners into the mix without adequate information. In this blog series, we have explored new product owners who are assigned to new products and those owning a system migration. Now we are going to explore a new product owner who takes over an existing product with a robust product backlog. In some respects, one might think this is the easiest of the three scenarios but it comes with its own set of challenges. Here are some tips for how to get started.
1. Get to know your customers
The first step to get your arms around an existing backlog is to understand your current customers. To do this, you need both
Backlog in Jira Agile
qualitative and quantitative information. Data is always your friend. How many customers do you have? Are they profitable? Are they the ideal customers that you want to attract? Once you understand the numbers, now you need to actually talk to customers. Schedule interviews with key customers – both happy ones and those that are frustrated. Use your strong product management skills by asking open ended questions. My favorite is “What keeps you up at night?” Let your customers talk or complaint or suggest – wherever the conversation goes can be valuable. Knowing who is buying your product is very important.
