The Agile Product Backlog For Product Owners

The Product Backlog is a list of the items that need to be developed and changes that need to be made to a product, specified in order of priority. It can include anything from new features to bug fixes to platform improvements. The content and prioritization of this list are the responsibility of the Product Owner, and it is something that evolves over time as work is completed and new requirements are added.

Properties of the Product Backlog

One of the key elements of the Product Backlog is that it must be the single source of truth that the team can refer to. This is why it is vital that it is regularly maintained and kept up to date, and that it doesn’t become cluttered with items that are no longer required.

Another important attribute of the Product Backlog is that each item is given an adequate level of corresponding details relevant to its priority. This means that the features that are at the top of the list should be sufficiently specified to be able to be used for planning and estimation, while those that are of a lower priority need not have as much information, as this might end up being wasted effort if the requirement is never planned for delivery.

Last but not least, although the Product Backlog should be put together and updated collaboratively, and it should be visible to all stakeholders, it remains solely and fully under the ownership of the Product Owner, and any decisions about ordering or content must always be ultimately taken by the person performing this role.

Backlog Prioritization

Backlog prioritization, also known as Product Backlog refinement, is the process of cleaning up the list of requirements and ensuring that everything in it reflects the current reality and state of the changes that need to be made to the product. It usually involves a collaborative session between the Product Owner and the Scrum team, and occasionally other stakeholders. During this session, the participants will discuss the current position of the list and work through various questions that may arise. This meeting doesn’t have to have a formal structure; in fact, different aspects may be addressed at different sessions, depending on what is considered the most valuable use of time at that point. For instance, one such meeting might be used to discuss the relative usefulness of particular requirements and a re-ordering of the items as a result. The following meeting might then be used to delve deeper into some of the user stories, and potentially decide to break some of them up if they are considered too complex to be completed within a single sprint.  

The backlog prioritization meeting serves as preparation for sprint planning. By dealing with questions that may arise before the sprint planning meeting, the intention is that any issues and inconsistencies are clarified ahead of time, thereby reducing the load when it comes to planning. Besides the reduction in time at the planning meeting itself, it also gives the opportunity for the team to spot any missing information that still needs to be gathered, and it allows that data to be retrieved beforehand, rather than only being noticed during the planning and therefore causing further delay.

Recommended Further Reading

The following materials may assist you in order to get the most out of this course: