Burndown Chart Analysis
Big Agent Jira Study Case
Understanding Burndown Chart
A burndown chart is a line chart drawn between “work remaining” as a vertical axis (Y) and “time” as a horizontal axis (X). This chart is used by scrum teams at their daily work to track progress and task burn in a sprint.
Actually, the burndown chart is simple and easy to understand, but teams often struggle to get a full understanding and deep meaning behind the graph.
By looking at the curve, the engineering manager (EM), product owner, project manager (PM), or team lead (TL) can monitor and manage the velocity of all team members. For example, by monitoring a burndown chart we can ask team members to spend more time and more effort to catch up to the deadline for each sprint. Even from burndown charts, we can detect if some blockings are arising that greatly inhibits the process of completing the task on target.
X-axis describes the time during the sprint and usually in days.
Y-axis describes the amount of work remaining to be done, it can be a story point, point, issue count, or manually in the form of a field that we have defined.
Progress Lines, lines that describe the progress of the team. The data will always be updated automatically or manually. When the sprint is taking place from this line, it can be seen whether the work of the team is on track or deviated, so corrective action is needed.
The guideline is a diagonal line from top left to bottom right. usually one day the line goes down and the next day it takes a horizontal line. Ideally, the progress line can be as close as possible to this guideline line. If we have planned the sprint correctly and the team finishes at a steady pace, usually the progress line will end the same as this guideline line.
Choose the Suitable and Correct Metrics for the Team
Choose Y-axis as the number of tasks remaining. This is the line that states how many tasks are left in the sprint on a certain date. When the task is completed, the curve will automatically move downwards. The biggest advantage of using this graph is that it is easy to understand.
The drawback of using this graph is that tasks are not estimated. Not all tasks have the same effort in completing it. Very often the team leaves a difficult task and does it at the end of the sprint and they see they can’t complete all the tasks even if they do on the right track.
Choose Y-axis as the number of story points remaining. The line is stating the number of story points or estimated points or points of a task during progress time. This graph is the best way to estimate tasks based on the level of complexity.
The graph will end almost the same as the previous graph but, it will clear the ambiguous level when we track the completion of the task.
When is the Burndown Chart Useful?
1. During the Sprint Process
Seeing the burndown curve during the sprint process can make EM, PM, or team lead answer the following questions:
a. Is the sprint progress on target?
b. Whether all stories or tasks will be completed on time?
c. What actions must be taken so that the target can be achieved?
2. After Sprint
This burndown chart is an indicator of team performance during the sprint. In a retrospective event it can be used to analyze the accuracy of task estimation and difficulty, team performance, blocking that occurs, and to be considered for the next sprint going better.
How to Read Burndown Chart
Burndown chart is read by comparing the sprint progress line with guidelines. The closer two lines are, the better and closer all tasks will be cleared on time.
- On track. The two lines are close together. The team will reach the target if they maintain their velocity when doing the task.
- Behind the schedule. If the progress line is above the guideline, it means the team is late and the team should complete more tasks. (we need to push them to do more work).
- Ahead of the schedule. The progress line under the guidelines shows the team will reach the target even before the end of the sprint. This happens because the task that was agreed is too little or the task that was thought to be difficult turned out to be easy. When this happens, the team can carry out additional tasks such as taking an enhancement task, creating TRD or learning other skills. So the team gets something more useful during the healing mode.
Patterns of Burndown Charts
Here are some common graphs
- Status updates are incorrect and inconsistent or the task breakdown process is not good
If the task does not break down in good detail, then each individual team will take a long time to complete it. The best way is to be more detailed and break down tasks into smaller ones that might still be possible. Generally, tasks with points greater than 8 must break down into more tasks with small point values.
2. The update process is done at the end of the sprint
This is because the team doesn’t update the status every day and update the status when the sprint finishes. This can happen when the team uses the Jira system using story and subtask and then burndown chart rendered using the Standard of Jira Chart.
By default, Jira only calculates points on stories, not in subtasks, but in real work, the team basically works in subtasks. Special chart plugins are needed to draw better charts and are usually not free.
An alternative is to create a custom field that illustrates the point of the story. This field must be updated manually by the team every day. For example, the number decreases when they have done some tasks and increases if the task moves back to the progress state.
In a big agent case, we update story point (decrease as the value of subtask point when going to state done) and point increase if add new subtask of subtask moving back to progress by QA team.
3. Ahead of Schedule
This graph occurs when the team estimates the task is too difficult to do.
If the team keeps up their velocity doing the task, then the sprint will be on target before the deadline.
4. Behind the Schedule
This graph shows the team must struggle and bleeding to be able to finish all tasks on the target deadline.
If the team has been disciplined at work completing the task, there is no useless thing that the team is working on, and no blocks occur then the following should be considered:
a. Add the number of teams or
b. Reduce the scope of the work by eliminating some stories or tasks
Limitation of Burndown Charts
Here the limitation of the burndown chart:
- This burndown graph actually cannot provide information about how much work is being done. This data can be illustrated using the Burnup Chart that in fact, is the opposite of the burndown chart.
- Difficult to retrieve or read data to illustrate changes in scope backlog. One workaround would be to add more data to the chart but this affects the readability of the graph. These limitations of the burndown chart can be overcome by using a Cumulative Flow Diagram.
- Burndown chart by default does not count from the progress state it will count from the task that is on the far right or is in the position done or released or go up to production. This results in the illusion of the process that occurs. It is recommended that we use a custom field whose data is updated every day so that it is more flexible or we use a paid chart plugin.
Big Agent team already uses a Burndown Chart Analysis for about 6 six months. Although the result is not perfect, we have achieved an average of completeness tasks above 95 %.
Furthermore, we will continue to use it and will be combined with the analysis of the burnup chart and cumulative flow diagram. We hope all of our sprints will go better and better and can deliver the best quality of software products.
