The Agile Burndown Chart Gauges Sprint Progress

For those new to agile, a Burndown Chart is a graphic representation of sprint status. The vertical right axis shows the number of Story points brought into the sprint. Across the bottom, you see the number of days in the sprint. Most charts also display the perfect 45 degree angle Burndown.

The ideal Burndown Chart gives you the impression that it is possible to complete Stories in a smooth process of building application functionality and closing Stories. However, with agile projects, just like with all other projects, progress can be a bit bumpy.

I love Burndown Charts, because all you need to do is glance at a Burndown Chart to easily see how the team is managing the sprint. It is quite a powerful tool. Root cause of what created the peaks and valleys of the Burndown provides excellent food for discussion at Retrospective.

A typical Burndown Chart might look like the one below:

Sample Burndown Chart for a Sprint

There are 2 negative indicators you do not want to see on your Burndown Chart:

1. Flat lines mean that no Stories have closed in one or more days.
2. Upward peaks mean the team brought in new Stories after the start of the sprint.

How to Combat Flat Lines

A Story can stay open for several reasons: it is larger than sized; it is blocked and the programmers need intervention from the Scrum Master; or the team is not practicing pair programming and every programmer has his or her own Story in progress. You get the idea.

If the team flat lines early in the sprint for more than 2 or 3 days, figure out why Stories aren’t closing, take action and get the sprint on track. If you don’t, the sprint could end up going off a cliff, like what happened in the Burndown Chart above. When the team does not close Stories in timely fashion, it cannot meet its sprint commitment and Stories remain unfinished at the end of the sprint. These Stories are removed to the Backlog at the end of the sprint. The team does not get credit for any work completed and they also risk missing key project milestones.

How to Combat Peaks

Yes, sprints are supposed to be time-boxed. Once started, the team works diligently on the Stories allocated to the sprint and the Product Owner freezes new work orders for the next few weeks.

In real life, stuff happens. The team realizes that it would be more efficient to work on a different aspect of the application first or a major emergency occurs or the team forgot something. There are lots of reasons why the team breaks the sanctity of the sprint and adds new Stories.

In the Burndown Chart above, you can see 5 mini-peaks where Stories were added. This definitely contributed to the cliff at the end.

More often than not, multiple peaks in the Burndown Chart indicate that the team is not doing a good job of deciding what to bring into the sprint. If this happens during multiple sprints in a row, the team should discuss the issue at Retrospective and try new ways to develop more predictive behavior. The team cannot accurately plan for and meet its commitments if it has trouble deciding what to work on next.  

If your sprints are longer than 2 weeks and you continue to see peaks, I recommend shortening your sprint cycle to 2 weeks. The team may also consider amending the team contract to include rules for determining whether or not to allow new Stories to be brought in mid-sprint.

Look at the Burndown Chart Every Day at Standup

To expedite standup and keep it under 10 to 15 minutes, many teams are tempted to skip looking at the Burndown Chart and go directly to the Story Board. Resist the temptation.

Use the Burndown Chart to gauge the team’s progress at a glance and take corrective action early.

If the team is regularly closing Stories, the Burndown Chart will reflect its success.

Celebrate wins too!

Cynthia Kahn

Cynthia Kahn
CynthiaK@gsd.guru  503.799.5500