Featured

A Nerd’s Guide on Sprint Backlog and Product Backlog

Sprint Backlog is a list of product backlog items selected for inclusion in a sprint, where product backlog items can be thought of as product requirements. The product owner is responsible for ensuring that the product backlog is visible to everyone—to team members, stakeholders and anyone else who is interested. The product owner also ensures that it’s clear which product backlog item the team should work on next.

The Sprint Backlog shows at a glance what will be done this sprint and who will do it. It consists of ready-for-work product backlog items from the product backlog, with enough detail so that team members understand what they are supposed to build. In addition, it classifies each item as “Done” or “Not Done”.

At the beginning of a sprint cycle, product backlog items are brought into the Sprint Backlog, usually by product owners or product backlog refinement sessions. As the sprint plays out, team members take product backlog items from the product backlog and decide how much of each item they can commit to complete in the upcoming sprint. They assign a value to each product backlog item in points—ideally derived during product backlog refinement—which roughly estimates the amount of work required to complete that item. These point assignments are added up for an overall total representing how much will be accomplished in this sprint against the product backlog as a whole.

At the end of a sprint cycle, team members assess their efforts against what has actually been delivered versus what was committed to at the beginning of that time period. After such an assessment, product backlog items that were completed ahead of schedule or that the product owner has just decided to pull out of the product backlog can be removed from this current product backlog.

Scrum utilizes a product backlog as one of its core artifacts and it is developed by the product owner and/or stakeholders who collectively analyze and prioritize it. The first step (Product Backlog Refinement)in product development is to create the initial product backlog on which ongoing sprints later build upon. Product backlog refinement is about working with customers and other stakeholders to elicit, discuss, and capture all their expected value for a product such as features they want in a new mobile phone or improvements they want made to a mobile device application.

The idea of product backlog was first introduced by Ken Schwaber and Jeff Sutherland in the early days of Scrum as a method to develop a product on a date ordered list prioritizing product development. As Scrum evolved, this list became more formalized.

In product creation using Scrum, there is no project manager or product owner who owns the sprint backlog, who does not have direct access to the customer whose interests are represented by product backlogs. The product owner maintains the product backlog as a single source of information for managing all aspects of product planning and making trade-offs between scope, schedule, and resources for each sprint. He/she makes sure that it represents just enough work for one sprint at any moment in time. It holds items that will be worked on during the next sprint. It does not contain items which are now in development, or completed, it is a product backlog until they enter the product backlog for the next sprint.

The product owner ensures that the product backlog is visible to everyone and shows how it will be prioritized by using techniques like sorting, ranking, or scoring of product backlog items against specific criteria (such as business value). The product owner also prioritizes the product backlog so that when there are multiple items in different categories, the most important item can be selected first for immediate work in software product development methodology.

A product owner may represent just one person or a group of people such as the customer, an investment committee, or company management. Because this role reports to various stakeholders in various organizations with various agendas, product owners must be able to communicate product backlog priorities effectively.

A product owner is responsible for maximizing the value of the product and the work of the development team. How product owners accomplish these goals may vary widely across organizations, Scrum teams, and individuals. Product ownership is often required within an organization but not always part of a product owner’s formal job description. The product owner role works in tandem with the scrum master to establish rules that guide how a product backlog is managed throughout a sprint. In most cases, a product owner will require help from other people who have strong domain expertise or “expert power” to represent stakeholders and validate requirements during prioritization activities. This helps ensure team members understand their stakeholders, and product management can obtain stakeholder feedback on product backlog items (PBIs) selected for the sprint.

Stakeholders can be product owners, product managers, marketing managers, market researchers, business analysts or anyone else who might have an interest in a product. The product owner represents the product’s stakeholders and is accountable for ensuring clear communication between them and the development team. A product owner will not directly tell the development team what to do but instead must work with other stakeholders to determine PBIs that will help realize value for both product management and users or customers of a product. The product owner helps ensure that features in a sprint backlog align with strategic goals while considering feasibility so they can be successfully developed within time constraints.