Sprint Backlog

The sprint backlog is the list of tasks identified by the Scrum team during sprint planning. During sprint planning, 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 is critical that the team selects the items and size of the sprint backlog. Because they are the ones committing to completing the tasks they must be the ones to choose what they are committing to.

The sprint backlog is very 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:

During the 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 sprint but sometimes too much or too little work is pulled in during the Sprint planning meeting. In this case the team needs to add or remove tasks. In the above sprint burndown chart you can see that the team had pulled in too much work initially and still had nearly 600 hours to go on 5/16/02. In this case the Product Owner was consulted and it was agreed to remove some work from the sprint, which resulted in the big drop on the chart between 5/16/02 (619 hours) and 5/17/02. From there the team made good consistent progress and finished the sprint successfully.