How to Create a Burnup Chart
In my blog about forecasting reality, I discussed the importance of Scrum Teams updating forecasted milestone dates at every single sprint review. A burnup chart is an essential tool in your toolkit to make this happen. Burnup charts are a powerful, visual way for teams to keep the organization up-to-date on progress relative to their goals. Burnup charts reduce the need for additional status meetings when they’re shared at sprint reviews and posted in highly visible places. With a single chart, teams communicate the likely completion date of their next milestone, how that forecast has changed over time and the reasons for any changes that occurred. By keeping progress transparent to all, Burnup Charts help teams to make important adjustments sooner.
Many teams I work with like the idea of sharing their burnup charts at sprint reviews but are not sure how to create one or get the information needed to populate it. In this article, we’ll cover both how to create a burnup chart and how to populate it.
First, let’s talk about how a burnup chart works.
The burnup chart above tracks progress towards a goal. The blue line tells the story of scope changing as more is learned about the product. This line rises when new user stories are added to the backlog and falls when user stories are dropped from the backlog. The red bars display the cumulative total of story points completed and are used to tell the story of team velocity. When the points completed (red bar) meet the blue scope line, the goal being tracked has been met. When the top of the red bars forms a line curving up (sprints 1-5), the team’s velocity is accelerating. When the top of the red bars forms a line curving down (sprints 5-9), the team’s velocity is decelerating. When the top of the red bars forms a straight line (sprints 9-13), the team’s velocity has stabilized. Stable velocity is a sign of a mature team and is helpful for planning. The yellow line is a forecast of when the team will meet their goal if they were to continue to progress at the pace of their average three-sprint velocity. The black line points to the forecasted completion date and is where the yellow forecast line crosses the blue scope line. In the example below, the forecasted completion date is at the end of sprint 24, which is 02/28/2022. The forecasted date is not a commitment; it is the most likely completion date given the information available and is expected to change every sprint. The forecasted date often shifts by a wide margin at the start of an initiative and stabilizes as the team nears completion.
A cautionary note about the forecast line: Avoid making predictions about your team’s velocity based on what you hope will happen in the future. So, don’t add 20% to the forecasted velocity because a high performer is supposed to join the team next month or because the team’s velocity is currently accelerating and you think they can continue to get faster. The 2020 Scrum Guide is astute in stating that “in complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making.” Stay objective and avoid the politics and posturing that go hand-in-hand with manipulating these numbers by using only the team’s rolling three sprint average velocity for forecasting milestone dates. Remember how important truth-telling can be when communicating with the team, leadership and stakeholders. If the improvements you are hoping for do happen, then they’ll be reflected in a future iteration of your burndown. It’s also helpful to know that the words “estimate” and “commitment” were replaced with “forecasts” in the 2013 Scrum Guide. Due to the inherent unpredictability in the market, the pace of development, technology, and customer expectations, forecasts tend to become outdated quickly. Forecasting strategies that are low-cost, continually revisited and develop a shared understanding among the people who will do the work tend to perform the best. Burnup charts aim to provide as much predictability as possible while still upholding the fifth value of The Disciplined Agile Manifesto: Transparency over false Predictability.
Here’s how to get the information needed to populate a burnup chart:
Calculate your average three-sprint velocity by adding up the total number of story points completed from the last three sprints and then dividing by 3. For instance, if your team’s velocity for the last 5 sprints was 20, 23, 27, 13, and 32 then the average three-sprint velocity would be (27 + 13 + 32) / 3 = 24. Some teams prefer using the last five sprints or getting fancy with binomial distributions. All of these options are fine as long as you are consistent with how forecasts are generated each sprint.
Calculate the value for the scope line each sprint by adding up the total number of story points known to complete the effort. This includes all story points that have been completed and are yet to be completed to meet the milestone you’re tracking. This is often the most difficult part because many product backlogs are littered with stories that have not been estimated. If this is a problem you share, check out this article on how to quickly and efficiently estimate your Product Backlog.
If you are in the middle of an initiative, don’t worry too much about constructing a burnup chart that tells the story of the past. I like to describe the activity of attempting to piece together past snapshots of the product backlog as burnup chart apologetics, which is time-consuming and inaccurate in my experience. Keep things simple by starting your burnup chart with whatever information you have available today and then adding to it each sprint.
Fiddling with excel formulas and charts can be time-consuming, so we’ve put together a template you can use to get started right away.
My challenge to you is to provide a visual update of your current overall status at your next sprint review using a burnup chart. Here is a script to get you started on how you might present this information:
“Our total scope to reach the next milestone changed in the following way <what changed> and here is why <reason for scope change>. Our velocity this sprint was <velocity> and is currently <consistent/accelerating/decelerating> and here is why <reason for velocity change>. The completion date that we’re forecasting given the information we have available today and which we expect to change every sprint is <insert forecast date>. We commit to sharing updated forecast information with you at every single sprint review. Now let’s have an open discussion about the questions you have and what you would like to see our Scrum team work on next.”
So, now you’re ready to go. You have the information and structure to create a burnup chart that can effectively represent the position of your project at your next sprint review.