Chapter 11
The Sprint Backlog

As you may have noticed by this point in the book, we’ve been around, or part of, a lot of development teams. We were eager to write this chapter so we could take a deeper look at the day-to-day activities of development teams and point out ways to improve how such teams work.

The sprint backlog represents those day-to-day development team activities. Let’s start our exploration of sprint backlogs by examining a situation Todd experienced while consulting as an Agile coach for an insurance company with a national presence.

The company had been transitioning from waterfall to Scrum for two years. (Yes, two full years of working to fully embrace Scrum. As you’ll see, even after all that time, they still had a lot to learn.) In their software development department, by the conclusion of sprint planning, each person on a development team was required to have a minimum of 40 hours’ worth of tasks, estimated per week in the sprint backlog. Tasks were to include development activities, time off, lunch breaks, and anything else that could happen during a work week.

Management had built dashboards that showed a summary of each developer’s total estimated time for a sprint, as well as the actual time that person had spent performing each task. The timesheet system was tightly integrated with the sprint backlog management system—-Microsoft Azure DevOps was the tool in this instance—so every task and every hour needed to be accounted for so that the billing system was representative of the actual time being spent. Scrum masters constantly badgered developers to update their tasks in the system so that management wouldn’t start asking questions.

Sprint productivity was a key concern of management and, in an effort to drive productivity, they created a metric called estimate vs. actuals. It measured the difference between the estimate a developer provided in sprint planning and the actual amount of time it took the developer to complete that activity. If a developer’s tasks deviated too far past the estimate, Scrum masters were required to facilitate a conversation between the developer and the developer’s manager about why the tasks were taking longer than the estimate. If tasks were completed earlier than expected, the Scrum master had to initiate a conversation with management so that the developer could be assigned more work.

Each development team as a whole was managed by a sprint burndown chart that showed a sum of all of their hourly task estimates and a trendline showing the remaining work. When the remaining work for the team was not trending in the right direction on the chart, the Scrum master was to bring it to management’s attention so they could figure out what the development team was doing wrong. Adding new tasks or product backlog items to a sprint was particularly frowned upon because it meant a deviation from the plan created during sprint planning.

A vast majority of the time, developer and development team estimates appeared perfect on the dashboards, and their sprint burndown charts always looked like they were on track. But nothing was getting done on many projects: Software wasn’t getting to production any faster than it had been before the organization started moving to Scrum from waterfall. Management brought Todd in to figure out why development teams weren’t getting anything done and why they seemed so good at estimating, but bad at delivering.

Todd made a point to speak to folks across the organization, from managers to development team members. In these conversations, management’s obsession with productivity became clear. Instead of owning the plan for a sprint and getting the work done together, developers concentrated on making charts look nice and getting tasks done by individuals. They spent a lot of time and effort making sure that their productivity metrics looked good—sometimes even fabricating numbers—so that management would leave them alone. Management didn’t understand why developers weren’t delivering anything and felt as if they were being lied to. The distrust between management and the development teams continued to grow.

Over several months, Todd worked with the Scrum masters and management to shift their focus from productivity to outcomes, which was no easy task. The key to making this shift was teaching the Scrum masters about alternative metrics they could use to quantify their progress for folks in management, about ways they could work with their Scrum teams and the organization to build mutual trust, and more about empiricism. In the end, the development teams gained full ownership over their sprint backlogs and started delivering. Management stopped requiring developers to estimate 40 hours of work every sprint and even abandoned their beloved burndown charts. These changes led to the beginnings of a culture that supported the developers in creating production-ready increments—instead of just trying to look busy.

The development team owns the sprint backlog, which contains the product backlog items that dev team members have selected for the current sprint. They add these items to it during sprint planning as they create an initial plan for the sprint. It contains a forecast of what the development team thinks the next increment will look like, outlines how the development team thinks they’ll create the next increment, and provides an initial plan for accomplishing the sprint goal. (Remember, things can and likely will change as the development team learns more about the work). The sprint backlog should be transparent to everyone on the Scrum team. Exactly how to create this transparency is up to the development team.

(Don’t confuse the sprint backlog with the product backlog. The product backlog is the product owner’s responsibility and it contains all the details for the future of your product. The sprint backlog, on the other hand, is a much smaller list of PBIs that’s owned by the dev team. It contains items that the developers intend to work on during the current sprint. The PBIs in the sprint backlog come from the product backlog, but the two lists are very different.)

The insurance company scenario illustrates one of the many sprint-backlog dysfunctions we’ve witnessed. Let’s examine some other common anti-patterns that can arise.