Becoming a Burndown Whisperer

April 25, 2019
Categories: Corporate
Reading Time: 3 minutes

Written by Josh Ettwein, Director of Software Engineering, MatrixCare

As Agilists and practitioners of Scrum, there are several metrics, charts, and the like that we use to determine the effectiveness of our team. One of the most common is the venerable Burndown Chart. Everyone (or a lot of us, I suppose) uses them, but I rarely come across a Scrum Master or Scrum team that really knows what their burndown charts are telling them.

I can’t count the number of Scrum teams I have worked with that say, “yeah, we look at our Burndown, but we don’t do much with it, other than joke about how bad it looks.” This is often because the team doesn’t understand the symptoms that your Burndown is presenting to you, and thus, you can’t adjust behavior accordingly.

We all know what the “optimal” Burndown chart should look like, but we rarely have it work out that way in practice. Below are some common Burndown chart “shapes,” and for each, a few common causes that you might look at when evaluating your team’s performance.

The Endless Plain of Despair

I see this one on my current scrum team pretty often. The chart looks like a continuous line, stretching out the right, often stepping up, rarely trending downward. There are several causes of this. In my current team’s case, it is a result of pulling in stories mid-sprint. It can also be caused by the team re-pointing/rescoring stories mid-sprint. If you have a chart that looks like a step function, take a look at how often the team pulls stories into the sprint post-sprint commitment, without removing others to compensate.

Waterfall in Scrum Clothing

This chart looks like the line travels out very flat to the right, and then suddenly, falls off a cliff, and miraculously, all of the stories close at the end of the sprint. This one is widespread, and most commonly so with teams that are very recently transitioning from a waterfall methodology to scrum. They’re going through the motions, but they often have done little more than hang some scrum terms on loosely similar waterfall processes. This is usually caused by teams that work on finishing development on all the stories and then kicks it over the wall to QA en masse. The other cause of this is often teams that are not doing an excellent job of keep story sizes small. When the team is working on a small number of gigantic stories, nothing closes until right at the end of the sprint, and then suddenly, everything is (hopefully) done.

Afraid of Commitment

Burndown charts that show the team burning stories down underneath the optimal line look like they are knocking it out of the park. At least on the surface. The executive team will say, “wow, these guys are overachievers!”, When in reality, they are probably sandbagging. They may not be doing it intentionally, but they are almost surely committing to less work than they can handle. It is also sometimes a situation in which the Product Owner is not doing their job, and does not have stories ready for work when the team is prepared for them. Another cause of this chart shape is that that team has grossly overestimated the level of difficulty of the work involved. As a result, stories are being closed much faster than expected.


If you consistently, sprint after sprint, see a chart in which the team is at times over the line, and at times, under, generally meeting their commitments with little to no “thrashing”… congratulations! You have a great team. If it ain’t broke, don’t fix it.

I hope these insights will help you to become the Scrum Master or Product Owner in your company that everyone else comes to when they can’t figure out what is wrong with their Scrum team.

Want to learn more? Let’s connect!

Josh Ettwein
Josh Ettwein

Josh Ettwein has served as Director of Software Engineering at MatrixCare for the past four years and is a highly pragmatic technology leader with a focus on delivering high-quality, intuitive software using agile practices. Josh is interested in building innovative products and services, and creating and growing great engineering teams. In the past, Josh has provided engineering and product development leadership on development of large-scale web, mobile and SaaS-based platforms, using a variety of technologies and languages.

Back to blog
Share this page

Learn more about how our services can help you succeed.