Burn Charts

Burn Charts2017-10-12T22:05:27+00:00

What is a Burn Chart?

Burn Charts – burnup or burndown – are among the handful of truly basic Agile tools.

Burn Charts summarise progress in a form that is:

  • Easily created.
  • Easily maintained.
  • Easily understood.

Burn Charts can be used at both Iteration & Release level.

A Burn Chart tells us our ‘earned value’ by answering the following question:

  • How much we have actually accomplished …
  • … compared to how much we should have accomplished …
  • … given how much work we’ve done so far?

The are many types of Burn Chart. The most popular are the Burndown  Chart and the Burnup Chart.  See the other tabs on this page for details of each.

A Burn Chart can be easily constructed with basic spreadsheet skills, or just a flipchart and a marker pen.

Burndown chart

The Burndown Chart is the most common type of Burn Chart, as it’s very easy to create, update and read.

A simple Burndown Chart

A simple Burndown Chart looks like this:
A simple Burndown Chart

Burndown Chart structure

The Burndown Chart shows two lines:

  • Effort Available, indicating resources still available.
  • Story Points Remaining, indicating story points left to do.

By comparing these lines and evaluating how well they are converging towards the end of the Iteration (or Release), the team can check their progress and their chances of overall success. More specifically:

  • Progress = Story Points Remaining  consistently close to Effort Available.
  • Success = Story Points Remaining reaches zero on the last day of delivery.

In other words, by comparing the lines the team can:

  • See how well they are doing.
  • Predict whether they will complete all the stories due to be delivered.
  • If not (or if they look like completing the stories early), the Burn Chart warns them that adaptation is needed.

Creating a Burndown Chart

Detailed instructions for creating and initialising a Burndown Chart are given in the Manage Burn Chart practice.

The initial Burndown Chart for an Iteration of 10 working days and planning to deliver 90 story points would look like this:

Burndown Chart Setup

Issues with Burndown Charts

Burndown Charts have their weaknesses.

  • Changing a Burndown Chart is more difficult:
    • E.g., if you want to add stories in the Iteration, the lines go below zero!
    • The chart is:
      • easy to redraw with a pen and paper, but
      • harder in a tool without being misleading.
  • Once changed, change is harder to interpret.
    • E.g., if a story is added and the Story Points Remaining is unchanged, is that because:
      • No stories were implemented? Or
      • At least one story was implemented, but the same number of story points were added on that day?
  • A Burndown Chart can also hide what is really happening in the project.
    • Rapid churn of stories in scope can be concealed if stories are added and removed at the same time.
      • So disruptive rapid changes become invisible.
    • Or the team may appear to be less effective than they really are.
      • Because credit for completing stories that are then removed from scope is lost.
    • And this disruption is often invisible to the Product Owner & other stakeholders.
      • Who may assume that the team is under-performing.
      • While the team is actually under increased stress.

One way of addressing these issues is to use a Burnup Chart instead of a Burndown Chart. See the Burnup Chart tab for details.

Burnup Chart

The Burnup Chart is more complicated and less widely used than a Burndown Chart, but it is more flexible and better at managing dynamically changing situations.

A simple Burnup Chart

A simple Burnup Chart looks like this:

Burnup Chart

Comparing Burndown and Burnup Charts

A Burnup Chart works like an inverted Burndown Chart:

  • The rising Story Points Delivered line should converge on the horizontal Total Deliverable Points line that crosses the top of the graph.
  • So progress and success are defined slightly differently:
    • Progress = Lines consistently converge on the end-date.
    • Success = Total Deliverable Points and Story Points Delivered cross on the last day of work.

But now the team can:

  • Identify & evaluate changes in scope.
  • Identify churn (i.e., rate of change).

Creating a Burnup Chart

Detailed instructions for creating and initialising a Burnup Chart are given in the Manage Burn Chart practice.

The initial Burnup Chart for an Iteration of 10 working days and planning to deliver 90 story points would look like this:

 

Burnup Chart Setup

Maintaining a Burnup Chart

In most respects maintaining a Burnup Chart is identical to maintaining a Burndown Chart.

The one important difference lies in how you change the number of story (or task) points against which you are tracking your work. Unlike a Burndown Chart, the Burnup Chart can easily be changed to show a different number of deliverable story points.

This is illustrated by this diagram:

Burnup Chart - updating deliverable points

As this example shows, the top line, at which the team is aiming, can be moved up (to show that points have been added to the Iteration’s scope) or down (to show that points have been removed).

The significance of the changes is clear: the team has a new target, and the ease with which this can be shown by a Burnup Chap makes the change very visible.

This is extremely important: Agile Iterations are set up to deliver a very clearly define scope. So:

  • If the scope increases (i.e., story points are added), then:
    • the team’s ways of working must change to accommodate the change, or
    • other stories must be rescheduled, or
    • the Iteration must be extended.
  • If the scope decreases (i.e., points are removed), then:
    • The Backlog should be reviewed for new stories to be included in the Iteration.

Note that the number of story (or task) points can be changed not only because stories are added or taken away. It is also possible that, following an external change, a Backlog Refinement meeting or other alteration, the list of stories in the Backlog remains the same but their size changes. This will change the number of story and task points, and must also be taken into account.

Workflow

For instructions on how to create, maintain and analyse a Burn Chart, see the Manage Burn Chart practice.

[tabby title=”Release Burn charts”]

Using Burn Charts at Release level

Burn Charts are simple tools that, taken individually, perform best at the level of the individual Iteration. However, when added together they can also provide valuable insight into how well a multi-Iteration Release as a whole is performing.

For example, by adding successive Iteration-level Burn Charts together, it is possible to predict whether or not the overall Release Plan is credible. These possibilities are illustrated below.

Release planning with Burn Charts

The Burn Charts for successive Iterations can be added together to plan and to predict the outcome of the Release of which they are part.

Burn Chart for Release Planning

Note that:

  • Successive Iterations converge on the Effort Available line.
  • Effort Available should normally be a straight line.
    • This reflects a constant velocity achieved by a team operating at a sustainable pace.

Evaluating a Release with Burn Charts

By adding successive Iteration-level Burn Charts together, it is also possible to predict whether or not the overall Release Plan is credible.

Burn Chart for Release Evaluation

Will this Release be a success? Consider the evidence:

  1. Iterations 1 and 2 appear to have been completed as planned.
  2. The team plainly failed to complete Iteration 3 as planned.
  3. Looking at the (implied) Effort Available line, at the end of Iteration 3:
    • the team recognised that their velocity is not as high as they originally believed, and so
    • they flattened the Effort Available line (i.e., reduced their expected velocity)
    • so now Iterations 4 and 5 have longer to run.
  4. Not knowing what other changes they made (e.g., which methods they changed or obstacles they removed, etc.), it can’t be said with certainty that the team will now finish as (re)planned, but the Effort Available line does now converge on the Total Deliverable Points line by the end of the Release – so success is more likely than previously.

Burn Chart analysis

Reviewing the Burn Chart is an important part of the intensive communications and commitment on which Agile relies.

Reviewing the Burn Chart

  • Progress should be reviewed regularly by the whole team.
    • It should always be reviewed as part of the Daily Stand-Up meetings, but also whenever the team or the Iteration Lead thinks appropriate.
    • This is the other side of the team’s explicit commitment to completing the Iteration or Release.
    • A collective review will ensure that the real impact of small variations or invisible obstacles is properly understood.
  • The Product Owner needs to be constantly aware of the real state of work.
    • Ideally this part of the routine Daily Stand-Up Meetings, which the Product Owner should attend.
    • However, if the Product Owner does not attend all Daily Stand-Up Meetings, the Iteration Lead should ensure that they are aware of:
      • The team’s real progress.
      • Any issues, risks & obstacles.
      • How problems are being managed.
    • This review will prompt the Product Owner to take action to deal with problems the team cannot solve or recurring issues – with the organisation as a whole, with the Extended Team, etc.

Common patterns

Unexpected patterns may arise for many reasons. (NB: These issues are not mutually exclusive.)

SymptomDiagnosisTreatment
Story Points Delivered/ Remaining do not reflect perceived progress.
  • Tracking of story progress incomplete or incorrect.
  • Complete or correct tracking.
  • Review tracking methods with team.
  • Are story points (e.g., story complications) being added to the Iteration in an uncontrolled way?
  • Identify added stories and review Iteration scope/schedule with the Product Owner.
  • Reinforce change control with stakeholders, Product Owner & the team.
 Burn Chart Analysis 1Story Points Delivered/ Remaining line significantly below Available Effort line.
  • Stories are easier than expected.
  • Add new stories from backlog.
  • Stories were over-estimated.
  • Review in Retrospective & correct estimating methods.
 Burn Chart Analysis 2Story Points Delivered/ Remaining line well above Available Effort line.
  • Stories under-estimated.
  • Review with team for root causes.
  • Adapt how work is being done.
  • Initiate a Spike.
  • If no workable solution, consider re-scoping Iteration.
  • Review in Retrospective.

Sample analysis

What does this Burn Chart say about this Iteration?

Burnup Chart Analysis

Here are some conclusions you could draw:

  1. Quite a lot of points were added at various points…
  2. … and quite a lot were removed.
  3. It took a long time to start delivering – the first points are credited at the start of Day 3.
    • Was Iteration 0 good enough?
  4. Points previously credited to the team had to be removed again when the story was removed from the scope of the Iteration.
  5. A defect was found in a previously accepted story and credit for those points was lost. So –
    • How good was/is the testing?
    • How effective was/is the user involved in this story?
    • How complete was/is the Definition of Done?
  6. A lot of new points we added to the scope – and as it happened close to the end of the Iteration, in practice the size of the remaining work has doubled.
  7. A total of 15 points were added between the start and end of the Iteration – a net increase in scope of 20%.
    • At the team’s usual velocity, that’s 2 days extra work – in a 10-day Iteration.
  8. A total of 45 points were either added or subtracted. In an Iteration that began with 75 points, that’s a total ‘churn’ of 60%!
    • The level of ‘noise’ created must have been huge!
    • Although Welcome change is a basic Agile discipline, so much change suggests that either the stakeholders don’t really know what they want or their communication channels  with the team are noisy.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?