Agile teams use burndown charts to show the amount of work completed over time to monitor their progress.
There are three common patterns to look for in a burndown chart. When progress stalls, the line becomes flat. When work is added, the line shoots up. And sometimes, the rate of work slows and floats above an ideal trend line.
Let's look at some baseline data, reflect on the meaning revealed by the charts and see where teams can improve.
The following burndown charts show how many task hours are left for the team. The goal is to drive the remaining work down to zero by the end of the time-box.
We'll start with a graph of three iterations completed by one team in two weeks. Sprint three is still underway, which you can tell because the line for it is unfinished. But what happened in these other iterations?
In sprint one, there is a catch-up pattern. The team stalled in its progress from days 8 to 11, and then made a push to finish. As a result, the team signed up for fewer hours in sprint two. This is common, as teams plan for more work than they can get done at first to help them plan for the next sprint.
In sprint two, the team faced a different problem. A bubble of work formed at the beginning because the team didn't plan the sprint process correctly and had to add work.
Both of those issues in the normal rate of work can confuse efforts to forecast the rate of progress based on the first few data points, allowing for improvements down the line. Instead of looking at the trend from the first day's allocated work, for example, take the maximum amount of work anticipated and plot that from day one.
Ideally, the maximum amount of work will be accomplished on the first day. But in the case of "bubble" sprints where work is added mid-course, drawing a line from the sprint's maximum workload as though it were known on day one will give a better presentation of the ideal trend line.
The next problem is a plateau every few days. The graph originally provided data for 14 days including weekends, not just the 10 working days in the sprint. It looks like the team is unproductive every few days, but it is simply a reflection that they took the weekend off. Adjust the burndown chart, as I've done below, by accounting for added work and masking non-workdays and your team will have a clearer picture of its iteration's progress.
What adjustments do you make to burndown charts to ensure an accurate depiction?
There are three common patterns to look for in a burndown chart. When progress stalls, the line becomes flat. When work is added, the line shoots up. And sometimes, the rate of work slows and floats above an ideal trend line.
Let's look at some baseline data, reflect on the meaning revealed by the charts and see where teams can improve.
The following burndown charts show how many task hours are left for the team. The goal is to drive the remaining work down to zero by the end of the time-box.
We'll start with a graph of three iterations completed by one team in two weeks. Sprint three is still underway, which you can tell because the line for it is unfinished. But what happened in these other iterations?
In sprint one, there is a catch-up pattern. The team stalled in its progress from days 8 to 11, and then made a push to finish. As a result, the team signed up for fewer hours in sprint two. This is common, as teams plan for more work than they can get done at first to help them plan for the next sprint.
In sprint two, the team faced a different problem. A bubble of work formed at the beginning because the team didn't plan the sprint process correctly and had to add work.
Both of those issues in the normal rate of work can confuse efforts to forecast the rate of progress based on the first few data points, allowing for improvements down the line. Instead of looking at the trend from the first day's allocated work, for example, take the maximum amount of work anticipated and plot that from day one.
Ideally, the maximum amount of work will be accomplished on the first day. But in the case of "bubble" sprints where work is added mid-course, drawing a line from the sprint's maximum workload as though it were known on day one will give a better presentation of the ideal trend line.
The next problem is a plateau every few days. The graph originally provided data for 14 days including weekends, not just the 10 working days in the sprint. It looks like the team is unproductive every few days, but it is simply a reflection that they took the weekend off. Adjust the burndown chart, as I've done below, by accounting for added work and masking non-workdays and your team will have a clearer picture of its iteration's progress.
What adjustments do you make to burndown charts to ensure an accurate depiction?
Leave a comment