… the Scrum Team has a well-defined Product Backlog and is holding a Sprint Planning Meeting to define the current Sprint. The Product Backlog Items (PBIs) that are selected are what will be developed; but the team must define how to develop them.
✥ ✥ ✥
In order to implement PBIs, you need to break them down into a credible work plan. Yet it’s difficult to keep track of and even remember them all.
In order to understand whether a PBI can be accomplished in a given Sprint, you need to understand the PBI in detail, including breaking it down into Small Items to Estimate. This is design work that flows into the Scrum itself. You can’t afford to shed any of this design work.
But this understanding is incomplete, and must evolve as more insight emerges.
The Development Team needs a starting point for measuring progress against the Sprint Goal. Of course, the ScrumMaster and Product Owner are interested too. But it’s the Development Team that makes the progress.
Create a list of Sprint Backlog Items that need to be accomplished in order to complete the Sprint Goal.
✥ ✥ ✥
The essence of creating the Sprint Backlog is the detailed design of the PBIs, but a Sprint is by definition time-boxed. Therefore, the Team must consider its Velocity in order to create a Sprint Backlog that it expects to be able to finish within the Sprint. (Use patterns of Velocity, such as Yesterday’s Weather, to help determine how much can be put in the Sprint Backlog.)
The contents of the Sprint Backlog can change during the course of the Sprint. As more is learned about the work, Developers might add or change SBIs . SBIs could be removed, or even split or combined. The dynamic nature of the Sprint Backlog makes it necessary to do incremental re-planning as a major activity of the Daily Scrum.
While there no formal ordering of the Sprint Backlog, there is an ordering in the sense that certain SBIs depend on the completion of others. The fact that the Development Team Swarms on PBIs also creates an ordering, but it’s up to the Development Team how to manage it: they can order the Sprint Backlog, or can just pull from it every. However they manage it, the Development Team must understand the dependencies among the SBIs so they can order their work and have an accurate picture of status; see Dependencies First.
The Sprint Backlog is visible to all; there is no reason to keep it secret.
The Sprint Backlog is intimately tied to the Sprint Planning Meeting. A key outcome of the Sprint Planning Meeting is an ability to explain how the Sprint Goal will be accomplished. The Sprint Backlog helps provide a mechanism of expression of the how, and helps the Development Team remember its design decisions.
A precise Sprint Backlog helps the Development Team to remember all detailed work they need to do.
The Sprint Backlog provides the basis for tracking progress (Burndown Chart) and for making status visible (Visible Status).