Why use a Sprint Burn-down chart?
A Sprint burn-down chart is a great way for a team to measure their own progress in a Sprint. It helps to maintain a sustainable pace by visualizing progress. It helps to pay attention to finishing rather than starting work. And it helps produce team level transparency, much like a score board does for any sports team. While it is not official part of Scrum anymore, it’s still a great practice to use.
Notice, I never said “manager” or “team lead” in the above. For a self-organizing team to be, well, self-organizing, it needs the right tools. A Sprint burndown is one simple and effective tool to aid self-organization and help a team self-correct when progress is stalled. All too often I work with teams that struggle measuring their own progress. In The Three Questions in Your Daily Scrum That Aren’t Working I talked about how you can have a Daily Scrum or standup without saying the three questions at all. The key is in great visualization.
I’d like to share the three most common dysfunctional Sprint burn-downs I see that tell me to look beyond a funny looking chart. Its not just about seeing this type of chart one time. Its about seeing the same chart every Sprint. When these charts are a pattern for a team, I know to look deeper. If you’re an agile coach, manager or team member looking to help a team self-correct, read on…
The Flatliner
This chart is by far the most common I see. The reasons for it are numerous, but the most common is that teams just aren’t paying any attention to it. If a team doesn’t find value in the burndown then it makes complete sense for it to look strange. Not paying attention to the Sprint burndown is completely fine if the team has other ways of measuring progress and doesn’t regularly spin out in the middle of a Sprint and fail to deliver half of what the intended. So that’s exactly what I look for beyond the flatline. I look at other evidence the team is staying in sync and finishing small chunks of work regularly. I ask how their standups go and if they do anything to resolve impediments. I ask how they break down work during planning. I look at the product backlog to see if they understand the requirements before starting work.
Often teams with the flatliner don’t have a good understanding of the requirements ahead of Sprint Planning, they divide and conquer work spending little time breaking work into smaller pieces that can show progress. They get used to the regular impediments and when they answer ‘the three questions’ no one says anything if a team member has been working on the same thing for five days. In some cases, the teams are pulled off mid-Sprint or even working on side projects that soak up valuable time. The flatliner is a symptom of many deeper and more important problems for getting work done.
Easy money
If people outside the development team are keeping a watchful eye on their internal metrics, the team might produce the “easy money” Sprint burn-down. It’s a complete fabrication. Notice how the the path of completion follows the ideal trend line perfectly. If a Sprint burndown looks too good to be true, like easy money, it probably is. When I see one that looks too good, I look at the burn-downs of other sprints in search of a trend.
If under pressure from management to keep a perfect burndown chart, the team will build a perfect burndown chart. However, transparency may suffer with a false sense of progress and stability.
The Slacker
In this example all the work got done well ahead of the Sprint Review. Great! There’s nothing wrong with finishing early, but a deeper problem may exist if this burndown represents a trend. Why wouldn’t the team pull in a little more work when the realize they’ll finish early? Is this team just lazy? Are the slacking off on the company’s dime? Do they just want to play video games in the lunchroom the last three days of the Sprint? Maybe, but I’m guessing it’s something else.
Have they been punished for not completing everything? Some still believe that Scrum asks you to “commit” to finishing all the work you pull into a Sprint. They’ll even shame a team and say they “failed the Sprint” if something carries over. When this is true, each Sprint feels like a mini-death march. If you’re curious why the word “commit” changed in the Scrum Guide you should read Ken Schwaber’s post Empiricism, the act of making decisions based on what is.
Another thing I would look for is if the team completes and visualizes QA activities as part of the work represented in the burndown? If not you might only be seeing part of the story. They could be leaving the last few days open to work with QA on bug fixes and plan for it.
Wrapping up
Whether you’re an agile coach, team member, project manager, or technical lead, keep a curious and open mind when looking at these graphs. If something looks interesting, suspend judgement and ask the team what their thoughts are. You might get a lot more insights directly from the people involved.
Have you seen any other common burndown patterns? Leave a comment below, I’d love to hear about them.
