This video is part of our 19-part Scrum Foundations video series. Click here to watch the rest of the series for free.
The sprint backlog is a list of tasks identified by the Scrum team to be completed during the Scrum sprint. During the sprint planning meeting, the team selects some number of product backlog items, usually in the form of user stories, and identifies the tasks necessary to complete each user story. Most teams also estimate how many hours each task will take someone on the team to complete.
It's critical that the team selects the items and size of the sprint backlog. Because they are the people committing to completing the tasks, they must be the people to choose what they are committing to during the Scrum sprint.
The sprint backlog is commonly maintained as a spreadsheet, but it is also possible to use your defect tracking system or any of a number of software products designed specifically for Scrum or agile. An example of a sprint backlog in a spreadsheet looks like this:
| User Story | Tasks | Day 1 | Day 2 | Day 3 | Day 4 | Day 5 | ... |
|---|---|---|---|---|---|---|---|
| As a member, I can read profiles of other members so that I can find someone to date. | Code the… | 8 | 4 | 8 | 0 | ||
| Design the… | 16 | 12 | 10 | 4 | |||
| Meet with Mary about… | 8 | 16 | 16 | 11 | |||
| Design the UI | 12 | 6 | 0 | 0 | |||
| Automate test… | 4 | 4 | 1 | 0 | |||
| Code the other… | 8 | 8 | 8 | 8 | |||
| As a member, I can update my billing information | Update security tests | 6 | 6 | 4 | 0 | ||
| Design a solution to… | 12 | 6 | 0 | 0 | |||
| Write a test plan | 8 | 8 | 4 | 0 | |||
| Automate tests… | 12 | 12 | 10 | 6 | |||
| Code the… | 8 | 8 | 8 | 4 |
During the Scrum sprint, team members are expected to update the sprint backlog as new information is available, but minimally once per day. Many teams will do this during the daily scrum. Once each day, the estimated work remaining in the sprint is calculated and graphed by the ScrumMaster, resulting in a sprint burndown chart like this one.
The team does its best to pull the right amount of work into the Scrum sprint, but sometimes too much or too little work is pulled in during planning. In this case, the team needs to add or remove tasks.
Let's take an example using the sprint burndown chart above. As you can see, the team in this scenario pulled in too much work initially into the sprint backlog, and still had nearly 600 hours to go on day 13 of a 20-day sprint. The product owner was consulted and agreed to remove some user stories from the sprint. This resulted in the big drop on the chart between days 13 and 14. From there, the team made consistent progress and finished the Scrum sprint successfully.