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 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.

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

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.