As part of our series on Scrum Artifacts, this article covers the Sprint Backlog. In it, we will discuss what it is, the purpose it serves, how it is created and managed and how different roles in the Scrum Team interact with it. We will also address the most commonly asked questions about the Sprint Backlog.
So, what is a Sprint Backlog?
The Sprint Backlog is a Scrum Artifact which contains the Product Backlog items pulled into a single Sprint, as well as the plan for the work needed to deliver a usable product Increment. It is a transparent artifact which shows all of the work the Development Team decides is needed to realize the agreed-upon Sprint Goal. A recent update of the Scrum Guide also introduces at least one high priority process improvement as part of a Sprint Backlog.
The Sprint Backlog is not a commitment set in stone and, instead, represents a forecast about the functionality that will be added to the Product as a “Done” Increment over the course of the single Sprint.
Sprint Backlog Helping the Team
The Sprint Backlog is essential for working in Scrum and there are a number of ways in which it helps the Scrum Team deliver value.
For one, the Sprint Backlog provides the Development Team with a plan to complete the Product Backlog items chosen for the Sprint. At the Sprint Planning meeting (more on this later), the team will come up with this plan which will help them deliver the Increment in a sensible, efficient fashion.
It also supports a unified approach to realizing the Sprint Goal as work needed to complete Product Backlog items is broken down and interdependencies are worked out. This prevents the Development Team from doing something twice or skipping crucial steps only to find out they did a ton of work in vain.
The Sprint Backlog is detailed enough to enable the Team to identify the changes in progress at Daily Scrum meetings and communicate any potential discrepancies between what was estimated at the Sprint Planning and what the Team will be able to deliver by the end of the Sprint. This allows the Scrum Team to predict future delays as soon as possible and to take the best course of action.
The Scrum Guide also states that the team should include a single high-priority process improvement in the Sprint Backlog, addressing issues that were discovered at the last Sprint Retrospective. This ensures that the team actively works on improving their process and growing as a unit.
Creation of the Sprint Backlog
At the Sprint Planning meeting, the Product Owner suggests and discusses with the team the objective that the upcoming Sprint should achieve, as well as the Product Backlog items whose completion would help meet the Sprint Goal. The entire team then discusses the suggested Product Backlog items, but it is the Development Team which decides how many of them to pull into the Sprint. The Sprint Goal is also defined at this point, by the entire Scrum Team.
Once the above is done, the Development Team will start working out how to build the agreed-upon functionality and make the selected Product Backlog items “Done”. The first few days of the Sprint will be worked out in detail. The rest of the plan will be detailed enough to enable a forecast, but it should be enabled to grow organically as the Sprint progresses.
Some teams will use additional agile Sprint planning tools and techniques that they have adopted over time and that help them with building their Sprint Backlog, like for example, various estimation techniques like Planning Poker.
Updating the Sprint Backlog
As the Sprint goes on and the team learns new information, it will regularly update the Sprint Backlog. New items will be added to it and those identified as unnecessary will be removed. The team consults and updates the Sprint Backlog throughout the Sprint, keeping a watchful eye over the Sprint Goal and whether they will be able to complete the Product Backlog items they chose for the Sprint.
If the Team determines that newly discovered information dramatically changes what will have to be done within the Sprint, they will discuss changing the scope of the Sprint and the Sprint Backlog with the Product Owner.
Finishing the Sprint
Many people, especially those new to Scrum feel that the goal of every Sprint is to complete all of the items in the Sprint Backlog. This is simply not the case and focusing on rushing the planned items just for the sake of clearing the Sprint Backlog can actually be detrimental to the Increment and the product as a whole.
At the end of the Sprint, the team has to deliver an Increment that will be usable and in adherence to the team’s Definition of Done. Usually, this will require the majority of the Sprint Backlog items to be completed, but this does not necessarily mean absolutely everything has to be done.
The Sprint Backlog is not a simple to-do list.
Sprint Backlog items that have not been completed within the Sprint will be returned to the Product Backlog and considered for the next Sprint by the Product Owner. If you want to read more about unfinished Sprint Backlog items, this is a great discussion.
Sprint Backlog FAQ
What is a Sprint Backlog?
The Sprint Backlog is the sum of the Product Backlog items that the Development Team pulls into the Sprint, plus the plan for working on those items. It is a Scrum artifact which ensures transparency of work during the Sprint and enables constant inspection and timely adaptation.
What is the main purpose of the Sprint Backlog?
The main purpose of the Sprint Backlog is to provide the Scrum Team (and other stakeholders) with full transparency of the work being done during the Sprint. This transparency, in turn, allows for continuous inspection and timely adaptation, as well as for tracking the progress of the Sprint and estimating whether the Increment will be “Done” by the end of the Sprint.
What is included in the Sprint Backlog?
The Sprint Backlog includes the Product Backlog items that the Development Team agreed to complete within the Sprint, the plan for doing this (including discovery work, tasks, improvements, etc.) and at least one process improvement. All new work that is identified as necessary throughout the Sprint is also added to the Sprint Backlog.
When is the Sprint Backlog created?
The Sprint Backlog is created at the Sprint Planning. However, it is not created as an exhaustive task list that is set in stone for the entire Sprint. The Sprint Backlog is continuously updated and modified throughout the Sprint in response to new circumstances and the work that has already been done.
How much of the Sprint Backlog must be defined during the Sprint Planning meeting?
At the Sprint Planning meeting, the team will define which Product Backlog items will be worked on during the Sprint. In addition to this, the Development Team will formulate a plan for the first day or two of the Sprint. The team will not define all of the work that will be done within the Sprint at the Sprint Planning meeting. If the team wishes so, they can use agile Sprint Planning tools that will help them with this process.
Who owns the Sprint Backlog?
The Development Team owns the Sprint Backlog. They create the Sprint Backlog at the Sprint Planning meeting and they are the only people who can make changes to it throughout the Sprint.
What should a team do with Product Backlog items they choose to bring into the sprint?
The team will break down the Product Backlog items into units of work that can be completed within a day. At the Sprint Planning, the team formulates a detailed plan for the work they will do in the first few days of the Sprint and the rest is broken down as the Sprint progresses and new information emerges.
Who is allowed to change the Sprint Backlog during the Sprint?
No one except for the Development Team is allowed to change the Sprint Backlog during the Sprint. The Product Owner can approach the Development Team and negotiate adding new work to the Sprint Backlog, but the final decision is always the Dev Team’s.
During a Sprint, when is new work or further decomposition of work added to the Sprint Backlog?
The Sprint Backlog is a dynamic artifact that is constantly being updated and modified by the Development Team. The team continuously breaks down the work needed to complete Product Backlog items instead of doing this at the Sprint Planning. This ‘just in time’ approach reduces the amount of waste in the process and ensures the team defines tasks only when it has all the pertinent information which is often not available before or at the start of the Sprint.
When does a Development Team member become the sole owner of a Sprint Backlog item?
Never. The Development team is the sole owner of the Sprint Backlog and all of its items. The fact that one person did all the work on a single item does not mean they become the owner.
What determines how the team knows when a Sprint Backlog item is done?
Every Scrum Team will define its own Definition of Done which will be applied to determine whether a Sprint Backlog item is done.
Author: Goran Prijić is the co-creator and Product Owner at VivifyScrum. He is also a Certified Scrum Master.