Blog

Anatomy of a Sprint Backlog

August 10, 2016

Platinum Edge developed a simple and useful product backlog and sprint backlog template for our students and clients. Several product backlog templates, as well as both 1- & 2-week sprint backlog templates are available for download in MS Excel format:

Download product backlog & sprint backlog templates

If you are not familiar with the sprint backlog, here is a summary:

Description: The sprint backlog is a list of the tasks required for a scrum team to create potentially shippable functionality to accomplish a sprint goal. The sprint backlog is one of the three scrum artifacts, and it exposes progress of the sprint.

Who:

  • The development team owns the sprint backlog and determines which product backlog items are included to accomplish the sprint goal. The development team defines the tasks required to turn each sprint backlog item into working, potentially shippable functionality.
  • The product owner establishes the sprint goal and provides clarification to the development team as they create the sprint backlog.
  • The scrum master facilitates creation of the sprint backlog during sprint planning, and also facilitates interactions and removes impediments during execution of the sprint backlog in the sprint.

When: Created during sprint planning, and updated continuously throughout the sprint.

At a minimum, a sprint backlog should include the following elements:

  • The sprint goal
  • User stories to achieve the sprint goal, in order of priority
  • The tasks necessary to complete each user story
  • A burndown chart showing the amount of work remaining to complete the tasks

Here is our one-week sprint template. Each of the areas labeled are explained in detail below.

A. Sprint title & dates

Replace the terms in brackets to reflect the specifics of your project.

B. Sprint goal

The sprint goal is an overall description of the goal for the sprint, stated in terms of functionality the customer will have at the end of the sprint that is potentially shippable.

C. Available working hours in the sprint

  • The list of developers on the scrum team
  • The number of working hours per day of the sprint for each developer
  • The total number of working days in the sprint (adjusted by half-day per week of the sprint to account for sprint meetings)
  • The total number of hours each developer has available during the sprint
  • The total number of hours in the sprint available for the development team

These cells determine the total number of hours available in the sprint (represented by the red line in the burndown chart).

D. Burndown chart

The burndown chart graphically shows the development team's progress.

  • Hours remaining are displayed on the left vertical axis. Story points remaining are displayed on the right vertical axis. X-axis refers to the day of the sprint.
  • The red line shows the even burndown of available hours
  • The blue line tracks the actual burndown of hours as the developers update remaining time to complete each task at the end of each day. Ideally, the blue line snakes around the red line. Blue line above the red line indicates behind schedule. Blue line below the red line indicates ahead of schedule.
  • The green line displays the burndown of story points as sprint backlog items are accepted by the product owner.

E. List of user stories, estimates, tasks and responsible developers for each task.

Here, we have each user story title with its corresponding tasks under each user story. Story point estimates are in column B, and the name of the developer working on each task is in column C.

F. The days of the sprint and hours remaining for tasks

At the end of each day, development team members enter the remaining hours for the tasks they are working on in the column for the following day, until the task's remaining hours are zero.

G. Done column.

When all remaining hours for the tasks of each user story are 0, the “Done” column displays “Y” to signal the product owner to accept or reject it.

H. Accepted column.

Entering “Y” means the product owner accepts the user story and the burndown chart green line updates. If the product owner enters “N,” then the development team adds tasks to fix the reason it was rejected until the product owner accepts it and enters “Y.”

I. Remaining hours & story points

These rows provide the calculations to generate the burndown chart.

J. Issues

Impediments are listed here and the scrum master makes sure they get removed.