This article looks to discuss ‘What is a Product Backlog?’ and looks to focus on the Product Owner role within the Product Backlog processes.

The Agile Fundamentals

A 59 Seconds Agile Video Animation

The Agile Manifesto with 59 Seconds Agile

What is a Product Backlog to the Product Owner

A 59 Seconds Agile Article

The Product Backlog is a list of the items that need to be developed. It also includes 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. It is something that evolves over time as work is completed and new requirements are added.

What is a Product Backlog? Properties of the 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. Those that are of a lower priority need not have as much information. These items may end up being wasted effort if the requirement is never planned for delivery.

What is a Product Backlog? A Collaborative Effort

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 any decisions about the ordering or the content must always be ultimately taken by the product owner.

59 Seconds Agile - Agile Product Backlog — 59 Seconds Agile – Agile Product Backlog

What is a Product Backlog? Product 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. It provides a 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. Additionally it allows data to be retrieved beforehand, rather than only being noticed during the planning. Thus reducing any further delays.

Prev <— Continue Reading —> Next

Learn More: The Agile Fundamentals

Learn More

User Stories Applied

A 59 Seconds Agile Book Review

User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.