The Sprint Backlog is the output of the planning meetings. It is essentially the list of tasks that the team needs to complete during the sprint in order to turn a selected set of product backlog items into a deliverable increment of functionality. Unlike PBIs, sprint backlog tasks have a time-based (hourly) estimate. Since the team is doing the work, they are responsible for keeping the Sprint Backlog up to date.
During a sprint, new tasks may be discovered and tasks already identified may be adjusted. This is perfectly normal behavior. The team simply adds the new tasks (and an estimate of the work remaining on that task) to the sprint backlog or adjusts the wording (and if necessary the estimated work remaining) for tasks in progress. As the team completes tasks, they should be marked on the sprint backlog. The sprint backlog shows team members what is complete and what remains. This data will help team members run an effective daily scrum meeting.
While changes to the sprint backlog are expected, the ScrumMaster should be watching for patterns about the type or amount of work that is added or adjusted. If a pattern emerges, it can teach a team quite a bit about the system as it is built and possibly themselves as a team. The picture below shows a typical sprint backlog. The lines with Work Item IDs are the PBIs. The indented lines underneath each PBI are the tasks associated with completing the feature. One indicator for looking for patterns is through burndown charts.
Looking at the sample sprint backlog below, notice that line item 32 was not originally part of the sprint backlog; it was identified and added on the second day of the sprint. This is evident because the Initial column doesn't have a number and because the data elements for Day 1 are blank. This visual indicator shows the team and the ScrumMaster that this item was added late, on day two specifically.
