We have gone through the Product Backlog artifact, and we know that this artifact is an order of a list of all the features that we need in the product. But we cannot work on all these items in one go, so we will need to pick some items that can be worked in a sprint. This tutorial will learn about the Sprint Backlog and how it’s important to Sprint’s success.
- What is a Sprint Backlog?
- Who Decides and owns the Sprint Backlog?
- Is Sprint Backlog Prioritized?
- Can we modify it during the Sprint?
- What is the difference between a Sprint Backlog and the Product Backlog?
- How is Sprint Progress Monitored?
- Story Pointing
- Remaining Hours
- Sprint Burndown chart
What is a Sprint Backlog?
A Sprint Backlog is a set of Product Backlog items that we select for the sprint. It also includes a plan to deliver these items and to meet the sprint goal. It essentially contains everything that the Scrum Development Team will work on, including Stories, tasks, defects, tech debts, improvement areas from previous retrospectives, etc.
There shouldn’t be anything that the team will work on that is not on the sprint backlog.
Who Decides and owns the Sprint Backlog?
It’s a very tricky question, and you will find two viewpoints in most tutorials – One that says Scrum Team and the other which says Development Team. Let’s dig this deep. First, let’s understand how a Sprint backlog is identified. We know that the Product Backlog is a prioritized list of all the needed items in the sprint. Who decides this prioritization? Product Owner. He is the only one who decides the priority of the backlog. The features he would need first in the product will be listed higher in the priority.
Now let’s see how the backlog is chosen. The sprint backlog is finalized during the Sprint Planning meeting, which happens on the first day of the sprint. During Sprint Planning, the Product owner tells the team the features he is looking for in the sprint (reflected in product backlog priority). This, at a high level, indicates the Sprint goal. The development team then starts picking up prioritized items from the backlog. The development team decides what all they can do in the current sprint. It’s important to note that only the Development team decides what they can do in a given sprint. Once they have finalized the scope, the Sprint goal can be defined or modified (from what the product owner had initially thought).
So to answer the original question – While the Product owner indicates the features that need to be developed, the Sprint backlog is owned by the Development team.
Is Sprint backlog prioritized?
We already know that product backlog is a priority, and sprint backlog is a subset of the product backlog. So the prioritization will automatically inherit? While this is true, it’s not how it works for the sprint backlog. The Development team owns it to change the prioritization of what stories need to be done first. This can be based on several factors. E.g., There is a back-end task that needs to be done first as the UI tasks depend on them. This can also change based on skillsets required for the tasks and availability of resources within the sprint.
Remember that Sprint Backlog is not just listing out stories and tasks that the development team will do. It also includes a plan to deliver this within the sprint. This plan’s creation also happens in Sprint planning, where the team prioritizes the stories and tasks to meet the sprint goal.
Can we modify the sprint backlog during the Sprint?
As per Scrum Guide – The development team modifies the sprint backlog throughout the sprint as they learn more about the work that needs to finish to meet the sprint goal. We need to understand this modification by adding additional details to stories or adding new tasks. But all these modifications still align with the sprint goals. The team doesn’t make any change or make additions that don’t align with the sprint goal. It’s important to note that only the development team can change the Sprint Backlog during the sprint.
What is the difference between a Sprint Backlog and the Product Backlog?
We have already seen some differences between the two – but let’s revisit those and more.
- The first key difference is that the Product Backlog represents work that needs to be done by for the entire product, while Sprint backlog is a subset that represents the work that will be done in the current sprint.
- The Product Owner owns the Product Backlog while the Development Team owns the Sprint Backlog.
- The Product backlog keeps changing based on stakeholder feedback, market conditions, etc. Its modification happens during the sprint to reflect additional understanding as the team starts working. However, the work still aligns with the Sprint Goals.
- The Product Backlog is a living backlog, which exists until the product live. The sprint backlog limit is the current sprint, and another one for the next sprints replaces it.
- Additionally, it is more refined, and it has enough details for the team to start working on. The product backlog will have several items that don’t have enough detail and represent only a high-level functionality.
How to Monitor the Sprint Progress?
We know that the development team creates a plan to deliver the sprint backlog to meet sprint goals. But how do we track this daily to know if the team is on track? Let’s quickly review how estimating the stories or tasks happen in the sprint to understand this better. There are various methodologies that the team can adopt. One of the common methodologies is to give story points to the stories.
Story Pointing
The story point is nothing but an estimate of the complexity of implementing/developing a story. These are numbers like 1,2,3,5,8 and 13. Each team would eventually figure out how many story points they can deliver in a sprint, and this is a driving factor for sprint planning. Once all the story tasks are complete and meet the definition of “done,” then the story will change its status to “done.”
Remaining Hours
In addition to story points, some teams also put hours into the stories and tasks. E.g., Story has a story point of 2 and effort hours as 6 hours. Now at the end of the day, each developer will update the remaining effort. Note that the emphasis here is remaining work hours and not how many hours have been spent. E.g., a story was estimated to be 6 hours, but the developer has used those 6 hours, but he still thinks that 3 hours’ worth of work is remaining. So at the end of the day, he will update the remaining hours from 6 to 3 and update the total hours worked as 6. This shows that while the estimate was 6 hours, it would take 9 hours to complete it. The discussion on the progress happens every day in the daily stand up call.
Sprint Burndown Chart
The sprint backlog is a highly visible and real-time picture of the development team’s work during the current sprint. There are various tools available to track progress. One of the most common ways is via the Sprint Burndown Chart. The common way to show burndown is on story points, though some teams prefer to do it in the remaining hours. The story points need to be small for effective burndown.
The sprint burndown chart shows the ideal story points or remaining hours that team needed to complete on a given day, compared to actual story points or remaining hours. E.g., If the team has picked up 50 story points for a 2 weeks sprint, then the ideal burndown will be 5 story points each day. The actual story burndown is based on how many stories point the team can complete. This graph gives a good picture of whether the team is going as per plan or slipping. The team can collectively take the next steps to bring the plan back on track or negotiate the product owner’s scope.
