The Ultimate Guide to the Sprint Backlog
Agile software development continues to be a staple based on its successive iterative style. Common Scrum events include Sprint Planning, Daily Scrum, Sprint Review and the Sprint Retrospective. A key artifact in Scrum is the Sprint Backlog. In Agile, this backlog may be called an iteration backlog. It is highly versatile but is easy to misuse. This guide shares what the Sprint Backlog is, how it fits into Scrum, best practices, and so much more. We hope this guide helps you and your team achieve success in future projects.
What Is the Sprint Backlog?
The Sprint Backlog is, ultimately, a plan for the Sprint. The development team executing work inside of a Sprint creates a Sprint Backlog. The creation occurs during the Sprint Planning. The central question is, how does this work get done? The Product Owner presents a list of prioritized items from the Product Backlog. The team will analyze the list, do capacity management, figure out what they can do, and make a plan to execute. The Sprint Backlog is a plan to achieve the overall goals of the Sprint.
Teams can benefit from the Sprint Backlog because it gives them a direction on a day-to-day basis and keeps the group on track. Scrum does not require you to create tasks (though most teams will do this anyway). On a daily basis, teams meet to see if they are on track, comparing their completed work against their original plan. One metric coming out of the Sprint Backlog is the burndown chart. If you have tasks to complete in a Sprint, this compares actual completion against the plan.
When you use tools, such as a burndown chart, you understand quickly when the team is falling behind, if you need to adjust the plan for the Sprint, and communicate expectations to the Product Owner. Another positive aspect is that teams are able to identify if they are ahead of schedule or behind schedule (and may need to put in additional work for the Sprint). Every situation is different, but the Sprint Backlog drives opportunity and execution, provides a visual to help the team know if they are on-track, and helps to manage expectations.
How Often Should It Be Updated?
The Sprint Backlog should be updated daily. Typically, items are in an overall Product Backlog. Teams will take those items and break them down into tasks. The tasks should be achievable in less than one day. If you are falling behind, having the tasks broken down that way will let you know if are on-track or falling behind. In the daily scrum meetings, you should be able to report progress every day.
In the event you are not updating and refining the Sprint Backlog daily, you will quickly realize it when you are not seeing work being completed, or the team is falling behind on the work. If it is not correctly updated, multiple days may go by without knowing that the team is no longer on-track.
With smaller, one-day tasks and daily updates teams can better pivot and react to progress. Teams that do not update daily tend not to pay much attention to the plan for the Sprint and are more likely to fail during the Sprint.
How to Use the Sprint Backlog in the Daily Stand-Up
The Daily Scrum, sometimes referred to as the Daily Stand-Up, is a discussion about what the team did since the last meeting, what they will be doing until the next meeting, and what impediments or problems certain team members are facing preventing them from getting their work done. This event should be no longer than 15 minutes. One helpful aspect of these meetings is seeing the Sprint Backlog daily to visually show progress on what the team is working on.
What Does a Sprint Backlog Contain?
Officially, the Sprint Backlog contains a plan for the Sprint. Usually, it will contain the Product Backlog Items (PBIs) that the team forecast to complete, along with a list of prioritized tasks broken down for each PBI to execute by a team. The order is based on the priority of the Product Backlog Item. The Product Owner works with the business to understand their priorities and then they pass that information to the Scrum Team. The team uses their current velocity, or how much work they can complete, to predict what they can fit into the current Sprint. Once they make the plan for the Sprint, the Development Team should compare the total hours of all the task against their capacity and make a final determination of what they can expect to complete.
How Does a Sprint Backlog Work?
During Sprint Planning the Product Backlog items on the Sprint Backlog are broken into tasks that can be completed within one-day. This allows us to see daily progress and helps with multiple people working on a Product Backlog item simultaneously.
Once you have the Sprint Backlog, it is locked in. Teams cannot remove items from the Sprint Backlog once they added it and the Sprint Planning is over. They can add more items to the list but they can’t remove items. If an item doesn't finish, the Product Owner will need to decide what to with that PBI. The Product Owner is the only individual that can remove things from the Sprint Backlog if it no longer provides business value. They cannot replace it with something else.
What Is the Difference between Product Backlog and Sprint Backlog?
The Product Backlog contains a list all of the items to be completed for overall product success. The Sprint Backlog is a subset of the Product Backlog. It is a forecast of work to be done in the Sprint’s expected time frame. Sprint Planning is an event where the Product Owner presents the most important Product Backlog Items and clarifies the details. Teams will then determine what they can execute in the Sprint based on priority order. What they believe they can complete is added to the Sprint Backlog.
Who Manages the Sprint Backlog?
The Sprint Backlog management is done by the Development Team. Best practices include using the Daily Scrum to update the Sprint Backlog every day. The team should be communicating regularly to realize dependencies or impediments based on the work they complete. The minute the Development Team decides they cannot get an item done, they should talk to the Product Owner. The communication will then revolve around setting expectations and discussing possible solutions.
Common Issues Teams Face and How to Resolve Them
Scrum Teams that often "fail", or are frequently unable to complete all of their work in a Sprint, can usually point to poor planning or Product Backlog items that are too large. Another common problem is having teams commit to too much work right off the bat.
These issues can normally be resolved through constant communication between the Development Team, Scrum Master, and Product Owner. Teams fail when they do not break down items into manageable tasks, do not revisit the Sprint Backlog daily, and do not communicate problems.
Capacity management is also in play. Scrum Masters have to look at the team and see what the team’s availability is for the Sprint. Figure out who is on the team and how many days they are available to work, taking into account vacation time, potential sick time and anything else that might draw a team member away from work. Understanding these little things can help to ascertain the actual capacity of a team.
Here is a quick example of capacity planning. Team members don't generally work 8 straight hours, especially in the software world. Instead, plan on 6 hours of work each day. In a 10 day sprint, there would probably be a full 8 days worth of work and another 2 days for Sprint Planning, Review and Retrospective. Doing the math: 8 days times 6 hours per day equals 48 hours available per team member. Therefore, a team of 5 has 240 hours of capacity.
After calculating the work capacity of a whole team you can deduct the hours from absent team members. This is your grand total. The final step is planning out the Sprint and comparing your total task hours to your total capacity.
Not all Certified Scrum Trainers teach these methods. I do in my classes because I feel they are helpful, but they are not required. It makes a big difference. Hope to see you in class!
