Wednesday, November 17, 2010

Burning up

I am growing increasingly fond of the Agile development method. It really has a transformational effect on how the teams operate and relate to their work.

Now working on a team of 26 people in four scrums spread across four geographies and four timezones, we have stepped up our reliance on Rational Team Concert dashboards to keep track of how each team is progressing. Each scrum team still has daily standup meetings and scrum of scrum meetings with the product owner, scrum masters, and stakeholders. Though the emphasis during the scrum of scrums is on the reporting from each scrum master, we have started to appreciate and use “burnup” charts as the backdrop for these meetings.

Disclaimer: I am an IBM employee with access to an internally hosted instance of Rational Team Concert. For small teams of up to 10 people, and with some functional restrictions, RTC is freely available at

There is ample literature on why “burnup”  charts are superior to “burndown” charts, but RTC combines project tracking and team information to provide significantly enhanced visibility on project progress. I produced a couple of heavily data-altered versions of our actual “burnup” charts as examples.

RTC Burnup Data Series


  • “Total Capacity” indicates how much work the team can execute on a given period. It is always a flat, straight, line. RTC uses information provided by each team member on their availability in terms of hours per day, vacation, and holidays.
  • “Planned Work” indicates how much work is actually planned for a given period. For any sane project, it should be under the “ Total Capacity” line at all times, otherwise low-priority work should be moved from that period immediately. In the example chart above, this can be observed on 11/16.
  • “Expected Complete” indicates how much work should be completed  over time so that all planned work is completed at the end of the given period. Always a straight line starting from 0 hours and ending at the total amount of planned work hours.
  • “Completed Work” indicates how much work the team is logging in the system against the tasks assigned to each individual. In very simple terms, "completed work should be at or above the “Expected Complete” line, indicating the team is on schedule or ahead of schedule. In the example chart above, it is possible to see the team recovering from a slow start and exceeding expectations after 11/10.
  • “Linear Complete” is a liner regression of data points in the “Completed Work” series. It projects how much work will be done at the end of the given period. This line should be at or above the “Expected Complete”  line, otherwise remediation is required, such as moving distracting low-priority work from that period of time.  In the example chart above, that line is slightly above the “Expected Complete” line, a good sign, indicating all work being completed one or two days ahead of schedule (where it crosses above the “Planned work”  line) .
  • “Capacity Burnup” indicates how much capacity the team is “burning” during a given period. It goes up whether the team is working or not, because the time available to work in that period is reduced every minute. Ideally you want the “Completed Work”  line to be at or above the “Capacity Burnup” line, indicating that team is burning up its capacity on actually planned work. In the above example chart, notice how the first half of the period has less completed work than the capacity being spent, a clear indication that people are being diverted from the planned work.

A non-ideal example

The first example was somewhat benign in that execution would have been well planned and completed ahead of time. Now lets look at another hypothetical example, with some planning and execution challenges:


The first warning sign is a number of data points *above* the “ Total Capacity” line, specially the “ Planned Work”  line. In a real project, this chart would be telling the project owner to move content outside the given period right at the beginning. Notice how the “Planned Work”  line does go down on 11/3, only to steadily climb up again. RTC does have an “Estimated vs Actual Work” chart that can clarify whether that increase in “Planned Work” is the result of new work being added to the period or the result of planned work taking longer than planned. I like to have both side by side in the same dashboard.

The second warning sign is the “Completed Work” line being significantly above the “Capacity Burnup”  chart line, an indication that the team worked a fair amount of overtime during the period. Though the “Linear Complete”  projection is slightly above the “Expected Complete”  work, the actual data points for “Completed Work” show the team running out of steam towards the last days of the interval (complete work goes from above expected to below expected around 11/10) .

In summary

A quick glance at a “burnup” chart, assuming somewhat accurate reporting by the team, will immediately point at any action required by the scrum master and product owner. This is the cheat-sheet I share with others reading these charts, which takes a lot of the guess work about how teams are doing.

  1. The “Capacity Burnup” line should always be at the top of all other lines or content must be moved out of the period in question.
  2. The “Linear Complete”  and “Completed Work” lines must be on top of or above the “Expected Complete” line, otherwise they indicate the team will overrun its time budget.
  3. The “Linear Complete” line must be somewhat matched to the “Capacity Burnup”  line. If it is significantly below that line, it indicates the team is working on something else other than planned content (e.g. spending 2 days reimaging failed hardware) ; if it is significantly above the capacity burnup, the team is working overtime and may run out of steam at the end of the period.
  4. Steady, rather than abrupt, increases in the “Planned Work”  line typically indicate the team taking longer on tasks than originally planned.
  5. Abrupt, rather than steady, changes in the “Planned Work”  line typically indicate work items being moved in and out of the time period. The product owner should always be aware of the causes for those changes.