Chapter 39. Sprint Backlogs Deserve a Life Beyond Your Electronic Tool

Mark Levison

Most Development Teams that I encounter simply use whatever their online Scrum tool feeds them for their Sprint Backlog. This harms the Team’s capacity for engagement because it reinforces the sense that Scrum is happening to them, not something they choose. Since the Sprint Backlog is solely for the use of the Development Team to organize their own work, they are the only ones who create, change, and manage it—not a tool and not an outsider.

A Sprint Backlog consists of a set of Product Backlog Items (PBIs) that the Development Team thinks they can complete in the Sprint, along with the work needed, described in small enough chunks that progress can be tracked throughout the Sprint. One specific and common belief is that a Sprint Backlog must contain tasks, which is not the case at all.

The Scrum Guide doesn’t provide any guidance on the contents or format of a Sprint Backlog. An effective Sprint Backlog contains more than just tasks.

Teams experiment with and choose whatever best helps them to stay focused and self-organize, creating the Sprint Backlog with whatever methods work best for them, such as index cards, whiteboards, or, yes, even electronic tools. (Note: if having to maintain a tool for the Sprint Backlog slows down the Team, that is an impediment, and it’s up to the Scrum Master to help find a better solution.)

To ensure that the Team and the process improve every Sprint, it’s recommended that the Development Team include at least one action item from their previous Sprint’s Retrospective in the Sprint Backlog for their current Sprint. Many also include their Sprint Goal and even notes on Team member vacations. They might also add things to visualize blockages and interruptions and an impediments list.

These additions encourage the Team to focus on more than just delivering a collection of user stories. Instead, they’re achieving the Sprint Goal while making improvements that, in the mid-term, help increase their work quality and effectiveness.

When your Sprint Backlog is designed and prepopulated by an outsider (or electronic tool), it’s unlikely to contain any of these improvements.

The Sprint Backlog is also the Development Team’s forecasting tool. On a daily basis during Daily Scrum, they re-plan their work, helping them assess whether they have taken on more than they can actually complete in the Sprint. They then work with the Product Owner to decide which items to add or to drop as needed.

The Sprint Backlog loses its value if used for external purposes or for micromanagement. When leadership uses it to look over the shoulders of the people doing the work, even if it’s not to direct the Development Team’s actions, it often leads to overloading the Sprint Backlog with details that undermine and eliminate transparency.

At the end of the Sprint, the Sprint Backlog is finished, completed work is deployed, and incomplete work is returned to the Product Backlog wherever the Product Owner deems it should belong. Next Sprint Planning, a new Sprint Backlog is created.

Good Teams know that they own this. Great Teams experiment every few Sprints to find what they can do to make their Sprint Backlog even better.