…the Scrum Team has a well-defined Product Backlog and is convening Sprint Planning to define the current Sprint. The Development Team gives a forecast of the anticipated delivered Product Backlog Items (PBIs) to the Product Owner, but the team members must define how they plan to develop them.

✥       ✥       ✥ 

In order to manage its progress during the Sprint, the Development Team needs to have a clear understanding of work remaining to achieve the Sprint Goal.

In order to understand whether the team can complete a PBI in the Sprint, it needs to understand the PBI in detail. Breaking a PBI down into Small Items helps the team more deeply understand the work necessary to bring a PBI to Done (see Definition of Done). This is design work that flows into the Scrum itself. You can’t afford to shed any of this design work. But the team has only incomplete understanding of the work necessary at the beginning of the Sprint, and the work is likely to grow as more insight emerges.

The Development Team needs a basis upon which to self-organize to accomplish the Sprint Goal. Frequent and accurate feedback at the Daily Scrum on the work remaining are essential for the Development Team to manage the dynamics of development.

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 actually creates the Product Increment.

Therefore:

Create a work plan for everything that the team must accomplish to meet the Sprint Goal. The team usually subdivides this work into Sprint Backlog Items (SBIs). These items may represent tasks that the team must complete, intermediate building blocks that combine into a deliverable, or any other unit of work that helps the team understand how to achieve the Sprint Goal within the Sprint.

✥       ✥       ✥ 

The Development Team creates and owns the Sprint Backlog and only the members collectively can change it ([1], p. 50; see also Developer-Ordered Work Plan). The essence of creating the Sprint Backlog is the detailed design of the PBIs so that anyone in the Development Team can explain how they will accomplish the Sprint Goal ([2]). The Sprint Backlog helps provide a mechanism to express the how of development, and helps the Development Team remember its design decisions. But a Sprint is by definition time-boxed. Therefore, the Development Team must consider its velocity (see Notes on Velocity) to create a Sprint Backlog it thinks it can finish within the Sprint in service of the Sprint Goal. Using patterns of velocity, such as Yesterday’s Weather and Updated Velocity, will help the team determine how much it can put in the Sprint Backlog.

A precise Sprint Backlog helps the Development Team to remember all detailed work it needs to do. The Development Team decides the order of the Sprint Backlog and should keep it ordered to optimize the chances of meeting the Sprint Goal. The contents of the Sprint Backlog can change during the Sprint. As the Development Team learns more about the difficulty of the work, it might add or change SBIs. The team might remove SBIs, or even split or combine them. The dynamic nature of the Sprint Backlog makes it necessary to do incremental replanning as a major activity of the Daily Scrum.

The Sprint Backlog provides the basis for tracking progress [3] (Sprint Burndown Chart) and for making status visible (Visible Status). At the Daily Scrum, the Sprint Backlog helps the Development Team members decide what they will work on next. While there is no formal ordering of the Sprint Backlog, there is an ordering in the sense that certain SBIs depend on the completion of others. The Development Team swarming on PBIs (see Swarming) also affects the ordering, but it’s up to the Development Team how to manage it. However it is managed, the Development Team must understand the dependencies among the SBIs so it can order the work and have an accurate picture of status; see Dependencies First.

The Developers should make the Sprint Backlog transparent to all stakeholders with an Information Radiator such as a Scrum Board, to increase transparency. One must be careful that people outside of the Development Team will not use this transparency to micromanage the team; the ScrumMaster should monitor for such abuse of any Information Radiator. The Sprint Burndown Chart and Scrum Board digest Sprint Backlog progress into more visual Information Radiators.

[1] Ken Schwaber. Agile Project Management with Scrum. Redmond, WA: Microsoft Press, 2004, p. 50.

[2] Ken Schwaber and Jeff Sutherland. Software in 30 Days: How Agile Managers Beat the Odds, Delight Their Customers, and Leave Competitors in the Dust. Chichester, UK: Wiley, 2012.

[3] Ken Schwaber and Jeff Sutherland. The Scrum Guide. Scrumguides.org, http://www.scrumguides.org (accessed 2 November 2017).

Picture credits: Shutterstock.com.