Whenever you start a new sprint, you start with a sprint backlog.
In one sentence, the sprint backlog is the sum of all the backlog items the team can fit in a sprint. Simple, right? If only …
The devil, as usual, is in the details.
- Why do we even need a sprint backlog?
- How is the sprint backlog created?
- What is in the sprint backlog?
Let us try to answer these 3 questions, and hopefully, we will have a better understanding of why we do sprints.
Why a sprint backlog?
Why do we need one?
The goal of the sprint backlog is to ensure focus on the sprint goal.
We do that by asking the following question:
- What is the remaining work that is needed to achieve the goal?
- Is the goal still achievable?
- What is the next top priority item that we can pick up?
The purpose of these questions is not to point fingers, instead, we inspect our progress and adapt our approach if needed.
How is it created?
The sprint backlog is created by the team.
The product owner expresses what he/she wants to achieve in the upcoming sprint by challenging the team with a goal.
The team in response to this challenge gets together, looks at the product backlog, and selects all the items needed to achieve the goal.
This is done during the sprint planning meeting.
A very important note. The sprint backlog is pulled by the team, not pushed by the P.O.
What is the sprint backlog?
The sprint backlog is a plan. The plan to reach a goal.
Does that mean that we will follow the plan blindly? No.
The sprint backlog can change. If new items are required, the development team may pull those into the sprint. If items are no longer necessary, the team can remove them.
Only the development team can change the sprint backlog during the sprint. This is very important.
The only way the development team can commit to a sprint is if they are autonomous on how they conduct their work.
If anyone can change that commitment, well, then how can you commit to delivering the unknown?