What is a Burndown Chart: Agile Tracking Guide

Have you been a part of a sprint where your team is unable to complete all of the deliverables? Deadlines are fast approaching, and tasks seem to be accumulating quickly. This is where I learned about the usefulness of burndown charts. Burndown charts changed the way I tracked agile projects.

Burndown charts are a visual representation of work remaining across time to complete the work. You can think of a burndown chart as a countdown of the remaining work. If you are looking to complete your PMP certification training, understanding burndown charts and agile tracking tools will be a key component of modern-day project management. Burndown charts help teams know if work is going to be completed on time and help teams work through problems that may derail a complete sprint.

For agile teams, burndown charts are the equivalent of a heartbeat monitor. Burndown charts have work remaining on the vertical axis and time on the horizontal axis. There is a chart that can be created to represent an infinite amount of time. That is the beauty of the burndown chart.

Most charts show two lines. The ideal line for remaining work starts at your beginning total (work) and ends at zero at the end of the sprint. This line illustrates perfect, albeit unrealistic, progress. The actual line for your remaining work shows the actual performance of your team, as this line is updated daily with closes. A significant gap between these two lines suggests there is an area of concern.

In my experience, the greatest benefit of the burndown chart is the transparency it creates. There is no need to give long-winded status updates at daily stand-ups, as my team has a direct and clear illustration of where the team is at. This honesty is, in particular, valued by the stakeholders. The burndown chart leaves no room for vague updates, as there is no way to obscure the burndown chart where one stands in relation to the timeline.

There are two main types of burndown charts to be familiar with.

Sprint Burndown Charts

Sprint burndown charts measure a single iteration, which will usually be between one and four weeks. The horizontal axis shows the days in the sprint, and the vertical axis shows the remaining work in terms of either story points or hours. Each day at the stand-up, we update the chart with the stories that we have finished.

These charts pose an important question: are we going to finish everything we said we would? If your actual line is above the ideal line, that means you are behind.

Product Burndown Charts

Product burndown charts look at a wider scope by tracking the total product backlog across several sprints. The horizontal axis represents the number of sprints rather than days. This aids product owners in visualising progress and estimating release dates.

I use product burndown charts when attempting to plan a release over a timeframe of 3 to 6 months. It indicates if our velocity is in line with the planned release date, or if we must revise our goals.

Epic Burndown Charts

Epic burndown charts follow large features which span multiple sprints. They are excellent to use when tracking significant initiatives that require prolonged team focus and effort. The chart tells you if you are making enough progress on that complicated feature or if it is turning into a bottleneck.

Knowing the crucial elements of burndown charts aids in quick and accurate reading of them to determine issues that are present. The horizontal axis reflects your timeline; for sprint burndowns, this means your days, while for product burndowns, your sprints.

The amount of work yet to be done is shown on the vertical axis. Teams can choose to measure remaining work in story points (which I prefer) or hours. Relative to time estimations, story points capture complexity and uncertainty better. In this case, a five-point story could require two hours for one developer and eight hours for another.

Your baseline is represented by the ideal line. It is calculated simply: total work divided by available time. Thus, if you have 40 story points and a 10-day sprint, you will have to complete 4 points each day. This will result in a straight, diagonal line from the beginning to the end of the graph.

The ideal line is not as important as the actual line. This line is most often revised after each day's standup. It reflects the work done. The actual line of the graph will not be perfectly ideal, and that is ok. It is a problem if the actual line is significantly different from the ideal line; this is a problem that will need to be addressed as soon as possible.

After a while, it will be easier to read burndown charts. If the actual line is above the ideal line, your team is behind schedule. The wider the gap, the more severe it is. If the gap is small, it will likely close on its own. If the gap is going wider, it will require someone to step in and offer help.

If the actual line is below the ideal line, then you are ahead of schedule. This means that the plan is likely overestimated. This is a good conclusion to have; it will help future efforts of sprint planning become more accurate. On the other hand, if the team consistently finishes tasks before the set deadlines, it could mean that you are not challenging the team enough.

Sections on the graph that are flat are days with no progress made. Lack of work completed isn't always negative. It could be that the team got blocked waiting on work outside the team. Or it may be that a complicated story may take multiple days to complete. The important part is to identify the reason for the flat day line.

Large, steep increases in the line mid-sprint indicate scope increases. Someone is adding work to your committed sprint. It's true that the agile values allow for change, yet constant scope changes disrupt the purpose of sprint planning. Make note of these changes and bring them up in your team retrospective.

Many teams wonder whether burndown charts or burnup charts are more useful. A burnup chart shows the work that has been completed and rises to the total work that needs to be done. Conversely, a burndown chart shows the work that still needs to be done, and the line goes down to zero. In each case, the charts represent the same information, but in a different way.

Burnup charts show scope changes more clearly because total work and work completed are both displayed. If the scope increases during the sprint, the line for total work jumps. This clarity helps to explain to the team why work remained.

I personally prefer burndown charts because the countdown invites motivation. On long-term goals, the ability to see scope changes becomes more important, so burnup charts are ideal for that purpose.

The primary benefit of using burndown charts is gaining an understanding of progress within the project. Additionally, these charts are designed for non-technical users, as little to no explanation is needed to help them interpret the line showing whether progress is on track, ahead, or behind.

When a line is diverging from the ideal line on the third day of a ten-day sprint, early detection of problems is crucial to the success of the sprint. Gaps from the ideal line are of critical importance to informing the sprint framework. If the gaps are discovered early, the team has enough time to address blockers, adjust priorities, or make changes to the team. If the gaps are discovered on day eight, there are few, if any.

The use of burndown charts helps to create a team culture that maintains a healthy team spirit. When a team has the opportunity to adjust the burndown line to create progress that is a perceived victory, the culture promotes positivity. It is an excellent motivator in the gamification of sprints as a whole.

Agile burndown charts are an excellent demonstration of understanding the modern approaches to project management. Techademy students in PMP certification courses demonstrate this understanding.

The progress line is misleading in the absence of value-based measures, KPIs, or other project management quality measures. It is also vital to recognise that burndown charts are limited to tracking value-based measures and prime measures. If the progress line is depicted as a measure of completely untested bugs, the progress line measures misleading progress. Burndown charts help track unvalued objectives.

Over time, teams learn to be more accurate and ideal lines are used more than once. It is important to recognise that using the ideal line is important. It provides the base standard to which the unvalued objectives are held. Over time, the measurement of teams can mature to be a reflection of their historical velocity data. The ideal is used more than once and is considered a measure of maturity.

The charts do not specify what work has been done, so it is possible to finish all of the low-priority items and leave critical features untouched. Pair your burndown charts and PCMP analysis Pareto chart with prioritisation to help show what is most important.

Consistency is key. During the daily standups, we all update the sprint burndown chart. To help keep this chart updated, you can assign one person to be the chart owner.

Use story points, not hours. Hours are too fragile and can be manipulated, but story points are much better for capturing relative complexity.
Don't punish variance. If teams fear being "punished" for being behind, they will just inflate their estimates and piss away the whole purpose of the chart. Use the burndown to measure progress, not punish.

Use other tools. Burndown charts do not work in isolation. Pair them with velocity, control chart, PCMP analysis, and CDF for flow diagrams.

First, you need to calculate the team's capacity for the sprint. If you have 5 developers, each of whom has 8 working hours over 10 working days, that gives you a total of 400 hours. If you factor in meetings, emails, and interruptions, then realistically, about 300 hours.

Next, you need to estimate all committed user stories in the relevant unit (story points or hours). For example, let's say you committed to 30 story points. If we create an ideal line, it would go from 30 to 0 in 10 days, decreasing 3 points per day.

Make sure to drop the actual line to reflect the completed work at the end of each day. For example, if you have completed stories worth 4 points, the line would drop by 4. If you do not complete anything, the line will remain at the same position. If the scope increases, the line would move up.

In most agile tools, such as Jira, the sprint board generates burndown charts automatically. The tool tracks the completion of stories marked as 'Done' and adjusts the chart automatically. This saves you from having to do it manually.

Once you understand burndown charts, you will completely change how you track projects. You will get an immediate, clear picture of what progress is being made. If any problems start to arise, you'll have clear data to help fix the issue. You will also have data to help you track continual improvement. Just start with a simple sprint burndown chart. Once you start updating it every day, you will see the changes in your team's commitment to the sprint. You will see how your team's approach to the sprint changes. You will also see how clear the charts are. You'll also see how it will require very little effort.