The venerable Burndown chart has been a central plank in tracking progress and predicting likely release dates in Scrum since I can remember. Over the last few years, the Burnup chart has gained popularity – lets explore why.

The strength of the burnup approach is in its simplicity and clarity, providing a view of net progress which helps predict when a product might be ready for release. Propagating the net velocity helps to show when the product might become releasable – the dotted blue line on the diagram.

Each data point of the burndown tells us how much “Work Remaining” there is at that point in time, i.e. the current amount of work left to release the product. The delta, the “Burndown”, between the points is the total of:

• Backlog completed satisfying the Definition of Done (burnt)
• New backlog added to the Release scope by the Product Owner
• Backlog removed from scope by the Product Owner

Burndown Drawbacks

The simplicity and elegance of the burndown also turn out to be its weakness.

Agile approaches embrace change as a positive aspect to increase the value delivered to the customer and business. So, it’s no surprise to find that release scope often changes significantly over time (usually in an upwards direction!). In a burndown chart, it isn’t clear what contribution scope change is making to net progress, often the impression is that the team simply aren’t working hard enough.

There have been a number of approaches used to enhance the burndown chart to provide deeper insight but to my mind these attempts lose the chart’s strengths - simplicity and readability (they also look ugly!).

Although a  team’s throughput can and does vary, working overtime, stronger coffee and more pizzas only has a marginal impact and is usually not sustainable on an ongoing basis. It turns out that the biggest lever we have to impact a release date is the scope. This is where the burnup chart comes in.

The Burnup Chart

The burnup chart tracks the throughput of the team and the scope separately so that the growth in the backlog is made very visible to all stakeholders. The chart illustrated to the right shows an all too common situation where the backlog grows at a similar rate to the team’s throughput.
We can add a forecast for likely team throughput based on their historical performance. Forecast approaches range from simple standard deviation through to sophisticated Monte Carlo simulation, modelling the team’s throughput data (Probabilistic Forecasting).
Now we add an indication of how the scope may grow over time. This chart shows a scope forecast range from zero additional scope through to an increase at the current average rate.
The intersection of the forecasts ranges provides something we call the “Landing Zone”. If we drop vertical lines down to the x axis from the intersection points is shows the release date range from the earliest likely, through to the latest expected dates. Working with a delivery date range is much more healthy and realistic than forecasting to precise dates.

Summary

We have found that when stakeholders see the impact of scope on delivery dates it removes some of the emotion from the debate and instead creates a healthy discussion and focus  on those backlog items that are critical to release versus those that are not.

While the Burndown chart is an elegant and simple view of release progress, the Burnup drives more healthy conversations that help shape the Minimum Viable Product. If the Burnup is used all the way through a release, it will help prevent the pressure on the team to work at an unstainable level and/or reduce quality levels to hit an unrealistic scope and deadline combination.

Agile process tooling is catching on with growing support for burnup chart functionality. If you use JIRA, TFS or VSTS then take a look at SenseAdapt which supports the burnup and a multitude of other handy charts.