A sprint backlog is the subset of product backlog that a team targets to deliver during a sprint in order to accomplish the sprint goal and make progress toward the desired outcome.
The sprint backlog consists of product backlog items that the team agreed with their product owner to include during sprint planning. The team owns the sprint backlog and can determine whether new items are added or existing items are removed. This allows the team to focus on a clear scope for the length of the sprint. Some teams may allow the inclusion of a new product backlog item if it replaces a product backlog item of an equal or greater size that already exists on the sprint backlog.
If a team identifies tasks needed to deliver the select product backlog item, those tasks also become part of the sprint backlog. The team can add or remove tasks to the sprint backlog throughout the course of the sprint. The sprint backlog also includes any action items the team identified from the previous retrospective meeting.
The sprint backlog is generally tracked on an information radiator to provide a visual signal of the progress of the team as well as indicate the scope of the current sprint. If the team does not identify tasks, the product backlog items are tracked through different stages of the workflow in a format sometimes referred to as a delivery board. If the team breaks their product backlog items into tasks, they will often use a task board to track those tasks.
The majority of product backlog items included on a sprint backlog are user stories that are appropriately described according to the team’s definition of ready. Other product backlog items could represent bugs that need to be addressed, research that needs to be done (typically in the form of spikes), or changes needed to the architecture or infrastructure of the product.
The sprint backlog only lasts for the duration of a sprint. Each new sprint starts with a new sprint backlog, although the team may choose to add items from the previous sprint’s sprint backlog to the new sprint backlog if those items contribute to completing the new sprint’s sprint goal.
Also Known As
Iteration backlog
Expected Benefits
A sprint backlog provides a team with a clear focus for the short term while a dynamic product backlog provides a mechanism for the team to collect and remember ideas for future consideration. Keeping a stable list of product backlog items in a sprint backlog protects the team from changing priorities and interrupts, at least for a short (usually 2-week) period.
Keeping the sprint backlog visible and showing the progress of items provides the team a way of communicating status without the extra work of creating burndown or burnup charts. A visual representation of the sprint backlog also provides a helpful visual aid for team discussions around current work and what to do next.
The ability to add tasks throughout the course of a sprint allows a team to learn and adjust their plan for delivering their select product backlog items.
Common Pitfalls
Teams can become overly fixated, usually due to outside pressure to complete every item on the sprint backlog at all costs based on the concept that an item placed on the sprint backlog is a commitment to get that item done. The standard of success for a sprint should be whether the team accomplishes the sprint goal. The sprint backlog may need to change through the course of the sprint based on what the team learns as they start working through the sprint backlog.
When Applicable
The sprint backlog is applicable when a team is using Scrum and working in time-boxed sprints. If a team is working in a flow approach (such as Kanban) a sprint backlog is not necessary.
Further Reading
Sprint Backlog Scrum Guide