Within the Sprint Backlog all activities required to complete the committed entries from the Scrum Product Backlog are stored. All entries have to be estimated on a person-hour base in order to track progress and remaining efforts.
The Sprint Backlog is a living artifact and is updated on a daily base. If a team member starts to work on an activity his name is recorded within the sprint backlog. New activities can be added to the Sprint Backlog during the Sprint. At the end of the day all remaining efforts are updated and this defines how much work is left until the Sprint Goal is reached. The Definition Of Done is used to decide if an item is done or not.
How to create sprint backlog?
The Sprint Backlog is created during the Sprint Planning Meeting. The team pulls the amount of work they want to do from the Product Backlog into the Sprint Backlog, and further decomposes the PBIs into Sprint Tasks. The team decides the how, and expresses this in the tasks. The best way to represent the Sprint Backlog is a physical task board, using PostIt Notes or index cards as well be kept electronically within e.g. an Excel-Sheet or digital task board. The latter has some advantages (e.g. transparency and easy access) but add additional complexity if the Scrum Team is distributed over multiple sites. The figure below shows an example how such a task board could be organized. The structure should be adapted to reflect the needs of the project.
Why sprint backlog is Important?
It is common practice in Scrum that the Sprint Backlog is represented on a Scrum board or task board, which provides a constantly visible depiction of the status of the User Stories in the backlog. Also included in the Sprint Backlog are any risks associated with the various tasks. Any mitigating activities to address the identified risks would also be included as tasks in the Sprint Backlog. Once the Sprint Backlog is finalized and committed to by the Scrum Team, new user stories should not be added – however, tasks that might have been missed or overlooked from the committed user stories may need to be added. If new requirements arise during a Sprint, they will be added to the overall Prioritized Product Backlog and included in a future Sprint.
9 Tips for Creating a Good Sprint Backlog
- Involve every team member in the process
- Discuss how every item should be implemented
- Have a definition of done
- Identify all kinds of tasks
- Don't estimate tasks at all
- Don't assign tasks up front
- Review the sprint commitment
- Don't use too much time
- Evolve the Sprint Backlog during the sprint