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, as well as the Sprint Retrospective.  A key artifact in Scrum is the Sprint Backlog. In Agile, this backlog may be called an iteration backlog. It has many uses and is easy to misuse. This guide shares what this 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? How does it help a team?

 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 Scrum event, Sprint Planning.  The central question is, how do we get this work 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 for the time-boxed period, the Sprint.

Teams benefit from the Sprint Backlog as it gives them direction on a day-to-day basis.  Scrum does not prescribe you have to create tasks.  Most teams will do this, but it is not a requirement.  The Sprint Backlog, though, keeps the overall group on track.  On a daily basis, teams meet to see if they are on track based on their completed work against their planned action.  One metric coming out of the Sprint Backlog is the burndown chart.  If you have tasks with hours to achieve in a Sprint, this compares 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 and may pull in additional work for the Sprint.  Every situation is different, but the Sprint Backlog drives opportunity and execution, as well as a visual to help the team to know if they are on-track and set expectations.

How often should it be updated? What happens if it isn't updated properly?

The Sprint Backlog gets an update 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.  Using the daily scrum meetings, with less then a day sized tasks, you should see progress made daily.

In the event you are not updating the Sprint Backlog daily, you will quickly realize it when you are not recognizing work completed or work falling behind.  If it is not correctly updated, multiple days may go by without understanding that the team is no longer on-track.

With one-day tasks, which get a daily update, 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 the Sprint.

How is it involved in daily stand up meetings?

Stand up meeting

The Daily Scrum, sometimes referred to as the daily stand up, involve what the team did since the last time they synced, what they will be doing until the next time they sync and is there any team member who has an impediment that prevents them from getting their work done.   This event should be no longer then 15 minutes. One helpful aspect of these meetings is seeing the Sprint Backlog daily to visually show what the team is working on, providing a visual indication of progress.

What does a Sprint Backlog contain? How should teams decide what goes on the Backlog?

Officially, the Sprint Backlog contains a plan for the sprint. Scrum doesn't say how that's captured. What's most common is that it will contain the Product Backlog Items (PBIs) that the team forecast to complete 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 voices that to the Scrum Team.  The team uses their current Velocity or how much work they can complete to forecast what they fit into this 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 forecast 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 at once.

 Lock in Sprint Backlog

Once you have the Sprint Backlog, it is locked in.  Teams cannot remove items from the Sprint Backlog once they forecast it and Sprint Planning is over.  They can add more items in, but not remove.  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 swap something back in.

What is the difference between product Backlog and Sprint Backlog? What is the relationship between the two if any?

The Product Backlog contains a list all of the items needed to complete for the overall Product.  The Sprint Backlog is a subset of it, but it is a forecast of work for the Sprint’s time-box.  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? What are some basic best practices for managing the Backlog?

 Product 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 has to have communications to realize dependencies or impediments based on the work they commit.  The minute the Development Team figures they cannot get an item done, they talk to the Product Owner.  The communication will then be around setting expectations and discussing possible solutions.

What common issues do teams face when dealing with Sprint Backlog?

Scrum Teams that often "fail" or do not complete all of their work in a Sprint is usually due to poor planning or having Product Backlog Items which are too big.  Other common problems include having teams commit to too much work or having tasks that are too big to be measured daily.

How do you solve the issues you mentioned?

Solving these issues usually happens through constant communication occurring between the Development Team, Scrum Master, and Product Owner.  Teams fail when they do not break down tasks into one day items, do not revisit the Sprint Backlog daily, and do not communicate dependencies and impediments. 

Capacity management is also in play.  Scrum Masters have to look at the team and see what the team’s availability for the sprint is.  Figure out who is on the team, how many days they will work, take into account vacation time, potential sick time and anything else that might draw a team member away from doing work.  An understanding of everything can help figure the actual capacity of a squad.

CA Class Map - Capacity Planning.png

Capacity Planning example. Team Members don't work 8 straight hours, especially in the software world. So we plan for 6 hours of work each day. In a 10 day sprint, there are a full 8 days of work time available. Leaving the other 2 days for Sprint Planning, Review and Retrospective. 8 days times 6 hour days equals 48 hours available per team member. So a team of 5 has 240 hours of capacity. Now figure out who's not here the whole time and deduct from the total. Now plan out the Sprint and compare your total task hours against your capacity.

Not all Certified Scrum Trainers teach these methods. I do in my classes as I feel they are helpful but they are not required. It makes a big difference. Hope to see you in class!