The sprint backlog is an essential part of sprint planning. Understand what is a sprint backlog, and how to use it to effectively manage workload during your sprints.
In this page you will learn:
- What is a sprint backlog and why it’s important
- Quick FAQ: everything you wanted to know about the sprint backlog
- 8 tips for making your sprint backlog great
- The missing link between sprint planning and product quality
This article is part of our series on sprint planning – see other articles in the series:
What is a Sprint Backlog and Why is it Important?
The Sprint Backlog is a list of items a Scrum team should complete in the current sprint, including details about how they will be implemented and the effort required to build them. These items are typically user stories—product features which provide value for a user.
The product owner and the Scrum team define backlog items together in a sprint planning meeting, selecting them from a larger release or product backlog, containing “everything” the team will build in the current scope of work. They prioritize backlog items according to the needs of the product owner and the product roadmap. During the sprint, the team builds software to deliver these user stories to users.
Below is an example of a sprint backlog, showing how user stories are broken down into granular tasks, with hour estimates per task per day. User stories can be estimated using hours or story points.
Image Source: Mountain Goat Software
Sprint Blog: A Quick FAQ
Who Owns The Sprint Backlog?
The development team is responsible for sprint backlog management and owns the sprint backlog. The development team should communicate with the product owner if they discover they cannot complete a task.
The daily Scrum is a crucial part of managing the sprint backlog. During the daily Scrum, team members evaluate their work to understand how the sprint is progressing, to enable accurate projection of time remaining. The team should update the backlog, and detailed estimations of tasks, during the daily Scrum.
What is Included in an Effective Sprint Backlog?
An effective sprint backlog must contain all user stories the team needs to address during the sprint. The Scrum master and product owner must break down each item in the backlog into specific tasks and prioritized each task according to the needs of the product owner. It is up to the Scrum master and product owner to make sure the team understands all tasks.
Team members should realistically evaluate their resources and capabilities so they can accurately predict their pace. The team needs to consider their velocity in previous sprints, to assess how many story points they can address during the upcoming sprint. A team can add items to the backlog if needed, but only the product owner can remove items after the sprint planning session has ended.
How Does it Fit into the Agile Development Workflow?
The sprint backlog is an essential part of any Agile project. The sprint backlog is created during the planning stage of the sprint. The team moves tasks from the product backlog into the sprint backlog, according to their estimated velocity. During planning, the team breaks the tasks down into steps.
After the sprint begins, during the daily Scrum, the Scrum Master revises the backlog and receives updates from team members on their progress. Team members can also update others and report any difficulties they encountered. The team can speak to the product owner about the scope of the project, if they encounter obstacles that prevent them from achieving the sprint goal.
Sprint Backlog vs Product Backlog: What is the Difference?
The product backlog is a list of all the tasks and specification required to complete the final product. It is prioritized according to business value and written in a straightforward manner, so both the development team and product owner can easily understand it. The product backlog is modified as work progresses. As the project unfolds, team members can update the estimated time required to complete the release or the entire product.
The sprint backlog is smaller scope and less dynamic than the product backlog. When items are moved from the product backlog to the sprint backlog, they are broken down into more detailed tasks. The team cannot change the sprint backlog during the sprint. At the end of a sprint, the team moves any uncompleted items back into the product backlog.
8 Tips for Making Your Sprint Backlog Great
- Include the entire team—different team members have varying perspectives and inputs, which can benefit the sprint backlog.
- Share decisions—all team members must take part in the planning stage and define how tasks should be addressed during the sprint; this creates joint ownership.
- Definition of Done—every item in the backlog must have a predefined, shared, realistic completion criterion, so all team members know when it is done.
- Include a variety of tasks—it is common to focus on a single area of development during planning (coding for example). A good backlog must address all parts of the project: architecture, coding, UI/UX, testing, etc.
- Team members should assign tasks—you should let team members assign tasks independently so they can learn, communicate with each other and cooperate better.
- Revise commitments based on detailed planning—once the team breaks the sprint goals down into smaller tasks, they should revise their initial commitment to sprint scope.
- The backlog should be dynamic—respond to challenges and opportunities that emerge during the sprint and update the backlog accordingly.
- Update the backlog diligently—update tasks and estimates on a daily basis. Not knowing where your team stands make it impossible to make decisions and makes it much less likely you will meet the sprint goal.
Sprint Planning and Product Quality: The Missing Link
The sprint backlog is an essential component of sprint planning. One thing that is sorely missing from most sprint planning sessions is information about the quality of the product. Is our product of high quality? Which parts have quality issues that need to be urgently addressed? This data is simply not available to most Scrum teams, meaning they cannot factor quality into their sprint backlog and prioritization of work scope.
SeaLights is a Quality Intelligence Platform which collects data about your development project, and produces a test gap analysis report that gives you this missing data. The test gap analysis report helps teams balance new features and maintenance work, by highlighting high-risk code areas:
- Code that has recently changed
- Code that is not tested by any part of the product’s test suite
- Code that is frequently used in production
When teams are aware of product areas that are at high risk of quality problems, they can devote time during a sprint to proactively invest in quality, for example by writing more tests or improving existing tests. This can prevent quality issues in production, which make customers unhappy and also generate a lot of unplanned work for Scrum teams.
To learn more about how to proactively address quality issues and save time in future sprints, read our white paper, Reactive Software Maintenance: The Silent Killer of Development Productivity.