Metric: Release Burnup and Cumulative Burnup

 The Metrics and Reporting View looks at the various feedback cycles, metrics and reports in Holistic Software Development.

Are we on track or not? When will we be done?

A related metric is a Release Burnup (for a product delivery team) or a Cumulative Burnup (for a steady state maintenance team).

A Burnup is an established metric in agile processes that indicates what the current scope target is (the number of stories or story points in the current release) and then tracks completion towards this target over time. The gradient of this line is driven by the Team Throughput and is usually called the team’s Velocity. Velocity is useful to extrapolate towards the intersection of work getting done and the required scope to indicate a likely point of timebox, release or product completion.

A traditional Burndown is simply an upside down version of this graph. We prefer a burnup because it allows for real life intervening in plans and the scope changing either up or down. In terms of perception the team can feel more positive about achieving something as the line goes up as progress is made. In a Burndown, as work is completed the line goes down as remaining work is reduced.

When there is no release or useful timebox (e.g. in a maintenance or purist continuous team) then a simple calendar based timebox (such as a month or quarter). Instead of a target scope we simply track the cumulative number of created items. This results in a Cumulative Burnup graph.

An ideal Cumulative Burnup graph will show that the number of completed items keep roughly in line with the number of created items. An unhealthy graph will show the number of items created outrunning the number of items completed. This indicates over-demand on teams.

Cumulative Burnups that count items rather than abstract points can be useful across teams and even across entire development organizations to indicate how well the organization is keeping up with demand, how stable that demand is and how stable the development supply is. Note that the only real difference between a Release Burnup and a Cumulative Burnup is the amount of up-front planning and therefore creation of items. In our experience the number of items in a Release always fluctuates and should never be considered as a fixed value.

Release Burnups can’t be easily aggregated because Release timeboxes will be different for different products. However, simplifying to Cumulative Burnups allows for easy aggregation.

In terms of Behavior Driven Measurement we have seen the following behaviors driven by tracking Burnups:

  • A desire to create less items
  • A desire to close items more quickly

Since this metric emphasizes speed over quality we balance it with the Quality Confidence Metric. To avoid very low priority but slow items never getting done we might also keep an eye on the age distribution of currently open items.