Burning Down the Work!

Ilustration of a ten year old girl setting her doll house on fire.
Burning down work is a positive thing. Image from Midjourney v8.1

When you work in the technology business, you spend plenty of time building things. The remainder of your time is fixing things. What is funny about this dynamic is that you are fixing not only technological problems but also broken business processes, psychological damage from toxic leaders, and glitches in organizational communication. It is a rough assignment. Problem-solving is part of the job description, and sometimes you feel like a genius and other times you wish you could climb into a cave. It follows you every day. As I have matured as a scrum master, I have used metrics to help my teams improve and solve problems. This week, I want to cover one of these metrics to diagnose problems in how the team completes work- the burn-down chart.

The Double-Edged Sword of Business Metrics -

The word "metrics" often carries uncomfortable connotations. In a business context, it is often used as a tool for punishment. Missed sales figures could mean unemployment for a marketing professional, and a network engineer without 99.9% uptime is considered incompetent. The misuse of metrics in this fashion has a name: Goodhart's law. First, proposed in 1975, it states that when we apply pressure to a system, statistical regularity breaks down.

When Data Weaponizes -

If elected officials or business leaders expect to see a certain number in their dashboard, the people being measured will do everything in their power to hit that number. Data will get fudged, perverse incentives will arise, and all the work in the organization will get sacrificed to hit the expected metrics. It is a vicious cycle, and Goodhart's law has featured prominently in many business disasters over the years, including the sales fraud at Wells Fargo Bank and the collapse of Enron. That is why I am careful with my use of metrics: I do not want people to feel threatened by how I track progress or performance.

The Burn Down Chart -

Here is where the burn-down chart becomes a helpful tool for success. The team can see their performance in real time, and during retrospectives, they can ask how they could improve. A typical burn-down chart consists of two columns and as many rows as there are days in the sprint. The first column is the actual number of story points left in the sprint. The second column is the ideal number of story points to be completed.

A sample chart might look like this –

Day Actual Ideal
Day 1 31 31
Day 2 31 27.9
Day 3 31 24.8
Day 4 23 21.7
Day 5 20 18.6
Day 6 17 15.5
Day 7 14 12.4
Day 8 11 9.3
Day 9 8 6.2
Day 10 5 3.1

It generates a chart like the following -

Based on this example, the team was off to a slow start but began completing work at a steady pace. We did not finish all the work, but we maintained a predictable pace. A mature scrum team can learn from this situation and figure out how to get better at delivery.

In this next example, the work is not getting done until the end of the sprint. If the team has quality professionals who must sign off on the work, they are often treated as the bottleneck for the team. On day eight of the sprint, all the work lands in their lap, and it is profoundly unfair because the sprint's success or failure depends on the quality of the people verifying the work. It creates conflict between quality people and developers on the team due to the pressure to complete work.

The next chart is a very different situation. The team finishes all of its work and does not add more to its efforts. Clearly, the team underestimated its capacity to complete work and did not have enough backlog to add to its efforts. In this situation, the Product Owner should provide more work for the team, or the team could take on more work.

This next burn-down is frustrating because the team is being held hostage by stakeholders who do not respect sprint goals. It is a classic example of people demanding quick fixes or features because they are the highest-paid person in the organization. The situation violates the agile social contract and will undermine the team's morale. The damage occurs because the team never really finishes anything and has nothing to demonstrate at the end of the sprint.

These are four major trends you can identify with a burn-down chart. If you would like to learn more, I recommend Mike Clayton's online tutorial, available here. If you have any more suggestions, I would love to see your examples.

Protecting Your Sprint -

Using metrics to track behavior and create positive trends will help you improve your team in an environment of psychological safety. You can also avoid Goodhart's law if you use these metrics to track progress rather than institute quotas. With burn-down charts, you have a way to encourage continuous improvement and solve problems around your business.

Until next time.


Edward J Wisniowski

Edward J Wisniowski

Ed Wisniowski is a software development veteran. He specializes in improving organization product ownership, helping developers become better artisans, and attempting to scale agile in organizations.
Sugar Grove, IL