In my current blog series on the primary responsibilities of Product Owners, I’ve talked already about the importance of regular communication with the Product Manager and the value of telling stories – specifically of generating user stories that prompt good conversations among the development team members about what users are trying to accomplish. I received some good comments on my blog recently and want to thank those who posted these or contacted me directly.

Here I want to talk about another core responsibility for product owners: tending the product backlog. First, let me define what I mean by a product backlog. In an Agile development environment, the set of features to add and bugs to fix in upcoming sprints is tracked on a product backlog. While a product roadmap gives a larger picture of the overall direction for a product, the backlog provides more detail on specific issues that will be addressed. Ideally each backlog item is tied to a specific user story and outlines a fix or feature that can be developed and tested within a short time period – no longer than a single sprint but at times as short as a single day. As I mentioned in an earlier post, the product owner and product manager talk about translating the near-term items from the product roadmap on to the backlog so that the development team knows what to work on next.

The product owner performs three basic tasks as the one who tends the backlog: adding, prioritizing, and deleting.

1. There are a number of ways that items might get on the backlog: testers might uncover bugs through manual or automated regression testing, coders might add sub-task items as they work on a larger feature, and end users of the product might submit their own requests for fixes or enhancements. But the product owner has the ultimate responsibility to make sure that the right items get put on the backlog – items that fit with the broader plans for enhancing the product. As new items are added to the backlog, the product owner is also (hopefully) making sure that these items are captured as user stories. This is especially true for items added to the backlog by the product owner or by end users themselves; as I mentioned in my last blog posting such items are best captured as user stories (for example, ‘the treasurer needs to know how risky this investment strategy might be’) rather than feature details (for example, ‘add a button at the upper right of the main screen to generate a PDF file with bar charts comparing actual and expected results for the past six months’). In my current firm I try to look through new items that get added to the backlog to make sure that they fit with where the product is headed and that they adequately capture the key information developers will need to plan for and work on the issue.

2. Once items get on to the backlog, the product owner must help the development team prioritize these items. Which story or set of stories should be addressed in the current sprint? What items will be worked on next sprint and might therefore require some initial research and designing in the current sprint? These priorities can be influenced by the product roadmap, the needs of existing customers, dependencies of future work on the efficient functioning of these features, or the availability of the right set of development resources. The responsibility of the product owner is to ensure that the team works on the most important items first rather than allowing them to get distracted by seemingly urgent matters or sidetracked by easy fixes that aren’t really moving the product forward. Both new and mature products often need a balance of regular maintenance and valuable enhancements, and the product owner tends the backlog to be certain that the correct mix of important items are being worked on and planned for each sprint. This kind of prioritizing – along with slotting individual backlog items into groups of related features – is part of what we do in sprint planning in my current firm; my role as product owner involves talking with the product manager about what is being prioritized and helping the development team understand the reasons behind prioritization choices.

3. Because there are a number of ways that items can get added to the backlog, and because the plan for the product evolves as the market itself changes, there are times when the product owner needs to remove items from the backlog that are no longer important. It may be possible for an alert product owner to juggle a set of 100-200 backlog items if each one focuses on a specific piece of user experience. Beyond this the size of the backlog becomes unwieldy and the job of reviewing and prioritizing it regularly stretches the capacity of even the best product owner. Part of tending the backlog means deleting items that are no longer important or that will simply not be worked on for the foreseeable future. Small bugs that were found six months ago and that still have not fixed probably no longer belong on the backlog; if new users discover these issues then fresh stories can be added to the backlog and prioritized more highly. Enhancement ideas that sounded good when first proposed but that have not been added to the prioritized roadmap for the new few quarters of work probably no longer belong in the backlog. Some record might be useful to track ‘product dreams’ that might someday be looked at, but when the product backlog becomes cluttered with such items it no longer serves its purpose and instead impedes the work of the product owner.

The product backlog can be a great tool to help the product owner track current and upcoming development work, prioritizing what is most important and providing a place to add stories about new fixes and features. A cluttered, disordered, and unwieldy backlog hinders the work of the product owner, making it hard for the development team to know what to expect for the future – and no one wants to be surprised by the unexpected like this: http://www.youtube.com/watch?v=vt0Y39eMvpI (Honestly, how long could I keep writing without at least an occasional reference to Monty Python). A good product owner tends the backlog, adding items, prioritizing them, and deleting them as needed to keep the list manageable and useful. I spend time every sprint tending the backlogs for the projects that I work on and so I know the value of these tasks. Of course, in truth it’s not that simple.