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:
- What does the Product Backlog contain?
- The shape of the Product Backlog
- Product Backlog Improvement
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.
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.
- Glossary of basic terms, roles and notions
- What is Scrum?
- Scrum values
- How to implement Scrum in your company?
- Scrum Team - what is it and how does it work?
- Who is a Product Owner?
- The most common mistakes of Product Owner
- Who is the Scrum Master?
- Characteristics of a good Scrum Master
- The most common mistakes of Scrum Master
- What statistics and metrics should the Scrum Master track?
- Cooperation between Product Owner and Scrum Master
- Development Team in Scrum
- The most common mistakes of Developers
- Scrum artifacts
- Scaling Scrum
- Sprint Backlog
- What is the Product Backlog?
- What are User Stories?
- Creating the best User Story with INVEST
- The most common User Story mistakes
- User Story Acceptance Criteria
- Estimation and Story Points in Scrum
- Planning Poker
- Team Estimation Game
- Defining Increment
- Scrum events
- What is Sprint in Scrum?
- Scrum Team Commitments - Product Goal, Sprint Goal and Definition of Completion
- What is a Burndown Chart?
- How to create and interpret a burndown chart?
- Advantages and disadvantages of the burndown chart
- Kanban boards in Scrum and Scrumban
- Velocity in Scrum - Speed of the Development Team
- Daily Scrum
- Sprint Planning
- Sprint Review
- What is a Sprint Retrospective?
- Common mistakes during a Sprint Retrospective
- Product Backlog nurturing