What is the Burndown Chart in Scrum? A burndown chart is a graphical illustration of work left to do versus time. The planned work is often on the vertical axis, with time along the horizontal. Burndown charts are a run chart of outstanding work. They help to predict when all of the work will be completed. Burndown chart is often used in agile software development methodologies such as Scrum. Still, burn down charts can be implemented in any project, including measured progress over time.
What is the Burndown chart used for?
The purpose of this graph is to show the progress of the Development Team on the Scrum Sprint.
How to create a Burndown chart?
Most modern Scrum management software tools have built-in Burndown chart generation functionality. Each time the Development Team completes the task, your Burndown chart will update itself. We recommend that you carefully study the settings of your software tool and study how it works.
You and the Burndown chart
The most important thing to know is that the Burndown chart is not as scary as it may seem.
Another essential thing to remember is that you should view the Burndown chart daily. Traditionally, this is done during the Daily Scrum meeting, as this event is held daily.
Here's an example of how a Burndown chart might look.
Explanation of the elements of the Burndown chart graph.
The left axis is vertical and shows the total amount of work planned for the Sprint. If all items in the Sprint Backlog have a total of 600 Story Points, the left vertical axis will show that 600 (top left). Another line descends down and to the right, ending at the end of the horizontal axis (bottom right).
The horizontal axis shows the time of your Sprint. The right-most part of the horizontal axis is assumed to be the last day of your Sprint.
The leftmost part of the vertical axis is accordingly the first day of your Sprint.
Note the gray line of the example above, which starts at the top of the left vertical axis, and ends at the right-most part of the horizontal axis. This is a starting line that does not change and is a benchmark for your Sprint to navigate.
The red line shows the real movement of the Development Team and its progress. Every day your real (red) line of work moves from top to bottom and to the right. The goal is to reach the gray orientation line at the end of the Sprint.
When your real red line is moving above the guidance line, it means that sprint work is behind schedule. If the real (red) work line is below the ideal gray line, logically, your Development team is advancing faster than planned.
Let's analyze the chart above
You may notice that during the first two days of the Sprint, the Development Team completed their work slower than expected. On the third day, however, the team was able to catch up with the delay, and the real red line even went down the ideal gray line.
By day 6, the team is moving faster than expected. The red line is still below the gray line. After the 7th day, the work is slowed down again. A period of 3 days is observed during which the red line does not drop down and moves horizontally. Horizontal movement means that there is no real progress on the tasks. Then we notice that the red line is starting to move very slowly down.
Any sharp vertical drop of the line means that one task or User Story is complete. You can see about 25 line movements, which means that all tasks were about 25. Each time a team member completes a task, and the task is marked as Done, Ready, Finished, or another similar status that your software automatically monitors, the line moves down.
However, you also notice strange slight upward movements that immediately revert downwards. Such changes can mean different things, but most of all, the team has added new small tasks to their Sprint Backlog list, modified task execution time, or swapped tasks.
The other thing that strikes the sample chart above is that the team is unlikely to be able to complete the planned Sprint job. It is noticed that the end of the red line is not quite close to the end of the ideal gray line. Still, half a day remains until the end of the Sprint. If the team completes all the planned work, the red line will have a sharp drop down and reach the ideal gray line (the end of the Sprint). The red line will touch the gray line.
The Burndown chart may, in some cases, not reflect the real situation. If the Development team forgets to mark their work as completed, the software will not update the schedule. It will appear that the planned sprint work is far behind schedule. If your software tool requires manual graphics updating, you should do so to have a visibly up-to-date status on team progress.
The Development Team and the Burndown chart
The Development Team freely observes and discusses the Burndown chart. If the team notices that Sprint progress is too fast, it may pay attention to the quality of work or consider whether all Definitions of Done and Acceptance Criteria are met.
In the event of delays in work, it will probably be necessary to take measures, which, however, should not impair the quality and all defined criteria of work.
Scrum Master role and the Burndown chart
The Scrum Master role has no regulated rules under Scrum related to the Burndown chart. BVOP, however, recommends that the Scrum Master role assists in supporting the Burndown Chart Chart and train each Scrum member on the benefits and applications of that chart. The Scrum Master role should be an assistant in making slow work decisions. He also assists with a fast-moving sprint.
Product Owner role and Burndown chart chart
The Product Owner role has no real practical involvement in the Burndown chart but can still benefit from it. Monitoring progress can be important to the work and responsibilities of the Product Owner.
If the work progresses too fast and all User Stories are expected to be completed before the end of Sprint, the Product Owner role can quickly notice this in the graph and prepare User Stories that can be further included in the Sprint Backlog.
- Previous article Sprint Retrospective