Caution: Developers Burning Down

In our opening story, the development team didn’t fully own the sprint backlog. Management dictated exactly how the dev team was supposed to create the sprint backlog and they put micromanaging mechanisms in place—constraints that created the illusion that everything was going as expected. The result was great looking charts but sloppy work and low morale.

You may find that management has a hard time coping with the changes that Scrum brings. They may search for ways to measure whether Scrum is succeeding. Executives often ask managers to find ways to prove that Scrum is working and worth the investment. They see the sprint backlog as the artifact that they can use to manage productivity and gain insights into how their employees are performing.

Not knowing any alternatives, managers often fall back on old ways of measuring performance that they’ve used for years (such as burndown charts and measuring estimates vs. actuals). Sprint burndown charts are a complementary Scrum practice that development teams can use as a way to inspect their sprint backlog. But we (your humble authors) have largely abandoned the practice because the bad behaviors we’ve seen associated with such charts far outweigh the benefits.

Our opening story described dev teams creating and updating sprint backlogs out of fear. In that situation, Todd overheard dev team members covering for each other and discussing ways to make the sprint burndown charts look the way management wanted them to. He often heard the Scrum masters helping out, clearly trying to keep management from intervening with the teams. The Scrum team spent a lot of time figuring out how to make their tasks and estimates create a good-looking chart.Teams went as far as cutting corners during development so that their actuals met their estimates. Sprints ended with a ton of unfinished work that was marked and displayed in sprint reviews as finished. Management had created an environment where the dev teams’ priority was making the charts look good, instead of producing a done increment of potentially shippable product by the end of each sprint.

As we’ve said, the sprint backlog should be owned and managed by the development team. Whether it exists virtually or on a physical Scrum board, it’s a shared workspace that the development team uses to continually and collectively plan and coordinate their work. It’s where they create a plan that will help them, as a team, build a high-quality increment and achieve the sprint goal by the end of the sprint.

If your organization’s management team has become obsessed with the sprint burndown chart, shifting focus away from it is likely a sensitive topic, but one that you need to address. Often the best way to solve this problem is to offer them an alternative way to get the info they need to feel comfortable. (Ideally, a done product increment will become the primary measure of progress for your organization.)

Many of the teams we work with use digital tools that provide sprint backlog management capabilities. But we love physical Scrum boards and take every opportunity we can to teach development teams the benefits of using them. We discuss Scrum boards in Chapter 12, ​Reclaiming the Daily Scrum​, but we love the power of physical boards so much that we’re going to promote them in this chapter, too.

In our experience, having a physical Scrum board is both wonderful for the development team and provides great insights to folks outside of the Scrum team, letting them see what’s happening in the sprint backlog. We’ve seen this increased transparency cause management’s obsession with burndown charts to fade.

Here’s an example of a physical Scrum board that represents a sprint backlog:

When you suggest to the development team that using a physical Scrum board can be a great way to make the sprint backlog more transparent, you may get some pushback from people who feel that maintaining a physical board and a board in a digital tool is just duplicating effort. Don’t force the dev team to create a physical board. After all, they own the sprint backlog and we, as Scrum masters, want them to take ownership of how they manage and visualize their work. Here are some benefits of a physical Scrum board that you can discuss with your teams:

• Imagine how much better the daily scrums could be if they’re held while you’re all standing in front of the board while actively changing and managing the sprint backlog as a team.

• A physical Scrum board really helps create transparency. If managers want to know what’s happening, they can just come look at the board. (This applies to digital Scrum boards, too–they also increase transparency.)

• When you’ve been grappling with a tough task or product backlog item, it’s really satisfying to physically move a sticky note from the Doing column to the Done column.

• As opposed to navigating a digital tool, glancing up at the board is an easier, faster way to double-check what development teammates are up to.

Ultimately, the development team decides how best to manage their work. If they decide to stick with a digital tool (a perfectly valid option), work with them to figure out how they can get the above benefits using their tool of choice.

Encouraging the development team to use a physical Scrum board is the first step in easing management’s sprint burndown chart obsession. Once the dev team adopts a Scrum board, you’ll need to continue to work with the folks in management to help them understand that the best way to cope with complexity is through empirical process control: transparency, inspection, and adaptation. (See Chapter 3, ​Breaking Bad Scrum with a Value-Driven Approach​ for a refresher on empiricism.)

The next time someone in management asks for a burndown chart, consider having the development team explain the physical Scrum board to them. This will give the manager new insights into how to get answers without disrupting the team. And hopefully, the board will include all the info needed to answer questions that your leadership team commonly asks. If it doesn’t, that’s a great opportunity to inspect and adapt the board to enhance transparency and build trust between the development team and the manager.

When dealing with complexity in day-to-day activities performed by the development team, organizations can leverage self-organizing development teams in order to solve tough problems. Obsessing over the sprint burndown chart is a form of micromanagement that inhibits development teams from truly self-organizing.

Changing the way your organization works is no easy task. You can help ease the pain of such changes by providing alternative ways to give people the info they need to feel comfortable.