As more and more organizations adopt Agile methodologies, the need for effective project management tools has never been greater. One such tool that is often overlooked is the burn-up chart. This powerful graph provides a visual representation of the work contributed by a team to a project and can be a game changer for managing its progress. In this article, we will explore the burn-up chart in detail and show you how it can be used to make realistic decisions about the pending work and the expectations around it.
The burn-up chart can help your team stay on track and deliver a successful project.
You will learn how to create these charts, what they are used for, and how they differ from other project management tools such as the burn-down chart or the Gantt chart.
By the end of this article, you will have a solid understanding of how the burn-up chart can help your team stay on track and deliver a successful project.
A step-by-step guide to creating a burn-up chart
A burn-up chart is a graph that shows the work contributed by a team to an agile project. It is created by plotting the duration of the project on the horizontal axis and the estimated stories of the product backlog on the vertical axis. Here are the steps to draw a burn-up chart:
- The horizontal axis represents the duration of the project. This is typically measured in sprints, which are all of the same duration.
- The vertical axis represents the estimated stories of the product backlog. This is an early estimate that will have to be updated as the project progresses.
- Plot the number of accumulated story points delivered for each sprint on the vertical axis, and the corresponding sprint on the horizontal axis.
- Draw a line connecting the points plotted in step 3. This line (in blue) represents the cumulative amount of software with value that has been delivered up to that point.
- As the project progresses, update the chart at the end of each sprint by plotting the new stories of the product backlog, and connecting the new points with the previous ones.
I recommend adding the backlog line, i.e. another line that represents the total size of the backlog. This line (in grey) will be updated as the backlog is refined and the estimates are updated.
I would also recommend adding the release plan as marks indicating the amount estimated story points of the backlog for each release.
The Burn-up Chart in Action
The slope of the line on the burn-up chart corresponds to the speed at which the backlog is being consumed, hence the name “burn-up chart”.
This type of graphics helps the team to find its sustainable rhythm that eventually will give predictability.
With this graph, you can see how much of the backlog has been completed, how much is remaining, and estimate when the project will be finished (this usually happens when the speed of the project stabilizes, after 4-5 iterations). But the most important contribution of this type of graphics is that it helps the team to find its sustainable rhythm.
See in the image above how we can answer the question: “when will this version of the product be finished?” Just draw the trend line (orange line) for the accumulated points already delivered (the blue line) and see where it cuts off with our current estimation of the product backlog (the grey line).
Notice that this projection is based on the team’s current velocity. However, it’s important to acknowledge that predicting the future with 100% certainty is not possible, especially when working with estimated story points, which can have a certain degree of uncertainty, subjectivity, biases, etc.
Therefore, it’s recommended to present this projection as a range of probabilities, and to also include a margin of error when indicating an expected completion date. This is represented by the orange lines on the graph, and the corresponding pink lines showing the range of completion dates.
This way of visualizing the progress of our project fits very well with an Agile approach because it gives a sense of something that has no clear end and focuses everyone to find a sustainable rhythm that eventually will give predictability.
The burn-up chart provides a realistic view of the work completed and remaining, which helps the team make informed decisions about the pending work and the expectations around it. If the team is falling behind on the estimated stories, the chart will show it, allowing the team to take corrective action.
To make our projection even more credible, it is highly recommended:
- that each version/release of our product is as simple as possible,
- everyone involved in building it has had enough discussion and is comfortable with the agreed estimates, and
- keep the estimated value of the backlog (the grey line) up to date.
Differences between burn-down chart and burn-up chart
The main obvious difference between a burn-down chart and a burn-up chart is that burn-down charts show the amount of work remaining over time, while burn-up charts show the total amount of work completed over time. The first works on expectations and the second on certainties, although both work on estimates. In a future article, I will offer some alternatives to simplify this estimation hassle.
While burn-up charts show the total amount of work completed, burn-down charts show the amount of work remaining over time.
If you are not familiar with burn-down charts, you can see here an example using Taiga in this public project.
Using a burn-down chart can help a team to focus on the remaining work and prioritize tasks to ensure that the project stays on track and is completed on time. It also provides a view of the progress made and the work remaining, and can help identify any potential issues or delays early on and manage stakeholders’ expectations.
On the other hand, burn-up charts can allow us to understand the progress made so far and motivate the team to keep working towards the final goal. It can also provide a clear visual representation of how much work has been accomplished, making it easy for team members, stakeholders, and managers to understand the progress of the project.
In summary, both charts can give different insights and you can use them together to have a better understanding of the progress of your project.
Burn-up chart vs Gantt chart: FIGHT!
The Gantt chart is another popular option in project planning, it is a type of bar chart that displays the start and end date of the tasks that make up a project, as well as their dependencies. Additionally, it can show the progress of each task.
Gantt charts are commonly associated with “waterfall” (non-Agile) projects, as they provide a clear view of the full plan with all the tasks that will be involved and their estimated durations, which creates a sense of an immutable end date for the project.
Let’s see how you can make both approaches coexist by drawing the release plan in a burn-up chart.
If at the end of a User Story Mapping workshop you ask the participants to agree on giving rough estimations of each version/release/slice of your project, then you can plot those estimations on the vertical axis of your burn-up chart, and you get a chart like this.
Now you can have a better understanding of the impact of any issue in our project, and we can have it well in advance. Obviously, as I said before, the sustainable rhythm is fundamental so that the projection we make is realistic.
Now, look at the following picture. If for some reason you have trouble getting a backlog estimate, you can also do it the other way around. In this chart, you can idealize the velocity of the team (the green line) as a straight line and estimate the duration (in sprints) of each version, so that you can have a first “snapshot” of your plan.
This is a good way to unblock the conversation as it helps stakeholders to realize their most important dates for the project. What you have below the horizontal axis is very similar to a Gantt chart… with all the pros and cons that it brings to an Agile project. Please, use it carefully.
Using the burn-up chart to manage deadlines
Managing expectations is an important part of the job of a Product Owner or Project Manager. At some point, you will have to answer the typical questions of “How big is this?”, “When will it end?” or “How much is it going to cost us?”. When making a project plan, it is common to face restrictions such as deadlines (e.g. a marketing campaign or the entry into force of a law). Therefore, it is necessary to make estimates.
You will always have software running, so you are eliminating the risk of hitting the deadline with nothing to deliver.
As we contrast earlier, contrary to the burn-down chart or the Gantt chart(*), the burn-up chart offers a vision of the constant evolution of the project.
If you are managing your project following the Agile principles, then you can take advantage of this to make your stakeholders understand that, if we get dangerously close to a deadline, the functionality at risk will be the one that provides the least value compared to what has already been built and that, in addition, you will always have software running, so you are eliminating the risk of hitting the deadline with nothing to deliver. Thus, you can reorder the priority of the backlog to ensure that no important functionality is left out of the product to be delivered before the deadline.
In the picture you can see how the estimated size of the backlog (the grey line) has been reduced, i.e. the scope of the project (or the current phase) has been reduced to give more guarantees to deliver before the deadline.
Another option is to increase the velocity of the team. This must be used carefully because we already know that increasing the team size does not automatically produce more work done.
And, of course, you can always ask for a change in the deadline. Maybe the difference is that, if the team is working at a sustainable pace, then you can have this conversation with enough time in advance.
(*) Yes, I know you can also do all of this with a burn-down chart or a Gantt chart, but it’s not that obvious. I believe that “Words create worlds” and it can also be understood as “Visuals create worlds”. 
Summary
In conclusion, the burn-up chart is a graph that shows the work contributed by a team to an Agile project. It shows the cumulative amount of software with value that has been delivered up to that point and the slope corresponds to the velocity at which the backlog is being consumed**. The burn-up chart is mainly used to help the team find its sustainable pace and to make an estimate of when the project could be finished.** However, the projection is based on the current speed of the team and should be represented with a range of probabilities and a margin. Remember that “estimate” is not the same as “prediction”. The burn-up chart is different from the burn-down chart or the Gantt chart as it is not predictive and does not have a certain end or ideal speed that the team should adjust to.
If you want to expand on this, you can read this book by Mike Cohn that is still very relevant IMO: “Agile Estimating and Planning”. And you can also know more about the Taiga reporting capabilities.
PICTURES: The hand-drawn pictures have been taken from this article that I wrote in Spanish long time ago in my blog.
And if, after reading this article, you still prefer the burn-down chart over the burn-up chart, I suggest you read this old but very good post by Pawel Brodzinski.
