Audio Version: SPaMCAST 133
A burn-up chart is a graph that tracks progress by accumulating a measure of functionality as it is completed over time. The measure of functionality can be compared to a goal, such as a budget or release plan, to provide the team and others with feedback on progress. Graphically the X axis is time and the Y axis is accumulated functionality completed over that period of time. The burn-up chart, like its cousin the burn-down chart, provides a simple yet powerful tool to provide visibility into the sprint or program.
The burn-up chart can be thought of as the mirror image of the burn-down chart, but it is generally extended over multiple sprints to show progress as the project builds toward release and product delivery.
As with its close cousin, the burn-down chart, there is not really a formula for a burn-up chart as much as there are instructions on how to graphically represent progress against a goal. In its simplest form, the X axis represents time (days, sprints, or releases) and the Y axis represents the accumulated functionality completed over that period of time (stories, value or cost).
Using the basic form of the graph as a base, other data can be integrated. The release plan, which typically includes an outline of the funcitonaity (in story points or function points) for a number, can be overlaid on the chart to give visibility into the anticipated flow of the project. The project budget can be added to the chart to provide feedback on budget utilization; the budget line can be raised or lowered to show how much work remains as changes to scope are incorporated. Value can be tracked on a second Y axis to show the team the relationship between work and value. The burn-up chart is one chart covering the big three topics of on-time, on-budget and on-schedule.
The burn-up and burn-down charts have many similar uses such as planning and monitoring. Rather than repeat the discussion already published in the Metrics Minute: Burn-Down Charts, I will focus on the major distinctions between the charts. The unique power of the burn-up chart can be found in its ability to provide a holistic view for the project. The view is holistic because the chart can be used to show progress over sprints and releases. To use a photographic analogy, the burn-up chart provides a panoramic view rather than a normal picture, which is narrow slice of real life.
James Shore suggests developing a risk-adjusted burn-up chart to make and meet commitments. It tracks commitments alongside progress. Adding a continually refined risk-adjustment to the burn-up chart accounts for Steve McConnell’s cone of uncertainty (the cone of uncertainty theorizes that plans are less accurate the farther in the future they are projected). Actual performance (delivered functionality) can be tracked against commitments; significant gaps would signal a need to adjust the release plan if performance strays to far from what is possible as established by the cone of uncertainty.
One issue is that a burn-up chart provides visibility at a high level, rather than progress at a story level. This causes some people concern. Burn-up, like burn-down charts, are not designed as a precise report on where each story is on a day-to-day basis, but rather as a view of how functionality or value has been delivered. The burn-down chart and the detail found in a card wall (or proxy) are better tools to drive a project on a day-to-day basis.
The second issue occurs because value is recognized only when a piece of work is complete. In software projects, this equates to functional code that has been integrated and tested. Value is not recognized until work in process is complete. Alistair Cockburn suggests recognizing functionality when ‘done’ yields more reliable information about the projects actual state than the classic plan based mode. The problem is that if the increment of work is too large the graph will resemble a J with the majority of value accumulating late in the sprint leaving room from negative surprises. The way to avoid this issue is to increase the granularity of the units of work (break the work down in smaller pieces). This will allow the team to recognize value more quickly, and therefore smooth out the curve.
The third issue is also related to the choice of unit of measure for use on the vertical axis. The unit needs to be predictable early in the process. Most physical measures, such as lines of code, can’t be known until you’re very near the end of the sprint or projects. Leveraging a metric that can expand even though scope has not changed muddles the information provided by the chart, thus reducing its usefulness. This issue can be avoided by choosing unit of measure that can’t expand unless additional work is accepted into the sprint or project. Functional measures, such as Quick and Early Function Points, that translate stories or requirements into numbers are a disciplined/formal mechanism for addressing the unit of measure issue without adding overhead.
Related or Variant Measures
- Functional Size
- Burn-down Charts
- Earned Value
- Cumulative Flow Diagrams
The most significant criticism of the burn-up chart is that, in its basic form, it does not reflect the flow of work. Work in some sprints does not lead to completed functionality, therefore value is not accrued. This leads to a feeling that partial credit should be given, splitting stories using waterfall stages or other bad practices all in a rush to show progress. One solution is to use flow metrics by using techniques like Kanban and cumulative flow diagrams is a way of accruing value on a more granular basis if the organization can’t find a measure to split user stories so they can be completed properly in a single sprint.
The final criticism is that burn-up charts do not predict surprises. This is a false criticism as a surprise by definition is not predictable. Use the value at risk metric as a risk management tool to help avoid surprises, but vigilance should never be supplanted by measurement.