Agile Tools: The Burn-Up Chart

Organisations are embracing agile delivery models at an unbelievable rate; a huge range of methodologies are being adopted in order to allow large corporations to make sense of doing things in a new and unfamiliar way.

All to often we see agile being interpreted as an “IT Thing”; as a result other parts of the organisation feel that they don’t need to adapt or change which introduces huge practical challenges in changing the culture.

Within my own organisation one of the biggest challenges we have faced is that stakeholders struggle with the concept of not being given a specific date when something will be delivered.

Stakeholders who are close to the delivery understand that we are prioritising feature developments according to business need. When a significant amount of money is being invested in a development which can’t go live until a critical mass of features are developed, it is often difficult to articulate a specific date on which that critical mass will be achieved.

The Burn-down Chart

The burn-down chart is one report which is commonly used to demonstrate and track team velocity. The burn-down chart is a great document for showing individual team progress, and for demonstrating how velocity improves over time. However, it does not help us visually present stakeholders with an indication of when work will be completed. To those who are not close to the work of the team the burn-down chart doesn’t give enough information because it only shows a snapshot of a single sprint which fails to show the whole picture.

The Burn-up Chart

One solution to the “When will it be delivered” problem that I have found effective is to create a Burn-Up Chart. The idea is simple:

  1. Estimate all stories in story points.
  2. Add up the total number of story points that need to be delivered in order to deliver the critical mass of work that people are interested in.
  3. Create a graph, the Y Axis should plot story points and the X axis should show sprint numbers (in our organisation stakeholders preferred the X — Axis to show dates).
  4. After each sprint plot the number of story points completed.
  5. Work out the average number of story points completed in each sprint and use this to forecast forward how many points will be completed during each future sprint.

The graph can now be presented to stakeholders and it clearly shows the estimated completion date based upon known velocity.

The burn-up chart can be used when you have a single team and also when you have multiple teams working on the same delivery. Just add all of the story points together and accurately plot the combined total achieved during each sprint.

I have also found that the burn-up chart is a great way to explain why a delivery date might change.

Scope Change

If scope changes part way through a delivery you can adjust the target line to reflect the point in time that the scope changed. This also gives an indication of how much extra work has been introduced.

Conversely it is straightforward to model what the delivery date might look like if scope were to be reduced.

Velocity Reduction

If velocity significantly reduces during a sprint it becomes immediately obvious to stakeholders. This should then inform a transparent conversation about what caused velocity to decrease at that point in time. Expectations can be managed at the earliest opportunity which ensures there are no surprises when a committed date isn’t achieved.

The burn-up chart is one tool which can be used to help organisations understand how delivery is progressing. It is particularly useful in businesses who are new to agile or have difficulty in breaking down work into small increments which can be fully delivered in a single sprint.

Have you used any alternate strategies to answer the question “When will the work be delivered”? If you have any ideas please reach out to me on twitter @stevewestgarth




The Engineering Leadership Network is a community for Engineering Leaders. A safe place to share ideas, thinking, seek advice and to network.

Recommended from Medium

My Cisco Ideathon Internship Experience

Overthinking, or: How I learned to stop worrying and love the bomb

Unity… she can’t always be trusted.

Methods to Login Azure Container Registry

E2E iOS UI Tests: Lots, Green, on PR

A Comprehensive Guide To App Development Cost Breakdown

How to Use Robot Framework

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Steve Westgarth

Steve Westgarth

Steve 🏳️‍🌈 is the Global Head of Engineering at GSK Consumer Healthcare where he heads up the Software Engineering function.

More from Medium

Risk Management in Scrum

What are good OKRs for a Scrum Master?

Long term damage from the Estimate blast radius.

Agile Software Development: Back to Basics — Part 3