What is the Product Backlog? The shape of the Product Backlog

The Product Backlog is the only source of tasks performed by the Scrum Team. It is a list of planned Product functionality and enhancements. Its shape is changeable and not all tasks included in the Product Backlog will be completed. It evolves during discussions with Stakeholders. It is also constantly improved. It means that the closer to the deadline the more detailed a task becomes.

What is the Product Backlog? – table of contents:

Introduction
What does the Product Backlog contain?
The shape of the Product Backlog
Product Backlog Improvement
Summary

Introduction

Product Backlog is the largest of the Scrum Artifacts. It reflects the status of work on a Product concerning the Product Goal. On the other hand, when the work on a Product is completed, its Backlog becomes a complete list of the tasks done by the Scrum Team to create the Product. However, it does not contain detailed technical solutions.

What does the Product Backlog contain?

Product Backlog is created during the Product Owner’s meetings with Stakeholders. The Product Owner is the sole owner and the person responsible for this source of tasks.

Business language characterizes the entries in the Product Backlog. In other words, they describe the value of the Product from the Stakeholders’ point of view.

Task descriptions included in the list of tasks need coherence and clarity. They contain functions and improvements of the Product usually presented in the form of User Stories to which we devote a separate entry. Here we will only mention that these are descriptions of partial functionalities of the product answering the questions about the following issues:

The scope of Product modifications
The purpose of modifying the Product
The type of user for whom this modification comes up

The shape of the Product Backlog

The order of tasks included in the Product Backlog changes as the Product develops. While working on it, the Scrum Team shapes and enhances its functionalities. Upon encountering obstacles, its implemented actions allow all to think about and define future adequate solutions, and these will too change accordingly to unforeseen further obstacle. Therefore, there is no clear and defined order of actions, all is changeable. Product Backlog improvement is aimed at its continuous updating and preparation for the next tasks. For this reason, it is continuous.

Tasks with a distant deadline are typically large, generic wholes. Their description does not contain details, but only an outline of functionality that should be realized. It is also possible to find tasks among them that will never terminate.

Entries in the Product Backlog may present alternative solutions. And also the Customer’s ideas which may become outdated, unprofitable or for some other reason never enter the implementation phase. That is why the Product Backlog is sometimes jokingly called the “Customer’s wish list”.

Another reason for changes in the shape of the Product Backlog is redefining solutions. Sometimes it turns out that a certain problem has already been solved while creating another product functionality. Or the expected functionality has become redundant due to changes in other solutions.

One of the basic activities during the Product Backlog improvement is dividing the tasks contained in the Product Backlog into parts. Thanks to this, the general outline of functionality is presented in the form of smaller, more detailed and precisely defined units.

Tasks designed for closer implementation become more detailed. They also become smaller, containing details of solutions. Details emerge during Product development. And thanks to the knowledge of the current state of the Product and the current expectations of Stakeholders, the Product Owner complements the upcoming tasks with their description, order and size. Then, selects the best-described tasks for the next Sprint Backlog.

Product Backlog Improvement

While working on a Product, the Product Owner modifies and details the Product Backlog in cooperation with the Development Team. Following the Product Owner’s suggestions, during Sprint Planning the team selects features to implement from the Product Backlog. They are then moved to the Sprint Backlog and divided into tasks to be completed. The tasks moved to the Sprint Backlog are described in technical language, which is the most useful for Developers.

Task size is an important metric from the Development Team’s point of view. Its proper estimation becomes especially critical when selecting User Stories from the Product Backlog to the Sprint Backlog.

The Development Team learns over time to correctly estimate the time and effort required to complete a specific User Story. This is expressed in days, man-hours, or Story Points and provides an estimate of a value called Team Velocity.

Summary

The Product Backlog is a continually improved list of tasks leading to the Product Goal. The content of the Product Backlog is usually expressed in the form of User Stories. And the shorter the time remaining to complete a task, the:

The job description is more detailed
The scope of the task is smaller
The scope of the task is better defined

The Scrum Team takes care of the tasks. The Product Owner manages and modifies the Product Backlog.

If you like our content, join our busy bees community on Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Author: Caroline Becker
As a Project Manager, Caroline is an expert in finding new methods to design the best workflows and optimize processes. Her organizational skills and ability to work under time pressure make her the best person to turn complicated projects into reality.
View all posts