06Apr
Scrum Artifacts - Burn Down Chart

The Burn Down Chart is a very simple tool use to monitor and show the progress of the current sprint. 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 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 at 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 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 off 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, it happens that 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 of you have a spike.

?

Where there is a spike, you'll get a flat rate for a while. And the reason is because 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're not going to have any story points. And your burn down chart is not going to 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 is responsible for updating the burn down chart; sometimes the Scrum master does it. It's something that the team's going to have 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 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 burn down chart is going to 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 still remaining to complete during the sprint. The chart is also giving us our velocity of that sprint. This gives the stakeholders an early indication of how well the team is completing the necessary tasks that they need to do during the sprint, and it gives them a good indication if they're going to complete them by the end of the sprint.

?