Backlog management in Agile needs to occur at three levels. First, the product backlog contains the prioritized list of epics, features, stories, and tasks. Second, the release backlog separates the features in the product backlog into time-phased chunks, with the first release containing as many high-priority features as possible in a working piece. The granularity differs in that the release backlog only contains prioritized and estimated stories. Finally, there is the iteration or sprint backlog (hereafter referred to as sprint backlog), which is organized into stories, broken down into tasks and estimated in terms of hours, that the team can implement within the span of each sprint. In this post, we describe the sprint backlog and best practices and pitfalls for its use.

Introduction

The sprint backlog is the primary output of the sprint planning meeting. It has two key parts. First and foremost, the sprint backlog is the list of tasks that the development team needs to complete to turn the selected set of product backlog items into a deliverable increment of functionality. Secondly, according to the Scrum Guide, the sprint backlog also contains the team’s plan for delivering these tasks and accomplishing the sprint goal, or the objective for the sprint that was defined during the sprint planning meeting (Schwaber and Sutherland, 2013, July)

Unlike the product backlog, which is managed primarily by the product owner, the development team owns the sprint backlog and takes responsibility for updating it and managing it throughout the sprint. Developers manage the backlog by signing up for tasks, updating their progress on tasks they have taken on, and removing any tasks that no longer apply due to changing requirements.

Best Practices

1. Update the sprint backlog on a regular basis.

For teams to get the best use out of their sprint backlog, they need to be able to see, at a glance, what has been finished, what is remaining, and what is in progress. To achieve this ability, teams need to make sure the sprint backlog is updated regularly. Some of the input to updates will come from daily scrums, but if a major issue comes up between scrum meetings, updates may need to occur sooner.

2. Empower teams.

Self-managing teams are a key to Agile. Teams discuss among themselves who takes on specific tasks, and team members can sign themselves up for a task in order to give themselves the opportunity to learn and develop. Luciano Felix (2009, 24 March) recommends making sure that every team member is involved in creating the sprint backlog and creating the “definition of done” for greater buy-in. Developers should feel free to assign themselves tasks rather than have them assigned. Empowering teams to make these decisions and similar decisions will help them learn; likewise, constraining them will likely hinder their growth.

3. Do not allow major changes during the sprint.

Another important piece of the self-management principle is that the team should be able to resist changes that would compromise a sprint goal. One example might be taking on a long change that would make it impossible for the team to complete other tasks in the sprint. This does not mean that no changes are welcomed in Agile; rather, they would be added to the product backlog, prioritized, and rolled into later sprints. While Agile welcomes change, it should not come at the price of disrupting the team’s flow during a sprint.

Teams who see lots of changes requested during a sprint might consider lowering their sprint length. For example, if many changes come in during the third week of a three-week sprint, the team should consider changing the sprint length to two weeks. This move to two weeks would minimize late changes and also provide the team an opportunity to address the changes sooner.

Pitfalls

1. Limiting the sprint backlog to just a set of Product Backlog items.

According to the Scrum Guide, the sprint backlog is a set of product backlog items selected for the sprint, plus a plan for delivering the product increment and realizing the sprint goal. The sprint goal is not just the set of tasks to be done, it is the overall objective for the sprint and the rationale for why this work is being done. In other words, the sprint backlog is not just a “what,” it is also a “why” and “how.” By reducing the sprint backlog to just the series of tasks, teams run the risk of producing disjointed software that isn’t cohesive and doesn’t add value.

2. Sticking too closely to the sprint backlog.

The Scrum Guide defines the sprint backlog as a “forecast” of what can be accomplished in a sprint (Schwaber and Sutherland, 2013, July). The development team can remove items if they are not necessary, and have some leeway to accommodate new items during a sprint (however, they should not accept any changes that make the sprint goal impossible to deliver) By sticking too closely to the sprint backlog, teams lose some of their flexibility to adapt. This does not mean teams should throw out their sprint backlogs, but there needs to be some ability to adapt.

How have you used the sprint backlog in your organization? What are some of your best practices and pitfalls? Please let us know in the comments.

If you are looking for further assistance, or have a specific roadblock you need to get around, we’re happy to help. We specialize in Agile Transformation. We can help your team successfully implement Agile, or get back on track with Agile with a little bit of coaching or training. Contact us today for your free initial consultation!

References

1. Felix, Luciano (2009, 24 March). 9 tips for creating a good sprint backlog. Scrum Alliance. Web.

2. Schwaber, Ken and Sutherland, Jeff (2013, July). The Scrum Guide. Scrum.org. Web.