The following article is part of the self-preparation for the modern BVOP® Scrum Master Certification program.
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 help to predict when all of the work will be completed.
- Why use a Burndown Chart?
- The stages of the sprint
- About this chapter
- What is the Burndown chart used for?
- How to create a Burndown chart?
- You and the chart
- The Development Team and the Burndown chart
- Scrum Master role and the Burndown chart
- Product Owner role and Burndown chart
Burndown chart is often used in agile software development methodologies such as Scrum. Still, burn down charts can be implemented in many projects.
The main goal is to track the completed and remaining work. The prognosis for a successful sprint is much easier.
At the beginning of the Sprint, the graph shows relatively little information, and predictions are difficult or impossible. Towards the middle of the Sprint, the tool visualizes much more information and the end is easier to predict.
This chapter is part of the preparation material for the BVOP Scrum Master certification exam.
The purpose of this graph is to show the progress of the Development Team during the Scrum Sprint.
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’s tools and the way they work.
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.
Here's an example of how a Burndown chart might look like.
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 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 rightmost part is assumed to be the last day of your Sprint.
The leftmost part of the horizontal axis is accordingly the first day of your Sprint.
Note the gray line on 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.
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 from left to 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.
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 under 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 downwards.
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 there are approximately 25 tasks. 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 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 work delays, it will probably be necessary to take measures. However, they should not impair the quality and all defined criteria of work.
The Scrum Master role has no regulated rules related to the Burndown chart. BVOP, however, recommends that the Scrum Master role assists in supporting the Burndown Chart and shows each Scrum member the benefits of the chart’s application. The Scrum Master role should assist during slow and fast-moving Sprint periods.
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 their work and responsibilities.
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 implemented in the Sprint Backlog.
The following issues related to chapter "Burndown Chart" are included in the certification exam. The sequence of questions is presented in the table.
The data is current as of September 25, 2020, 12:57 pm
|0||The Development Team and the Burndown chart||60 sec||SM, PO|
|1||Analysis||60 sec||SM, PO|
|2||Let's analyze the chart above||60 sec||SM, PO|
|3||About this chapter||60 sec||SM, PO|
|4||Product Owner role and Burndown chart||60 sec||SM, PO|
|5||What is the Burndown chart used for?||60 sec||SM, PO|
|6||Why use a Burndown Chart?||60 sec||SM, PO|
|7||The stages of the sprint||60 sec||SM, PO|
|8||You and the chart||60 sec||SM, PO|
|9||How to create a Burndown chart?||60 sec||SM, PO|
|10||Scrum Master role and the Burndown chart||60 sec||SM, PO|
- Previous article Sprint Retrospective