What is a Product Backlog?

Agile product Backlog is a list of new features, changes to existing features, bugs fixes, infrastructure changes or other activities which a team may deliver in order to achieve a particular outcome.

The product backlog is the single authoritative source for things that a team would work on. That means, nothing would get done which is not present in the list of Product Backlog items. On the other hand, the presence of a backlog item on the product backlog would not guarantee that it would be delivered. It would represent an option the team is having before delivering a specific outcome rather than a commitment.

Product Backlog is a single source of requirements for any kind of changes that are to be made to the product. The Product owner would be responsible for the product backlog including its contents, availability, and ordering. A product backlog is never complete. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful. If a product exists, its Product Backlog also exists.

Product Backlog refinement is the process of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team would collaborate on the details of Product Backlog items. During Product Backlog refinement, items would be reviewed and revised.

Multiple Scrum Teams would often work together on the same product. One Product Backlog would be used to describe the upcoming work on the product. A Product Backlog attribute that groups items may then be employed.

Every Scrum Product Backlog would have properties that would differentiate it from the simple to-do list.

• An entry in the Scrum Product Backlog always would add value for the customer.
• The entries in the Scrum Product Backlog are prioritized and ordered accordingly.
• The level of detail depends on the position of the entry within the Scrum Product Backlog.
• All entries are estimated.
• The Scrum Product Backlog is a living document.
• There are no action-items or low-level tasks in the Scrum Product Backlog.

Product Owner responsibilities

In Scrum, always the most important work would be done first. The product Owner would be responsible for managing and determining the order of this work and communicating it in the form of a prioritized list which is known as the product backlog. In the process of developing a new product, the initial product backlog items are the features which are required to meet the product owner's vision. And, for a product that is undergoing the product development, the product backlog might contain changes to existing features, defects, technical improvements and also new features, etc.

The Product Owner would collaborate with both the external and internal stakeholders to collect and define the product backlog items. He would make sure that Scrum activities, product backlog items and artifacts are placed in a correct order. Items can be deleted, added and revised by the product owner as and when the business conditions keep changing. On the whole, the activity of creating and refining the product backlog items, prioritizing them and estimating them would be known as grooming.

Size would equate to cost. Product owner would need to know an item's cost to determine it's priority. In general, many teams would use a relative size measure such as ideal days and story points.

Why is a Product Backlog important?

A product backlog is important due to the following reasons -

• It is prepared in order to estimate each and every feature.
• It would help in planning the roadmap of the product.
• It would help in re-grading the features so that more value can be added to the product.
• It would help in determining what to prioritize first. Team would rank the item and them build value.

Characteristics -

• Each product must have one product backlog which would contain set of large to exceptionally large functionalities.
• Multiple teams would work on a single product backlog.
• Features would be ranked based on the business value, technical value, risk management or strategic fitness.
• Highest ranked items would be broken down into smaller stories during release planning so that they can be completed with future iterations.