The three parts of the Sprint Backlog
The Sprint Goal explains why the Sprint matters. The selected Product Backlog items are what the Developers forecast to complete during the Sprint. The plan for delivering the Increment is how, usually a set of tasks decomposed to be small enough to complete or reassess daily.
All three elements are created together during Sprint Planning, but the plan is expected to be a living document; the Scrum Guide is explicit that the Sprint Backlog is updated throughout the Sprint as more is learned, not fixed on day one.
Who owns it
The Sprint Backlog is owned solely by the Developers. Even the Scrum Master and Product Owner do not modify it unilaterally, though the Product Owner can clarify or renegotiate scope with the Developers if needed and the Scrum Master can help the team keep it visible and useful.
This ownership matters because the Sprint Backlog is a forecast made by the people doing the work, and a forecast imposed from outside is not a real forecast, it is an assignment.
Keeping it a living plan, not a snapshot
A Sprint Backlog that is only updated once, at Sprint Planning, and never touched again stops reflecting reality within days. The Scrum Guide's expectation is that the Developers modify it throughout the Sprint, adding newly discovered tasks and removing ones that turn out to be unnecessary.
Making the Sprint Backlog visible, whether on a physical board or a shared tool, is what allows the Daily Scrum to be a quick, useful inspection rather than a status meeting; everyone can see the same plan and focus discussion on what actually needs to change.
- Decompose Sprint Backlog items into tasks small enough to finish in a day
- Update it throughout the Sprint, not only at Sprint Planning
- Keep it visible to the whole Scrum Team at all times
- Let the Developers, not outsiders, decide what changes on it
Anti-patterns
A manager or Product Owner adding items directly to the Sprint Backlog mid-Sprint without the Developers' agreement undermines the forecast and the Sprint Goal it is meant to protect. Another anti-pattern is a Sprint Backlog that is never updated after Sprint Planning, which turns the Daily Scrum into a guessing game about what is actually happening.
Overly granular task breakdown, where the Developers spend more time updating tickets than doing the work, is also a failure mode; the plan should serve the team, not become a second job.
How it connects to the rest of Scrum
The Sprint Backlog is created in Sprint Planning, inspected daily at the Daily Scrum against the Sprint Goal, and its remaining items either become part of the Increment or return to the Product Backlog at the end of the Sprint. Its health is a direct reflection of how well Sprint Planning and Product Backlog refinement were done beforehand.
Frequently asked questions
What three elements make up the Sprint Backlog?
The Sprint Goal, the Product Backlog items selected for the Sprint, and an actionable plan for delivering the Increment. All three are created together during Sprint Planning and evolve together during the Sprint.
Who can change the Sprint Backlog during the Sprint?
The Developers own it and are the ones who update it as they learn more. The Product Owner can negotiate scope with them if priorities shift, but does not unilaterally add or remove items from the plan.
Is the Sprint Backlog the same as a task board?
A task board, physical or digital, is usually how the Sprint Backlog is made visible, but the Sprint Backlog itself is the Sprint Goal, the selected items, and the delivery plan together, not just the visual tool used to display them.
What happens to unfinished Sprint Backlog items at the end of the Sprint?
They do not carry an automatic penalty or roll over as a broken promise. The Scrum Guide has no ceremony for 'carrying over' work; unfinished items simply return to the Product Backlog, where the Product Owner re-evaluates and re-orders them alongside everything else.