Product Backlog

When you work in a Scrum environment, you will maintain and prioritize a list of all individual work items in order to create, maintain or improve your product. This prioritized list of work is known as a Product Backlog. It is prioritised in the sense that the most important items in terms of business value and risk are listed on top, while the lesser important items are listed below.

It is one of the Scrum artifacts, which is like a to-do list of all the things you need to do and continue doing to meet the product goal. It is also a lot more organic and fluid than a static to-do-list. It is aligned to the product's overall strategy and translates it into working details of creating the product.

It includes new features, changes to existing features, bug fixes, infrastructure changes, wireframes, workflow diagrams, use cases, non-functional requirements or other activities needed for the product. The work is usually described in epics, user stories or tasks. As long as the product exists, the product backlog exists.

A good Product Backlog should be DEEP (coined by Roman Pichler and Mike Cohn). DEEP is a very useful concept to apply during the backlog refinement process and helps keep the backlog maintained.

• Detailed Appropriately
  Items at the top of the backlog must be more detailed compared to the lower items. Generally detailed high-priority items take the form of user stories while less priority items take the form of epics. While creating the user stories one should ideally follow the INVEST concept (Independent, Negotiable, Valuable, Estimable, Small, Testable)
• Estimated
  Items in the backlog must be estimated. The items at the top of the backlog are more precise compared to the items at the bottom. Generally the high-priority items are often expressed in story points while the lower items can be estimated via t-shirt sizing.
• Emergent
  The product backlog is not a static document but is a living document i.e it's content changes frequently. New items are added, existing items are removed, refined, reprioritized based on research, customer feedback, stakeholder feedback, retrospective etc.
• Prioritized
  Items within the backlog must be ranked based on the value they serve. Items at the top are of higher priority and items towards the button are of lower priority.

Who owns the Product Backlog?

The product owner owns the product backlog. They are responsible for managing, prioritizing, updating, and maintaining the backlog. However, backlog grooming is a result of product teamwork.

Difference between Product Backlog and Product Roadmap

The product roadmap helps fill in the product backlog i.e the roadmap tells us ‘where we want the product to go’ while the backlog tells us ‘how to get there’. The roadmap focuses more on high level themes like customer satisfaction, increased conversions, better seller experience etc while the backlog details out the tasks (users stories) of how and what is needed to be done to achieve those themes.

The roadmap is more like a strategic document mainly intended towards stakeholders, executive teams etc while the backlog is more tactical document mainly for product development teams. However, both documents must be visible and easily accessible for stakeholders and the product team.

Difference between Product Backlog and Sprint Backlog

Both the product and sprint backlog are key artifacts of Scrum. However they differ.

The product backlog is a list of all the items that is required to be done to help fulfil the product vision. It is owned and managed by the Product Owner. It is a constantly evolving document and the Product Owner keeps updating it through the product development lifecycle. A product backlog grooming meeting is held to refine it. The estimation of the product backlog items are at a story level.

The sprint backlog is a list of all items that is needed to fulfill the sprint goal. It is a subset of the product backlog. During the Sprint planning meetings, the team pulls items from the product backlog to be worked on in the sprint. It is owned and managed by the development team. The estimation of the sprint backlog items are done at a task level.

No changes are allowed to the sprint backlog items once the sprint has started. At the end of a sprint, the development team moves any uncompleted items back into the product backlog.

Benefits of Product Backlog

Cross-functional teams can quickly adapt to the changing needs of their customers. Items are re-prioritized, removed, modified etc which allows the team to adjust their process to align with new priorities. As new requirements are gathered or submitted, they are inserted into the backlog at the position that best represents their business value with respect to requirements that have already been entered.

Product backlog facilitates healthy discussion amongst cross-functional teams. Items are discussed, and the team understands any interdependencies or conflicts items may create.

The team knows where they need to go to search for what work needs to be done next and in which order and priority as the tasks are already written down.

Some key points to remember on Product Backlog

• The backlog must be constantly evolving along with the product i.e as the product evolves to better suit the customer needs and stakeholders preferences, the backlog must be updated to reflect these changes.
• The product owner must understand and communicate to the team regarding how the different items in the backlog relate to each other. He needs to constantly collaborate with the development team and stakeholders.
• You must conduct a backlog grooming session so that the items within the backlog can be reviewed and monitored. This will ensure that all the items within the backlog are contributing towards meeting the overall product goal.
• Prioritise items in the backlog so that the team knows what is the next list of items to be worked on once the sprint is over.
• Avoid making changes to items once they are being worked on by the development team. If any changes need to be done, create a new item and add it to the backlog which then can be picked up in the next sprint.
• Don't create multiple backlogs ideally there should be just one source of work for the development team.
• Follow a 20/30/50 rule if possible i.e 20% of the items are ready for the team to pick up in the next sprint, 30% of the items have enough information, though further details need to be added, 50% of the items need discussions.

Conclusion

When created and managed correctly, the backlog helps the cross-functional team to reach peak productivity, navigate constant change and deliver maximum value to both the business and the customer. You must regularly groom it so that the entire cross-functional team is aligned to working towards a common set of strategic goals. Keep it transparent and reasonably sized. Avoid getting into details of lower priority items. When it comes to product backlogs, it’s simple: you should manage it like it’s a product!