Anatomy of a Sprint Backlog

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 one and two-week sprint backlog templates, are available for download in MS Excel format.

Download product backlog & sprint backlog templates.

A sprint backlog summary

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

Description: The sprint backlog is a list of the required tasks 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 to include to accomplish the sprint goal. The development team defines the tasks necessary 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. The role 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:

Sprint goal.
User stories to achieve the sprint goal, in order of priority.
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. We’ll explain in detail below.

A. Sprint title and dates

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

B. Sprint goal

The sprint goal describes the objections for the sprint. The goal is a statement 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. 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’re 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.”