Burn Up Charts for the Win

Most people are familiar with burn down charts, but many are not familiar with burn up charts. Burn up, burn down, toe-may-toe, toe-mah-toe, who cares? There are differences and they both add value in their own way. Let’s explore…

Burn down charts are usually used at the Sprint level, to monitor the day to day progress toward the Sprint Goal. The burn down chart shows how much work is remaining.

Burn up charts are usually used at the release level, to monitor the Sprint by Sprint progress toward some release or milestone. The burn up chart typically shows how we are trending toward a certain amount of scope or toward a date.

Both are simple tools whose main purpose is to offer an inspect and adapt feedback loop. This feedback loop can trigger important and difficult conversations sooner than later, which has many benefits, such as discussions about priority and increased levels of trust between the team and stakeholders.

To highlight the benefits, I would like to share a real life example of how a burn up chart saved the skin of an organization and allowed the teams to adjust to meet a critical deadline.

I was an Agile Coach supporting a development team that was focused on building a product to meet a deadline. There was A LOT of money riding on this. The deadline was artificially created by people not doing the work, which is a topic for another blog post.

The deadline was the end of September. Near the end of May, based on the estimated work, the burn up chart showed that we would be done sometime around early to mid July. Piece of cake. However, this was software development, so there were a few surprises awaiting the team…

Burn up chart near the end of May – what could go wrong?

The Product Owner met with stakeholders to discuss the product and what still needed to be delivered. After that discussion, there was a realization that not all of the work was in the Product Backlog. The Product Owner – Patricia – was panicking when we met. As the Agile Coach for the team, I supported Patricia in learning how to manage the backlog. I asked Patricia if she could create the remaining Product Backlog items – even if they were high level and not very detailed. She said yes, but it would take her a day or so.

After Patricia created the PBIs, we got the Dev Team together to do a quick affinity estimation exercise to get a rough idea of how much work remained. Patricia had written the high level PBIs on index cards, with some high level acceptance criteria on the back. I explained affinity estimation to the team and we spread the index cards out on the table. Affinity estimation is an exercise where you can quickly provide rough estimates on many backlog items.

One by one, people picked up the cards and placed them on the wall. Some quick discussion ensued, cards were moved and eventually, the team was satisfied with the relative estimation on the wall. The team had just estimated over 80 Product Backlog items in about 20 minutes.

Patricia plugged those estimates into our burn up chart and found that it was no longer a piece of cake. The data now showed that we would probably finish the work in early November – about a month past the deadline. Talk about a wake up call!

Burn up chart after affinity estimating the rest of the work

While this was a big surprise and there was some panicking, I saw this as a good sign because now we had visibility and transparency into the situation. We knew – roughly – where we stood and we could decide what to do next. As I mentioned previously, this allowed us to have an important and difficult conversation. Patricia and Sri – the Engineering Manager – met to discuss this issue with our VP of Engineering, Martyna, and the CTO, Tyrone. There was a lot of money riding on this end of September deadline.

After explaining the situation, Martyna and Tyrone asked what the team needed. After some discussion, it was decided that another team would start working from our backlog. In addition, the VP and CTO offered to form a new team that could also work from our backlog. It was great support and the executives didn’t hesitate for a moment.

After getting an idea of which work would still be left for our team to work on, we took another look at the burn up chart. It showed that we would finish somewhere around the middle of September. That was great news because (A) we now had a chance and (B) there was some wiggle room for when the next surprise presented itself.

Burn up chart after having two additional teams support the work

The teams worked hard over the next couple of months. A bit of scope changed, so there were some additional points added, but it was not substantial. Everyone showed remarkable focus and continued to have retrospectives to improve the way they worked together. In the end, the team hit the date and were celebrated for a job well done. It was a long, tough road. There were certainly scars, and we learned a lot from the experience. There were also many wins, lots of camaraderie and a stronger team as a result.

Burn up chart after the project was complete – The team hit the date!

When reflecting on this experience, I view the burn up chart as a game changing tool. It’s a very simple tool that was updated once per sprint. We made it visible in online dashboards for people to see because the team wanted to be transparent about our progress. It provided the team with an idea of whether or not we were on track to meet the deadline. Without it, we may not have known how far off the target we were. The burn up chart helped us have that difficult conversation which forced us to look in the mirror and address reality. The simple chart using high level estimates offered an inspect and adapt feedback loop that turned failure into success.

---

This article was originally published on March 9, 2020.