AGL Academy

This lesson provides insight into the various metrics tracked by a burndown chart and the value that each delivers.

The Burndown Chart

The progression of stories and their assigned points, as they reach a completed state, can be expressed in a burndown chart. A burndown chart does not count partial progress — only stories that are complete may count towards the “burn”. As a result, the Product Owner and the team can identify how much of the product can be delivered at any one time. A burndown chart for the Sprint should be a regular part of Scrum meetings as it helps the entire team identify whether or not they are on track. The progression of stories and their assigned points (representing the effort required to complete them), as they move incrementally from Backlog to Done, can be expressed in a burndown chart.

Burndown charts, like storyboards, can vary in appearance and have a number of tracked values, but they all have these things in common:

• Red line – Expresses a vector from the maximum anticipated story points to zero — the ideal “red line”. This vector is the perfect function of points completed or “burned” per day.
• Green line – Shows a plot of of actual points complete for each day that passes. If you finish a 5 point story, 5 points are burned. The actual points completed may fall above or below the ideal schedule (red line) as the Sprint progresses. This is to be expected.
• Purple line – Shows the number of points planned. This number can go up or down if the team adds a “stretch story” or a story is removed because it’s blocked by external circumstances. In the example above, the team does not add or remove any stories to the Sprint, therefore the line stays flat.
• Blue line – Sometimes (as pictured above) there is a burn-up line, useful for predicting team patterns to find the “break even” point.

Every team has a maximum point value that they can take on. New teams tend to underperform and experienced teams tend to burn hot. It takes a few Sprints to dial in on the team’s point maximum.

A burndown chart can provide value to the PO and the team, both during a Sprint and after it has been completed. While a Sprint is ongoing, you can review the burndown chart for indicators that help you infer how well the team is doing or if there is a potential issue on the horizon. After the Sprint, the burndown chart provides information about how the work was completed. Below are three burndown charts, along with explanations that describe key takeaways during and after the Sprint.

Example 1: Sprint with Large Stories

During the Sprint

Throughout the Sprint, viewing a burndown chart like the one in Example 1 can highlight stories that are very large and complex. For instance, on March 11, one user story may have been completed but it accounted for almost a third of the total points in the sprint. Stories that make up over a quarter of the points in a given Sprint can be considered risky. The larger the story, the greater the amount of uncertainty (i.e., possibility that the work will not be completed by the end of the Sprint).

After the Sprint

Example 1 may also indicate that a team is still functioning in a waterfall manner. For example, 4 stories totalling 14 points may have been completed on March 11, and 5 stories totalling 16 points were completed on the 14th. This may indicate that the team is not dividing their work properly or that there is a bottleneck in the process.

Example 2: Sprint Expanding in Scope and Missing Target

During the Sprint

In the first week of the Sprint, the team in Example 2 seems to be on pace. However, on March 14, additional stories were added to the Sprint, as demonstrated by the upward turn of the yellow line. This places the team in a precarious situation where they may not be able to complete all of the work required.

After the Sprint

The effect of adding stories is fully realized when the team does not deliver all functionality on the last day of the Sprint. Adding scope (stories) to a Sprint after it has started is considered a bad practice. Many times, a PO will be tempted to add stories mid-Sprint if a requirement was missed or it is discovered that a product cannot be shipped without an additional feature. This becomes quite risky and can result in the team missing their original target as shown above (or results in the team working long hours to make up the difference). When a team is working long hours to catch up, they are more prone to shipping a defective product. This will result in downstream maintenance costs that could have been otherwise avoided.

Example 3: Sprint Rushing to the Finish

During the Sprint

Throughout the Sprint, you will notice that that team lags further and further behind the expected completion schedule as denoted by the red line. This may be due to the fact that the team is blocked either externally or internally. An external blocker, for example, could be that they are relying on you for the language that goes into an automated e-mail message or they need the networking team to make a change that is out of their control. As a Product Owner, one of your chief responsibilities is to unblock your teams as quickly as possible. Sometimes that means calling the network team on behalf of your Development Team or stopping your day-to-day work to complete the language for an automated e-mail. Internal blockers can arise if the team has not built that particular type of functionality before, or if one of their resources is busy on other tasks.

After the Sprint

Example 3 demonstrates a team who lagged behind for a majority of the sprint and suddenly completed the remaining stories on the last day of the sprint. While they did finish on time, the fact that 18 of the 31 points (almost 60%) were completed in one day raises a number of questions. Were the stories so interrelated that they could not test until the end? If so, that is an indicator that the team could have broken down the stories to be more independent from one another. Was there a bottleneck in the development process that forced the team to rush to the finish?

As you learn to interpret and create burndown charts (it takes practice!) you will be more effective at helping your team achieve their goals on time.

Congratulations, you’ve completed Agile for the Government Product Owner!

The Next Level

There are many important topics which have not been covered in this introductory study track:

• Automated testing
• Continuous integration
• Modern deployment tools
• Lean startup continuous learning techniques

And many more! Once your agency begins to reap the benefits of Agile, you’ll likely want to continue studying and pursuing this methodology that allows governments to bring delightful, effective services to citizens and customers.

Feedback

We would love to learn how we can make this course better. Your feedback is welcome!