Scrum is a widely adopted framework for developing, delivering, and sustaining complex products iteratively. Central to this framework is the concept of a backlog, which serves as a structured repository for all work. Understanding how work is planned requires knowing precisely when and how the Sprint Backlog, a main artifact, is created. This article defines the timing and process for formulating this planning document.
Defining the Sprint Backlog
The Sprint Backlog (SB) represents the specific work the Development Team intends to accomplish during a single Sprint. It is composed of two distinct, interconnected elements. The first element is the selection of Product Backlog items (features, requirements, or fixes) chosen from the overall master list of work.
The second element is the detailed, actionable plan for how the team will deliver these selected items and achieve the Sprint Goal. This artifact functions as a highly visible, real-time forecast of the work the Development Team believes is feasible within the time box. Unlike the comprehensive Product Backlog, the Sprint Backlog is a specific, time-bound subset that provides immediate focus.
The Definitive Answer: Timing the Creation
The Sprint Backlog is created exclusively during the Sprint Planning event. This event is the first activity that occurs immediately at the beginning of a new Sprint cycle.
The purpose of the Sprint Planning session is to define the work for the upcoming cycle, which directly results in the formation of the Sprint Backlog. No part of this artifact is formally created before the Sprint officially starts or outside of this specific, time-boxed meeting.
Prerequisites for Effective Backlog Creation
Creating a meaningful and achievable Sprint Backlog requires several preparatory steps before the Sprint Planning event begins. These prerequisites ensure the planning meeting is efficient and results in a high-quality forecast of work.
The first necessary input involves having a sufficient number of “ready” Product Backlog items. These items must meet the Development Team’s established Definition of Ready, meaning they are well-understood, clearly defined, and have been sized or estimated. Ambiguous items cannot be effectively selected for immediate development.
Another foundational element is the Product Owner’s proposal for the upcoming Sprint Goal. This goal provides the overarching objective and narrative for the Sprint, guiding the Development Team when selecting items. Finally, the Development Team must understand their current capacity, accounting for availability, planned holidays, and recent historical performance (velocity).
Mechanics of Sprint Planning and Backlog Formulation
The Sprint Planning meeting transforms the selected inputs into the official Sprint Backlog artifact. The process begins with the Development Team collaborating with the Product Owner to determine the “What” that will be delivered. The team selects Product Backlog items that align with the Sprint Goal and that they believe can be completed based on their capacity assessment.
This selection is a pull mechanism, where the team commits to what they can realistically deliver. These selected items form the high-level component of the Sprint Backlog. Following selection, the team addresses the “How” by decomposing the items.
This decomposition involves breaking down the larger items into smaller, more granular, and actionable tasks. These tasks represent the specific technical steps required to complete the item, such as designing a database schema or coding a function. This breakdown formulates the second component of the Sprint Backlog: the detailed plan for delivery.
The team continuously refines this task list until they are confident they have a feasible plan to achieve the Sprint Goal. The meeting culminates in the finalization of the commitment. The Development Team confirms their commitment and presents the resulting Sprint Backlog, making it a transparent and agreed-upon plan.
Maintaining the Sprint Backlog During the Sprint
Once created during planning, the Sprint Backlog functions as a living artifact that is continuously maintained and updated throughout the Sprint. The Development Team uses the Daily Scrum event as the primary mechanism for inspecting progress toward the Sprint Goal and making necessary adjustments to the plan.
During the Daily Scrum, the team assesses performance and identifies roadblocks or new information. This inspection leads to the adaptation of the Sprint Backlog, which may involve adding new tasks, removing unnecessary tasks, or adjusting estimated effort. The team updates the backlog to reflect the reality of the work being done.
The Development Team maintains exclusive ownership of the Sprint Backlog throughout the cycle. They have the authority to adjust the detailed plan (the tasks) if new information surfaces or challenges arise. Adaptations are permitted, provided these changes do not endanger the team’s ability to achieve the committed Sprint Goal.