What Is A Burndown Chart? Scrum Basics
If you’ve ever come into contact with Agile ways of working or using the Scrum framework to develop a digital product, you’ve heard the term ‘burndown chart’. Although it is not an essential tool during your day to day Agile work, it very often helps team members keep track of the scope of the work (and project too!). If you’ve ever wondered, just what is a burndown chart, you’re in the right place. Read on for a definition together with the benefits a burndown chart can bring to your product development, plus some tips on use.
Table of contents
What is a burndown chart in Scrum?
Just to recap, Scrum is an approach to digital product creation that is highly user-focused, depending on defined periods of development (called sprints) with specified goals, resulting in a series of product iterations in a process of continuous improvement. What keeps development teams on track in such a rapidly-moving environment? The answer is metrics – data-based measures of progress against project and development goals.
A burndown chart could be one of your fo-to metrics, a representation of progress during each sprint. To quote the Scrum Institute, a burndown chart is,
…a visual measurement tool that shows the completed work per day against the projected rate of completion for the current project release.
A burndown chart is represented graphically, with outstanding work and tasks (referred to as ‘story points’) on the vertical axis, and time (often shown as ‘sprints remaining’) on the horizontal axis. It’s a very simple, intuitively understandable visual, showing the work to be done and the time available.
Invented by software developer Ken Schwaber in 2000, the purpose of sprint burndown charts is to give development teams a simple and straightforward way of assessing progress and planning future activity.
How are burndown charts used in Scrum?
As a metric, burndown charts are used in Scrum meetings to review the work so far and plan next steps, especially in daily Scrums – short daily meetings to assess progress. During the course of product development, burndown charts are used as follows:
- Estimated burndown – A chart is created based on the initial predictions for the amount of work required, the time needed to deliver that work, and time available to the team. This produces the ‘estimated burndown’ – a descending line that shows the outstanding tasks or story points decreasing as they are delivered over time, approaching zero as the estimated time for product completion is used.
- Velocity – The team’s rate of progress is called the ‘velocity’, indicating the number of story points completed per product iteration. The velocity of the team allows for an estimate of the remaining time required to complete the product, based on the number of story points remaining.
- Changes to the product backlog – All story points are listed in the product backlog, and this list is almost certain to change during the course of development; due to changing priorities or pivoting on the product goals. Such changes mean story points can be amended, deleted or added during the process. Using a different graphical representation, such scope changes can be reflected while maintaining a true picture of the team’s velocity.
Benefits of burndown charts
The clear grasp on development progress that the team gets from its burndown charts has a number of advantages, depending on role. Product owners find burndown charts to be one of their main ways of monitoring the team’s efficiency. Scrum masters use them as a kind of health indicator or early warning system in relation to the team’s understanding of the product and use of the sprint backlog.
Other benefits of burndown charts include:
- Monitoring scope creep,
- Setting and maintaining an agreed schedule,
- Motivation for the development team,
- Reporting back to investors and other stakeholders.
The essential value of a burndown chart is that it is a measure of work done. Not planned, not prioritized, but done. Only story points that have been delivered count towards progress. Burndown charts are a metric that reflects real, completed achievement.
Potential disadvantages of burndown charts
Burndown charts are not always free from problems, although any difficulties tend to be caused by how burndown charts are implemented or used, and not the chart itself. For example, a burndown chart is only as accurate as the data used to compile it. If team members exaggerate their achievement (or underestimate it) or forget to log their times and activities, the resulting chart will not be an accurate reflection of progress.
Likewise, as mentioned earlier, any changes to the product backlog can result in an inaccurate representation – maybe the team’s work remains constant, but the addition of new story points (or the scale of the remaining points) can make it seem like the team’s planning is poor. As with any metric, however useful, burndown charts should be viewed in the wider context of project activity.
The last of the most common issues concerning a burndown chart is misuse of it. This metric is supposed to be an indicator for a Scrum team (product owner, Scrum master and Scrum developers) to make the most appropriate decisions during the development process. However, there is a temptation by management to use it as a metric that allows comparison of different teams’ performance levels, often not taking into consideration that this is a team-specific metric and should not be used as a general one.
Burndown charts in Scrum
Burndown charts are a common and – when used correctly and accurately – highly trusted Scrum metric. Once again, the Scrum Institute sums things up nicely:
(The burndown chart’s) …purpose is to ensure that the project is on track to deliver the expected solution within the desired schedule.
For any development team working in Scrum, facility in interpreting and using burndown charts is a must. If you’re interested in learning more about burndown charts in Scrum, check out our case study of a time when the burndown chart alerted us to a slowdown – due to a variety of factors – in development progress, allowing us to remedy the situation and still deliver a successful product on time.
Share this article: