A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed. It is often used in agile software development methodologies such as Scrum. However, burn down charts can be applied to any project containing measurable progress over time. Outstanding work can be represented in terms of either time or story points
A burn down chart for a completed iteration is shown above and can be read by knowing the following:
| Element | Details |
| X-Axis | The project/iteration timeline |
| Y-Axis | The work that needs to be completed for the project. The time or story point estimates for the work remaining will be represented by this axis. |
| Project Start Point | This is the farthest point to the left of the chart and occurs at day 0 of the project/iteration. |
| Project End Point | This is the point that is farthest to the right of the chart and occurs on the predicted last day of the project/iteration |
| Number of Workers and Efficiency Factor | In the above example, there are an estimated 28 days of work to be done, and there are two developers working on the project, who work at an efficiency of 70%. Therefore the work should be completed in (28 ÷ 2) ÷ 0.7 = 20 days. |
| Ideal Work Remaining Line | This is a straight line that connects the start point to the end point. At the start point, the ideal line shows the sum of the estimates for all the tasks (work) that needs to be completed. At the end point, the ideal line intercepts the x-axis showing that there is no work left to be completed. Some people take issue with calling this an “ideal” line, as it’s not generally true that the goal is to follow this line. This line is a mathematical calculation based on estimates, and the estimates are more likely to be in error than the work. The goal of a burn down chart is to display the progress toward completion and give an estimate on the likelihood of timely completion. |
| Actual Work Remaining Line | This shows the actual work remaining. At the start point, the actual work remaining is the same as the ideal work remaining but as time progresses, the actual work line fluctuates above and below the ideal line depending on this disparity between estimates and how effective the team is. In general, a new point is added to this line each day of the project. Each day, the sum of the time or story point estimates for work that was recently completed is subtracted from the last point in the line to determine the next point. |
The burndown shows the total effort against the amount of work we deliver each iteration. Something like this
We can see the total effort on the left, our team velocity on the right. But look what else this simple graphs gives us.
- Work done each iteration
- Work remaining
- Work done so far
- When we can expect to be done
All this from one graph! Now what you see above is pretty ideal. A more realistic burndown looks something more like this:
It’s never a straight line. The team never moves at exactly one fixed velocity. And we discover things along the way (notice how it shows us scope creep in the form of those 5 new reports). And of course like all things in Agile, you are free to make things your own. One tweak I like making to the burndown is displaying total work done each iteration also. This let’s me look at the chart, and immediately get a sense of whether we are a quarter, a third, or ½ way done the project.
Sprint Burndown Chart
Teams use the sprint Burndown chart to track the product development effort remaining in a sprint.
General speaking the Burndown chart should consist of:
- X axis to display working days
- Y axis to display remaining effort
- Ideal effort as a guideline
- Real progress of effort
Companies use different attributes on the Y axis. All of them have benefits and drawbacks.
The number of stories
New agile teams used to start with the Burndown chart that displays the number of items on the Y axis.
It is a big mistake if they are allowed to continue with this approach. The reason is simple; stories require different effort to be completed. The first completed story can be two times bigger than the second one, but the chart does not explain the real iteration status.
Time unit
Time unit (hours or days) represents remaining time necessary for completion.
The benefit of displaying time is that it provides more granular view of progress, but it leads to micromanagement as well. It is typically suggested for new agile teams. Teams are often asked to carefully track time spent and remaining time, but all those who ask their team to do so should understand that the team is hired to develop a real product, not to spend amounts of time. Therefore most agile teams track a remaining size.
Remaining size
The chart displays the remaining size of all stories in a sprint backlog that needs to be done, using story points.
Stories are typically bigger items than tasks. Stories are also considered as done only when all tasks are completed. This leads to stairs in the Burndown chart. Such stairs are usually not evaluated correctly. Especially management reads them as ‘no progress’ while they mean ‘effort continues, it has not been completed yet’. Steps could be smaller if stories are broken down in an appropriate way. More experienced teams work with stories (level of what, not how), that are enough for a daily synchronization. It is less comprehensive, but sufficient. It allows to have shorter daily meetings that are more focused on ‘what we solved, what remains’.
Bring an Understanding
Simplicity of the chart does not help if process gaps need to be identified. In this case, two lines are not enough as they simply display a summary of work for all team members and the gaps need to be identified on a task board. Usually it is unclear if a team is too late or somebody added additional work. Especially, in the case that an equal amount of work has been completed, there will be no progress indicated.
In this situation, viewing the total size of the sprint backlog should be helpful. Any change in the total size provides a clear explanation for the actual line issue.
It might be helpful to display impediment indicators as well. I think that impediments are a pain that should be visible. Having them on a Burndown chart is a good way to combine them with the progress giving the sprint overview.
What a Burndown Chart Can Say
There are only two lines drawn in Burndown chart, but the situation they describe might have different reasons. In workshops, I can see that even certified Scrum masters are not able to explain situations described by Burndown charts correctly.
Ideal Team
Such diagram indicates the great team able to organize itself. It indicates a great product owner who understands the reason for a locked sprint backlog and a great Scrum master able to help the team. The team is not over-committing and finished the spring backlog on time. The team is also able to estimate capacity correctly. No corrective action is necessary in such case.
Great Team
Such progress might be observed on charts of experienced teams. The team has completed work on time and met the sprint goal. They also have applied the principle of getting things done, but the most important is they have adapted a scope of the sprint backlog to complete the sprint. At the end the team has a possibility to complete some additional work.
In the retrospective, the team should discuss the reasons of late progress in the first half of the sprint and solve issues so they are better in the next sprint. The team should also consider the capacity that they are able to complete.
Nice Team
This is a typical progress that can be observed in many experienced agile teams. The chart says again that the team was able to complete their commitment on time. They adapted the scope or worked harder to complete the sprint. The team is self-reflecting.
Boom. It Is Too Late.
This burndown chart says: “You have not completed your commitment”. The team has been late for the entire sprint. The team did not adapt the sprint scope to appropriate level.
It shows that the team has not completed stories that should have been split or moved to the next sprint. In such situation the capacity of the next sprint should be lowered. If this happens again, corrective actions should be taken after a few days when slower progress is observed. Typically, lower priority story should be moved to the next sprint or back to the product backlog.
Boom. Too Early.
The team finishes its work sooner than expected. The stories were implemented, but the team didn’t work on additional stories even it had the capacity to do it. The stories were probably overestimated, therefore the team finished them earlier. Also the velocity of the team has not been probably estimated correctly.
Let’s Have a Rest
The team with such progress has a problem. The problem is either the team committed to less than they are able to complete or the product owner does not provide enough stories for the sprint. The reason might be also an over-estimation of complexity, which ends up in completion earlier than expected at the beginning of the sprint.
Oh, Management Is Coming!
The team is probably doing some work, but maybe it does not update its progress accordingly. Another reason might be that the product owner has added the same amount of work that was already completed, therefore the line is straight. The team is not able to predict the end of the sprint or even to provide the status of the current sprint.
Do Your Duties
The team is non-functional on many levels. The Scrum Master of this team is not able to coach the team why it is necessary to track progress on daily basis. The product owner does not care about development progress either. To fix this situation the team should restart. Restart from scratch by training and do a retrospective to figure out why this is happening.
Zero Effort
A chart like this indicates that stories or tasks were not estimated during the sprint planning meeting and the sprint has not officially started yet. To fix this situation, team should immediately arrange a planning meeting, estimate the user stories, include them in the sprint according to their velocity and start the sprint.
Up to the Sky
The first sprint typically looks like that. It is good source of knowledge because the team has failed significantly and it is highly visible. Stories or tasks were added into the sprint backlog every day without any progress recorded. Another reason might be that tasks were re-estimated constantly during the sprint.
Bump on the Road
The team has not started sprint correctly. They added stories after the sprint had started. It is positive that they recognized that planning is missing planning, it is however too late. The team should be careful about the capacity estimation as planning happened in the middle of the sprint, not before it. In such case it is suggested to restart the sprint, even within a shorter timeframe.
Progress from Long-Run Perspective
Burndown charts described in previous paragraphs are the description of iteration. But does a nice Burndown chart indicate a great team? Maybe if your team indicates great progress for more than one iteration. Does the team believe in such success? I would be personally careful. We all know about changes coming every minute. Maybe the team provides conservative estimation for their safety.
