Scrum is an agile way to accomplish the project, usually in software development. In Scrum, artifacts are the key information providers that are designed specifically to enhance transparency of key information required to ensure that the Scrum teams are successful in delivering a ‘Done’ increment. The Scrum Process Framework defines 3 essential artifacts:
- Product Backlog
- Sprint Backlog
- Product Increment
In this article, we are going to see everything in detail about Sprint Backlog in Scrum. While being a simple concept, it is misunderstood by many people. This article will clear up the confusion and explain clearly what the Sprint Backlog is and how to use it. So, let’s take a look at the ultimate guide to the Scrum Sprint Backlog. Go for CSM certification training and boost your scrum learning.
What is a Sprint Backlog?
The Sprint Backlog is a set of all the product backlog items chosen for the current sprint, plus a plan for delivering the product increment and achieving the sprint goal. This plan takes the form of all the work required to get the backlog items to “Done” in that sprint.
The following video will explain how to create your first sprint backlog.
The Sprint Backlog is produced by the team in the Sprint Planning meeting. It is an outcome of that meeting and the Sprint Planning meeting should not conclude until the team has produced the Sprint Backlog in some form (though it can actually change after that, as I’ll explain below). Collated below is the anatomy of Scrum Sprint Backlog.
Steps for creating a better Sprint Backlog
Sprint Backlog is the output of the sprint planning meeting with the participation of every team member in the Scrum team. The process is as follows:
There is another final step that many teams don’t do (and don’t know about!). As of the latest version of the Scrum Guide, the team must also add a continuous improvement item to the Sprint Backlog. This is an interesting and important change and will really encourage teams to take continuous improvement seriously (rather than as an afterthought). Make sure you don’t forget to do this with your teams!
Once produced, the team should make sure that the Sprint Backlog is visible to everyone. This ties in with the Scrum pillars of transparency, inspection, and adaptation. It provides a clear, real-time view of the progress of the team in completion of the sprint goal and Product Increment.
How does the team plan the work?
Many people might now be wondering what a “plan” is. The answer is, it can be anything that the team comes up with to complete the product increment and complete the items in the Sprint Backlog. Some people do this by breaking them into tasks, which are estimated in hours. That’s fine, though it’s not mandated by Scrum.
Each team should find its own best way to plan and arrange the work. Scrum guide is very clear on this matter:
The figure below shows an example of how the development team plans the work to be done in the sprint for each user story.
So the Sprint Backlog will start off with some Product Backlog Items. The team can then add tasks, subtasks, designs, diagrams, whatever they like to the Sprint Backlog, as part of coming up with a plan to complete the work.
Can you change the Sprint Backlog?
Some people believe that the Sprint Backlog cannot be changed during the Sprint, that it is locked down when the sprint starts. This is totally untrue!
The Scrum Guide is very clear on this point. It says
The key point is that only the Development Team can change the Sprint Backlog since it is their artifact. Conversely, the Product Owner owns the Product Backlog and is the only person who can change that.
So the team should add, remove, and change things in the Sprint Backlog as the sprint progresses, work is completed, new facts are discovered, and so on.
Keep in mind though that the changes should be discussed with the Product Owner (though they don’t need approval from them), and that they should still reflect the team’s understanding of the sprint goal. Changing the Sprint Backlog so that it no longer matches with the sprint goal is a serious decision that would need the agreement of the product owner, and could be grounds for canceling a sprint.
Do we have to use tasks?
Another myth is that the team must break the stories down into tasks as part of moving them into the Sprint Backlog in Sprint Planning. This is also not true! The Scrum Guide does not include the word “task” anywhere. The team finds its own best way of completing the work.
What is the output of a sprint backlog?
The output at the end of a sprint is a product increment (PI). A product increment is the sum of all the Sprint Backlog items which are “Done” at the end of the sprint, plus the outputs of all the previous increments in previous sprints.