Backlog Prioritization is Not for the Feeble Minded

Updated: Feb 16

Knowing what to work on with your product lines has become increasingly important in the age of metrics, data and constant feedback. The reality is that nothing quite replaces the ability to read between the lines and try many small samplings of what may work well and satisfy the customer, especially when comparing to that of a big bang approach with all the chips on the line. Let’s dive into what are some examples used by Product Owners on prioritizing Product Backlogs to see what does and doesn’t work well.

product backlog

Get the Whole Picture Visible

Determining what you want to work on suggests you have a picture of the whole solution or list of items to be included in the solution. Even if the list seems insurmountable, pull it together in one spot as this will ultimately help with the next steps we are going to go through. Lee Henson, President and CEO of AgileDad, recently reviewed an article written by Janna Bastow where the topic was “How to Clean Up a Big Messy Product Backlog”. You can listen to his thoughts here on this article HERE.

I echo the thoughts of Janna and Lee that it is important to know what you are potentially going to work on by getting all your items into one repository. The specific repository is not as important as the usability of that information for the audience that is going to be prioritizing it. As an example of this process, I vividly remember a Scrum Master I worked with several years ago helping her Product Owners accomplish this with outstanding defects and bugs to be triaged in what was a seemingly endless list of ‘could be done” items. The process was altogether very simple and looked a little bit as follows: