In 30 seconds
- Made of three parts: the why, the what, and the how.
- Owned by the Developers and updated throughout the sprint.
- Its commitment is the Sprint Goal.
Three parts
- Why: the Sprint Goal.
- What: the Product Backlog items selected in Sprint Planning.
- How: the tasks or plan for getting them done.
A living plan
The Developers update the Sprint Backlog as they learn: adding tasks they discover, splitting items, or renegotiating scope with the Product Owner. It should always show the real state of the sprint, usually on a board.
Sprint Backlog vs Product Backlog
| Product Backlog | Sprint Backlog | |
|---|---|---|
| Owner | Product Owner | Developers |
| Time span | Whole product | One sprint |
| Commitment | Product Goal | Sprint Goal |
Myth vs reality
Myth · Managers can add work to the Sprint Backlog.
Reality · Only the Developers change it; new requests go through the Product Owner.
Myth · It must be broken into hour-level tasks.
Reality · Detail enough to see progress; many teams use day-sized tasks.
Myth · Unfinished items roll over automatically.
Reality · They go back to the Product Backlog to be re-ordered.
FAQ
How do we track progress?
A task board plus, optionally, a burndown chart.
Can items be removed mid-sprint?
Yes, by agreement with the Product Owner, as long as the Sprint Goal holds.
Is the Sprint Backlog visible to stakeholders?
It should be; transparency is a core Scrum idea.