How to Read a Burndown Chart
How long do you spend talking about your burndown chart during your sprint retrospectives? Burndown charts tell you so much more than if you finished all the work in the sprint or not. From these charts, you can learn:
How well your team is estimating story points
How many injections occur during the sprint
How well your team is breaking down tickets
Bottlenecks in your team’s software development pipeline
We’ll walk through a few examples of burndown charts in this article and discuss what we can learn.
Burndown Chart Assumptions
As with any analysis, we need to verify that our burndown charts are based on clean data.
Done vs. Done Done
Burndown charts track when tickets are done. What does “done” mean as part of the software development lifecycle? For a SaaS platform, done means the ticket functionality (e.g., a new feature of a bugfix) is built, tested, and deployed to production. Each of these stages could be done, but the whole ticket is not “done done” until the ticket is out in production.
Your burndown chart won’t accurately reflect the whole software development lifecycle if tickets are closed before they’re “done done.”
Don’t Update Story Points Mid-Sprint
Story points are estimates, not commitments. As part of the sprint retrospective, you and your team should reflect on tickets that were greatly over or underestimated. Would a research ticket before implementation have helped estimate more accurately? Was there a hidden dependency that the team missed? Over time your team should improve at estimation, but only if you take the time to retrospect and improve.
Even if an estimate is off, developers should not change the estimate mid-sprint. This shows up in the burndown chart as a scope change. Story points are estimates, not actual effort counts. Use other fields like time tracking to track actual effort if that metric is essential.
Keep Tickets Updates
Updating tickets is one of the less enjoyable parts of software development but is crucial to accurate Agile process management. Developers should update in-progress tickets at least daily. Teams who make batch updates to all their tickets every few days or once a week will wreak havoc on Agile metrics like average time in progress, average WIP (work in progress), and overall ticket cycle time.
Batch updates (due to delayed updates) impersonate other problems in a burndown chart, so encourage your team to keep their tickets updated.
Chart Shapes
Now we’re ready to analyze a few burndown charts. Through this analysis, we’ll focus on overall chart shape as well as chart features. Your team’s charts will be unique and change sprint to sprint., so use the tools below to create a custom diagnosis and action plan.
In all charts, the y-axis is total story points and the x-axis is time. These charts won’t have units because story point totals and sprint durations vary between teams.
The Perfect Chart
We’ll start with the easiest chart. Take a moment to analyze the image above. What does this tell you about the team? If this was your team’s burndown chart, what would you celebrate during your sprint retrospective?
A few features stand out to me:
The team completed all work in the sprint (the trend line hits zero)
The last tickets were completed near the end of the sprint meaning the team didn’t under commit
There are frequent tiny drops which means small batches of work are regularly pushed out to production, leading to lower risk deployments and faster improvement delivery to customers
There are no upticks in scope which means no injections or scope creep
Notice that the absence of chart features tells us just as much as the chart features we see. Next, we’ll see a chart with a few negative features present.
Scope Creep
In the chart above, there are two circled features. What do these tell you about the team?
I see two main issues with this chart:
Mid-sprint (when the team already hasn’t completed much work), there are two significant story point injections
The team didn’t complete all work in the sprint
My guess is these two events are correlated. The incomplete work looks suspiciously close in size to the injected work. This team may have done an excellent job estimating their sprint capacity, but the injections increased the overall sprint size.
The solution is not to under-commit in case of injections. Instead, dig into these injections. Were they last-minute feature requests? Blocker level bugs? Hidden dependencies for work the team had already committed to? Injections disrupt sprints, so if you experience them, dive into the root cause of why the injections were necessary.
Batched Work
Lastly, we have what I call a Cliff Chart. The team completed all work in the sprint (which you should celebrate), but there’s an issue with the overall software development lifecycle. If a team is new to continuous deployment, two deploys a sprint may be a great success. For a team with multiple microservices and the deployment infrastructure to deploy frequently.
What is holding up work? Look into a few tickets to understand their state changes.
Are too many tickets put into progress then closed all at once? If so, talk with the team about limiting WIP and pushing tickets all the way through to production before starting another.
Are developers not prioritizing peer review? If tickets are stuck In Review for periods of time, talk with your team about prioritizing unblocking others before building new features.
Are these two drops actually one ticket each? If so, work with your team to break large tickets up into smaller, independent tickets for a smoother sprint and faster, lower-risk deployments to production.
Conclusion
Take a few minutes to look at your team’s last burndown charts. Do you see any trends or features described here? Do you think your team’s workflow is improving over time?
Burndown charts are a visual representation of your team’s software development lifecycle. Spend time during your next sprint retrospective to walk your team through the sprint’s burndown chart. It will be well worth the time.
If you’re interested in discussing your team’s burndown charts or learning more about Agile process improvement, please send me a note at brian@connsulting.io or schedule a time to chat at https://calendly.com/connsulting.