The sprint backlog
Overview
From Wikipedia:
The sprint backlog is a document containing information about how the team is going to implement the features for the upcoming sprint. Features are broken down into tasks; as a best practice, tasks are normally estimated between four and sixteen hours of work. With this level of detail the whole team understands exactly what to do, and anyone can potentially pick a task from the list. Tasks on the sprint backlog are never assigned; rather, tasks are signed up for by the team members as needed, according to the set priority and the team member skills. The sprint backlog is the property of the Team. Estimations are set by the Team. Often an according Task Board is used to see and change the state of the tasks of the current sprint, like “to do”, “in progress” and “done”.
Defining sprints
Sprints for a given project are managed in a dedicated page. Through this page, you can define a new sprint, close a finished sprint, delete a sprint. To define a sprint, the following infos have to be filled:
| Property | Description |
| Sprint no | The number of the sprint inside the project |
| Start date | The start date of the sprint |
| End date | The end date of the sprint. It is recommended considering the sprint demo / sprint retrospective / sprint planning are within the boundaries of a sprint. |
| Nr days | The number of working days during the sprint. |
| Unit | The unit in which the tasks of the sprint are expressed. Could be Story points or Hours. |
| Nr units per day | The number of Story points of Hours achieved in a typical day. I.E: 5 hours of effective work during a day when you have removed all meetings, unexpected tasks… |
| Sprint goal | The goal of the sprint, that will be mentioned at the top of the sprint backlog / whiteboard. Very important for the team to remember each day of the sprint what the main goal of the sprint is. |
| Closed? | Indicates if the sprint is close or not. When a sprint is closed, it triggers new features on the sprint backlog: manage the retrospective, some statistics regarding the sprint. |
 |
Link to the sprint backlog of the sprint. |
 |
Open a pop-up to fill the allocation of each team member. |
 |
Delete a sprint and all its belonging tasks. This option should be used very wisely; I.E: a major business change implies to stop and forget all the work done in the current sprint. |
Team allocation:
Creating the sprint backlog
The sprint backlog is basically a read-only view of product backlog on which tasks can be created for each user story or spike (a task cannot be directly assigned to an epic). Building the tasks from the product backlog enables the team to keep a clear idea of the priorities.
Based on the estimation filled for each task, a “team allocation” box (available in the bottom-right of the screen) enables the scrum master to check the team is not going too far in the product backlog.
There is no “I have finished my sprint backlog” button: the sprint backlog can be changed during the sprint if needed, even if it should be avoided. The scrum master remains in control as the sprint backlog is read-only for the team, and only writable by the scrum master.
New sprint backlog with no task created yet:
Adding a new task to a story:
The sprint backlog filled with the first tasks:
Editing tasks
| Property | Description |
| Prio | Priorities can be assigned to tasks, to sort tasks inside a story. This can be useful if you have a high number of tasks needed to complete the story; however, if the stories are small enough (think minimum marketable features), you should have a manageable number of tasks per story, and therefore you should not need to set up priorities for tasks. |
| Task | The description of the task |
| Own. | The owner of the task. The team can decide to assign owners during the sprint planning, or to let owners blank at this stage. |
| Estim. | The estimation of the tasks, expressed in Story Points or Hours (depending on the configuration of the sprint). When filling estimation, the team allocation box is refreshed to check if the team is not over-allocated tasks to the sprint; if the team has decided to assign owners to tasks during the sprint planning, then the team allocation box is refreshed to check if a team member has not too many tasks. |
| Curr. estim. | Not editable in this view. Indicates if the task has been re-estimated during the sprint. |
| Worked | Not editable in this view. Allows the owner of the task to fill how much time he has already spent on it. |
Using the whiteboard
Going low-tech using post-its, or using a tool? While real whiteboards are more flexible than any tool (Read “the power of the whiteboard” article if you need to be convinced 
), there are situations for which tools are needed (team members in remote locations…). theSCRUM uses the metaphor of real whiteboards for team members to pick their tasks, fill re-estimations and time spent on the task. Through drag&drop, it enables team members to efficiently pass a task from “TO DO” to “IN PROGRESS” then “DONE”.
Using the burn down chart
From Wikipedia:
A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed. It is often used in agile software development methodologies such as Scrum.
theSCRUM proposes basic burn down chart capacities, based upon the status of tasks in the whiteboard. The burn down chart is computed once a day.
is released under