A Scrum team can learn a lot form sprint burn-down charts. I want to help you recognize typical patterns, understand what causes problems and how to resolve these issues. For continuous improvement in Scrum you need to be able to read the patterns in your burn-down charts.
What is a Burn-Down Chart?
If you need a refresher and what a burn-down chart is and how it works, read What is a Sprint Burn-Down Chart? first.
How to solve problems with Burn-Down Charts?
A burn-down chart is one of many great tools to help a Scrum improve. It allows you to see potential problems earlier than you usually would thereby giving you the chance to fix things quickly and cheaply. The chart also acts as a meter for your experiments and continuous improvement actions: did they have the desired impact? While a single burn-down chart of one sprint can already unearth potential improvements, comparing the charts of multiple sprints can even give you deeper insights.
A word of warning: A burn-down chart is NOT a management tool to see how a Scrum team is performing! Just like velocity a burn-down chart should be primarily used by the team internally to detect problems and measure the impact of improvements. The only sensible use of burn-down charts for management is by watching typical anti-patterns disappear over team while a teams mature and become more agile. An agile coach would typically monitor burn-down charts to see whether a team is improving and pick their coaching methods partly due to what they see in the history of charts.
The big reason for burn-down charts is to have them as a feedback tool for the Scrum team itself. And to be able to interpret this feedback, a Scrum Master or Agile Coach must be able to recognize certain (anti-)patterns.
Recognizing Typical Burn-Down Patterns
You can read many things from burn-down charts. Here are a two common patterns that you might encounter. Learn them, learn what problems they represent and how to fix them.
If you know what a burn-down chart is, you also know it has an “ideal line” to compare your team’s Sprint to. And if it’s the ideal line, the team’s performance should be better if the burn-down is closer to the ideal line. That is correct until you get to the extreme case where the team’s burn-down chart looks exactly like the ideal line! If your team is dead on this line, don’t celebrate to early: your team is probably faking the numbers! In my vast experience with teams, no great team ever exactly hits that line – it’s just a statistical improbability. But if you see that happen, look deeper at why your team is faking the numbers. Fake numbers do not help anybody improve and just sweep problems under the rug. In many cases teams do this out of fear, because reporting “bad numbers” has been discouraged in the past. They’d rather make everything look good than confront themselves (and their superiors) with the dirty truths and start to fix things.
The solution to fixing this anti-pattern is most likely to establish agile values. For example courage, openness and respect are values that lead a team to being honest with their burn-down charts. Also coach management to teach them the value of a failure culture and the respect for people openly admitting problems. Sometimes managers have a wrong Menschenbild (view of other human beings) that prevents them from accepting these values (read up on X and Y management styles). Establishing agile values and such an agile mindset is the most fundamental and most difficult job an agile coach has to deliver! This burn-down chart anti-pattern shows a fundamental problem in agile adoption in a company and should not be neglected.
A very common pattern in burn-down charts is “the stinger”. It is characterized by an almost flat line throughout most of the Sprint only to rapidly sting down towards zero on the last day. Though it could look as if the team had been slacking off until the last day, this is usually not what happened. The pattern is often caused by late acceptance of user stories by the Product Owner. Having said that, it might not be the Product Owner’s fault. Let me describe two typical cases causing late acceptance:
The first common case is a Product Owner only starting to accept user stories on the final day of the Sprint or (worse) during Sprint Review. It is a widespread misunderstanding among team’s new to Scrum that acceptance of stories would happen during the Sprint Review event. But the Sprint Review has a completely different purpose (which it can’t fulfill if abused as an acceptance meeting). Even if the stories are accepted on the final day prior to the Review event, we still have a big problem. Imagine a user story is still missing something and cannot be accepted (and released to the customer)? If you have to reject a user story on the final day of the Sprint, the development team has no chance of finishing this user story in the current Sprint! They would have to take it into their next Sprint and delay releasing to the customer by another 1-4 weeks. The rejection might also come to a user story which was finished early in the Sprint and now the developers have to undo a few other things they already built on top of that feature. In any of case it makes total sense to have an acceptance/rejection of each user story as early as possible. A Product Owner should accept/reject finished user stories at least once a day! Some teams establish a time-slot called “In-Sprint Inspection” to present finished user stories to the PO in order to get acceptance.
The second case this anti-pattern appears is if a team multi-tasks. They start to work on all user stories of the Sprint on day one and work on them in parallel. They work on this a bit, then on that and finally finish most user stories towards the end of the Sprint. Agility discourages multi-tasking, because it is inefficient, stressful and error-prone. (If you’re not convinced that multi-tasking is a stupid idea, just google.) Encourage your team to tackle one user story at a time – finish it before you start the next. Focus is the goal. Sometimes the tool of “work-in-progress limits” (WIP limits) from Kanban can help establishing focus again.
Wrapping up
I only talked about two typical patterns here, but I prepared a cheat sheet with more burn-down chart patterns for you to download. Feel free to print here it for your teams. Learn to recognize these patterns and help teams to improve.
What patterns do you see in the burn-down charts of your team?