An Agile Burn-Down Chart is a very simple tool used to monitor and show the progress of the current sprint - it is usually used in agile software development, but not necessary. It is exposed in a public location so that any stakeholder can get the information on how the sprint is progressing against the initial plan. The horizontal axis is the Time axis, usually a number of days from the sprint (from 1 to 10 for example if we have a 2-weeks sprint).
On the vertical axis, we have the number of story points, the amount of work that needs to be done on a particular day. Ideally, on the first day, we have the total amount of story points for the sprint and each day the amount remained will decrease with the velocity of the team. This is the ideal burn down line. This shows that, if you started with this much work to do and you did the same amount of work each day, you'd be able to finish at the end of the sprint.
Now the real progress rarely matches the ideal guideline, but it should show steady progress. So, on top of the ideal burn down line, we put the actual effort remained after each day in the sprint and the generated line will usually stay close to the ideal line, crossing it from one side to another, but in general having the same descending trend?
Sometimes, blockages are preventing for completing the sprint story points. It means we have technical debt, which is transmitted to the next sprint. Therefore, the next sprint will bring less value to the product because he cannot include as many features as it could have done without the technical debt.
And then sometimes you'll get a strange burn-down chart because of some other things you're doing. Like, for example, if you have a spike.
Where there is a spike, you'll get a flat rate for a while. And the reason is that a spike has no story points. Remember, spikes are used to investigate areas of uncertainty. They do not add functionality to the product increment, so they will not have any story points.
And your burn-down chart will not show work getting done when you have a spike, so lots of times it'll look like you're not doing any work, even though you are.
Normally, the development team updates the burn-down chart; sometimes the Scrum master does it. It's something that the team has to decide. And as tasks are completed, the burn down chart is updated so it always reflects how the team is performing during the sprint.
An up-to-date agile burn-down chart is a great tool to use during the daily Scrum. If the burn-down chart is not moving down, then it's a good indication there's a blockage that the Scrum master needs to be aware of, so it can be worked.
At any point in time, the agile burn-down chart will show at a glance the initial amount of work taken on by the team in the sprint planning meeting, and the estimated amount of work that's remaining to complete during the sprint.
The chart is also giving us our velocity of that sprint. This gives the stakeholders an early sign of how well the team is completing the tasks that they need to do during the sprint, and it gives them a good sign if they will complete them by the end of the sprint.
Some (final) thoughts
This article is part of a bigger topic called: