Using Sprint Backlogs Effectively
Having a well-managed and effective Sprint Backlog helps everyone understand what will and will not be accomplished during the Sprint.
Building an effective Sprint Backlog starts during the Sprint Planning event. At the end of the event:
- The Scrum Team has defined the Sprint Goal and the Developers commit to achieving it
- The Developers have selected a set of Product Backlog Items that they forecast will be Done during the Sprint
- There should be only one Sprint Backlog; there should be no separate backlog for enhancements, defects or other tasks
- The Sprint Backlog should have one or two Sprint Retrospective improvement items that the team would like to work on during the Sprint
- The Sprint Backlog should include an actionable plan for how the team will deliver the work and achieve the Sprint Goal
- One way to create this plan is to decompose selected PBIs into multiple units of work that allow progress on the PBIs to be transparent
- Ideally, the Developers do this work together. This conversation helps uncover dependencies and impediments in the work and drives greater alignment and understanding among team members
There is no specific format for the Sprint Backlog. However, many teams create a Scrum Board which helps them visualize progress on the PBIs by indicating the state of each item on the Sprint Backlog. These states are often “To Do,” “In Progress,” and “Done.”
During the Daily Scrum, the team focuses on the progress being made toward the Sprint Goal and they discuss adjustments to the Sprint Backlog. These adjustments include adding, removing, splitting and decomposing Product Backlog Items (PBIs) and the tasks required to accomplish them. These adjustments are often made after the Daily Scrum concludes.
Resources: