The burn-down chart is a tool in the agile Scrum framework to unearth inefficiencies in a team and improve towards greater agility. In an agile team or organization you should know about this chart and how to construct it.
The Basics
The burn-down chart is a simple graph. It shows how the remaining work a team has to deliver “burns down” (ideally to zero remaining work). On its x-axis you have the time in days – typically the work days of the sprint. For a two-week sprint starting and ending on Wednesdays, it would have ten days: Thu, Fri, Mon, Tue, Wed, Thu, Fri, Mon, Tue, Wed. On the y-axis you have remaining work in story points. If your team typically delivers between 5 and 24 story points, you’d have the numbers from 0 to 24 (+ some headroom, say up to 30).
After sprint planning you will know the sum of story points your team plans to deliver at the end of the sprint – let’s say 21. Mark that number on the y-axis of your burn-down chart. Now mark the end of the sprint on the x-axis. Finally draw a straight line from the point on the y-axis to the point on the x-axis.
Your burn-down chart is now set up and ready for action ?. The line shows the theoretical ideal burning down of your work over time, if your team would make exactly the same progress every day. Of course we will seldomly be on that theoretical line (in fact, being right on that line points at problems as you will see below), but it acts as a guide.
Everyday after your daily scrum you will look at the progress in the sprint backlog. You count the number of story points not yet “done” and mark that number on the specific day in the burn-down chart. Connect yesterday’s and today’s point by a line – use a different color than for ideal to make the two lines easily distinguishable . That way you add one data point per day.
If you use a software tool to manage your backlog (like Jira, Pivotal Tracker, Scrumwise or others) you most likely automatically get your plotted sprint burn-down chart. You should however check it regularly to make sure it records the right data. If you don’t enter your estimations at the beginning of the sprint or forget to “close” your sprint in some tools, you could end up with useless charts.
At the end of the sprint you will have two lines spanning all days of the sprint. How your daily plotted line looks will tell you a lot about where the team could improve.
When Reality Hits
In theory, this is easy to understand. But in practice I see Scrum Masters and teams struggle with real issues not covered by this simple explanation. What counts towards “burned-down” work? What do you do if the sprint backlog changes mid-sprint? What if the chart suddenly “burns up”? What if my line doesn’t hit 0 story points at the end?
What counts towards “burned-down” work?
You must only count “done” user stories as outlined by your definition of done (you should have a definition of done – or DoD – but that’s a topic for another day). “Done” means that the story could be released to your customers immediately. Let me give you a few examples together with whether they count as burned work:
- A user story (of 5 story points or SP) on which no work has started yet => 0 SP burned
- A user story (of 5 SP) in implementation => 0 SP burned
- A user story (of 5 SP) that is fully implemented and just needs testing => 0 SP burned
- A user story (of 5 SP) that is implemented & tested, but still has to be accepted by the Product Owner => 0 SP burned
- A user story (of 5 SP) that has been accepted by the Product Owner => 5 SP burned
You see, we’re pretty strict on what counts as “burned-down work”. So no-half stories, no 99% finished stories, no not-yet accepted stories – only the story points of “done” and accepted user stories are counted.
The reason to count like this is not to discredit the effort the team puts into their work, but to avoid common inefficiencies and increase the team’s agility. Trust me, it makes sense. If you want to know more, feel free to request an article specifically and why only “done” stories count towards burned-down work.
What if the Sprint Backlog Changes Mid-Sprint?
Ideally we want the sprint backlog to remain pretty fixed after the sprint planning. The sprint is the only little island of predictability and focused work we give the Scrum team in the midst of an always flexible product backlog. But agility assumes that we can never fully predict the future – things happen. Consequently a sprint backlog can change more or less radically.
The most common reason for a changing sprint backlog is new insight from the team into certain user stories. They might have underestimated the complexity or have overlooked a crucial aspect during refinement. They might also simply have learned a bit more about the requirement or their technology, so that they adapt their plans. Often this leads to a changed estimation for one or more user stories – sometimes even to an addition of new user stories. (Side note: these changes are all triggered by the development team and should not change the overall sprint goal.)
If the sum of story points in the sprint changes, you also have to plot that in the burn-down chart. Let’s say you started your sprint with 21 SP. Then the team realized during implementation that a 3 SP story is actually 5 SP. You now have a total of 23 SP. If no other work was completed on the day the team re-estimates the story, your burn-down chart simply burns 2 SP upwards. Should your team have finished another 3 SP story on the same day, you burn-up 2 SP and down 3 SP to end up burning 1 SP total for that day. However, to keep the burn-down chart useful, actually plot a vertical line upwards for the added 2 SP and then a vertical line downwards for the completed 3 SP. This allows us to actually see what happened later.
Mid-sprint changes in the amount of story points are not uncommon. You should simply plot them as outlined above. Just make sure to leave some headroom initially, in case your chart burns “up” above your initial starting point.
What if the Burn-Down Chart Burns “Up”?
As you know from the previous section, a burn-down chart – despite its name – can actually also burn “up”. In fact this burning up gives us important indications when it comes to improving the workflow of the team.
A burning up of the chart can have many reasons. We already mentioned new technical insights by the team, overlooked clarifications of requirements or simply too optimistic or pessimistic initial estimations. Occasionally the Product Owner might negotiate a change of the sprint scope with the team (while keeping the sprint goal intact). (Side note: if the sprint goal is no longer valid, the cancellation of the sprint followed by a regular sprint planning for a new sprint might be a better option). Sometimes the Product Owner pushes in new stuff without letting other user stories drop out of the sprint backlog – of course we don’t want this, but let’s face reality for once. At least we have the burn-down chart to make such scope creep clearly visible in a later analysis, should it have caused release dates to slip or quality to suffer.
Another source of added story points could be an unexpectedly well going sprint. This can leave the team with no more work on the sprint backlog while they still have a few days left until the sprint ends. While the team might just celebrate and take an impromptu holiday, the more common reaction is to pull in the next user stories from the top of the sprint backlog. In that case your burn-down chart will also actually burn “up”.
So the chart can indeed burn upwards. Just make sure to refrain from aggregating ups and downs – rather show up and down as two vertical lines.
What if we do not hit 0 SP at the end of the sprint?
It happens that a team cannot achieve their sprint forecast and end up with unfinished stories in the sprint backlog. This is NOT a “failed” sprint – it is simply a learning opportunity to improve your forecasting. The burn-down chart actually shows such learning opportunities clearly, if the plotted line does not reach 0 SP.
Not hitting 0 SP at the end – while potentially an indicator for possible improvement – is totally fine for the burn-down chart.
All in all the burn-down chart is a wonderful tool that is fairly easy to create and understand. But how can it help a team improve? That’s next.
How to Learn from Burn-Down Charts
It is a good practice to review your burn-down chart with the whole Scrum team during your retrospectives. Often the team can immediately recognize unusual graphs and spawn a discussion about what caused it in the last sprint. It is crucial that the Scrum Masters steers such conversation away from dwelling on problems and towards learnings and specific actions to improve in the next sprint.
A proven technique to augment the burn-down chart is to let the team recollect important events during the sprint. You can use the x-axis of the chart for that and let team members put sticky notes with significant events on that timeline. A similar approach is to ask the team for their mood during each day of the sprint. Overlay a y-axis with a scale from -5 to +5 and let everyone put a dot for each day. Usually you see certain days on which the whole team’s mood was very high or low. Unsurprisingly this sometimes coincides with significant patterns of the burn-down chart.
The Scrum Master should learn to recognize typical burn-down chart patterns. She can point them out to the team along with an initial assessment of what this could mean. One very typical pattern is the “stinger”: the chart runs almost horizontal for most of the sprint only to sting down to zero on the last day. This pattern usually points out a problem with accepting stories too late – a typical lapse of unexperienced Scrum teams. The Scrum Master should have typical fixes ready to propose to the team. With accepting too late a common solution and improvement is to do in-sprint inspections after the daily scrum. If you want to learn to recognize burn-down chart patterns and fix the underlying problems, download my poster Burn-Down Patterns (it’s free).
Extending the Use Beyond a Sprint
While single sprint burn-down charts are very useful already, they can tell you even more if compared over time. Collect your burn-down charts and put them next to each other (e.g. for the last 12-16 sprints). You will be amazed at the new patterns you will find. Having the entire history of several months can tell you how the team improved (and we all know that improvement doesn’t mean merely increasing velocity), whether they learn from mistakes and if there are repeating patterns out of the team’s control. More often than not these overarching insights will surprise you.
In order to compare burn-down charts over several months, you should think up-front about a certain level of standardization. Without comparable x- and y-axes or similar colors, patterns are much harder to see. I will cover this in the next section.
Practical Tips to Create a Burn-Down Charts
And here come a few practical tips for creating useful burn-down charts in the physical or digital world. Feel free to skip ahead to the “Summary” on your first read.
I already mentioned software tools that automatically generate burn-down charts. Make sure you check these charts early on for validity. These automatic chart generators can only work if you feed them the right data: estimated user stories, up-to-date states, correct user story assignment to certain teams and timely started/stopped sprints. Just make sure to check the generated charts during your first few sprints, lest you’re surprised by useless charts after a few months.
We agile coaches just love pen & paper charts! They’re simple to use, easy to understand and can be adapted to almost any situation. Granted you cannot use pen & paper in all situations, but if you can, consider using it.
I like to use regular flipchart paper with the little squares on it for burn-down charts. I fold it in half to get two charts for two sprints. Then I measure how many squares my standard x-axis and y-axis will have. Try to guess an upper limit for the story points per sprint and do the division of your y-axis. Also decide on the colors you will use for the ideal line and the actual plotted data. I try to make it three colors: one (usually black) for the axes and writing, one (green?) for the ideal line and one (pick your favorite) for the actual data.
You can pre-fabricate these chart templates or draw them right after your sprint planning. Don’t forget to add important data to make them comparable later on! At least write the sprint number (“Sprint #42”) or dates (“Weeks 5-6”) and the sprint goal on top. Whether you use numbered sprints or weeks/dates is up to you – weeks/dates makes it easier to compare with other teams that might have started earlier or later. The sprint goal can also be written on a sticky note and added to the chart. Also write the initial amount of story points next to the starting point on the y-axis.
During the sprint make sure to explicitly draw burn-ups separately from burn-downs. You might even make distinctions for burn-up due to “re-estimation” and burn-up due to “scope creep”. The same for burn-down: you might want to visually distinguish burn-down do to “completing” from burn-down due to “de-scoping”. I like to also note a few words in the graph about what happened at these points.
After the sprint review at the end of the sprint, note the actually “done” story points (aka “velocity”) onto the chart and take it to your retro. For archiving afterwards, you can roll up the flipcharts and use an empty beer crate to store them.
Even if you use a chart in Jira, you might want to consider to print it out for the retrospective. It’s easier to augment the chart with mood scatter plots or significant incidents as outlined above. For archiving graphs in software you can always simply collect screenshots, should the tool not allow to put them side-by-side nicely.
Summary
Sprint burn-down charts in Scrum are an important tool for the self-assessment and improvement of the team. They help to unearth inefficiencies and improve towards greater agility. You now know the basics to help your agile team or organization make the best of burn-down charts. Make sure you also learn how to recognize basic burn-down patterns
