Everything you always wanted to know about the Iteration Burndown

There are several techniques that can be used to track team progress during an Agile Iteration. One of the most popular ones is the Iteration Burndown Chart. It's a simple chart, however it has the power to provide quite a bit of information. In general, the most interested in the burndows are the team's Product Owner (PO) and Scrum Master (SM). Also, it can be used for anyone else who is interested in Sprint outcomes, as Project/Product Managers and stakeholders.

Components

In the burndown chart we usually put the period of time at the X-axis and the hours of work at the Y-axis. This way, you can find out how many hours the team still needs to work in order to complete the Sprint (green bars) and also how many hours of work have been delivered (yellow bars).

This chart above is an example of what would be the "perfect" sprint of the "perfect" team. The velocity of delivery is consistent throughout the sprint. In the middle of the sprint we have exactly 50% of the planned work delivered. In the end of the sprint, everything was already delivered and the Sprint finishes as a success. Of course, this is a perfect balanced sprint and it's not expected that real teams work like this.

One more example

Let's take a look at another example. This is a situation where the team completed the sprint successfully, but there are things to improve for certain. Observe that the velocity was not uniform throughout the sprint. There was a very small amount of work delivered on day 2 and a big amount at day 3. Besides that, between days 14 and 15 there were absolutely no work delivered. Two things could have happened here: Either the tool wasn't updated appropriately or the team rushed to finish the sprint on time.

Sprint failure

A final example of a failed sprint: about 23% of the planned work was not finished. The velocity of delivery was uniform, but it wasn't enough to finish all the work on time. The team must adjust their velocity in order to prevent failures on next sprints.

At last, let's take a look at this text from the Official Scrum Guide:

"Various projective practices upon trending have been used to forecast progress, like burndowns, burn-ups, or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decision-making."

In other words: trending graphs are useful and can help your team to understand whats going on in the current sprint and the chance that it might fail or succeed; however, you should use them with caution, specially when dealing with a complex system or even maybe a complex team, where team members are joining and leaving the team constantly and the team has not yet achieved a mature level.