Burn Up, Burn Down, and Capacity Utilization Charts
How can you even think about ‘constant improvement’ if you aren’t measuring your basic activity. Its taken rather more time than I’d like to admit to realize that Sprint burn up and burn down charts are not just an overly complicated way of saying “we’re not going to make our commitments this time”
Asking the team to say how much time they have worked on a story and how much time they think they need only adds a few minutes (once the team gets used to it) to the standup, and it allows more directed conversation around the upcoming activities for that story – so its basically a “good thing” all round.
Once you have that information, and armed with the simple formula for total daily team capacity of ‘6 hours per person’ – then by merely taking allowances for sick days and days off, it is easy to calculate the capacity.
When it comes to plotting the charts, I don’t do these during the iteration – and this is the big change. We’re not looking at these numbers to track commitment progress in real time. Instead we are going to use them to help drill into areas of possible improvement. As a consequence of this change in focus, the charts now get produced on a weekly basis, just prior to the retrospective. Reviewing the charts should be the first order of business – as part of the ‘data collection’ phase of the iteration. What can be gleaned from this data?
Firstly you can calculate ‘capacity utilization’ – simply put this is ‘Hours Worked’ / ‘Total Team Capacity’. As you’ve only been collecting hours actually spent on stories, this gives you the percentage of time that the team was directly working on stories. This is never going to be, and never should be I’d argue, 100%. The 2 hours a day having lunch, bathroom breaks etc is already factored in to the capacity (by assuming a 6 hour ‘perfect’ day) – but there are other activities such as planning for future features, meetings, triaging bugs, troubleshooting production issues and other essential activities. Having said that, looking at the capacity utilization on a regular basis should remind the team that they do actually need to stay reasonably focused on working on stories, and over time this figure can also be used by other managers to detect if the team is being sucked into operational/non-value-creation activities that needs addressing.
Capacity Utilization can be investigated on a day by day basis also, for deeper insight into how the team worked during any particular iteration, or to detect work patterns consistent across many iterations. The purpose might be for example to identify days in which the team appears to be ‘in the zone’ and being productive, and then protecting those days from interruption.
If the team hasn’t estimated how long each story will take when they were planning at the beginning of the iteration, this can still be roughly imputed by the first day (day ‘n’) of work on the story simply by assuming that Initial Estimate (Day zero) = Work Done (Day ‘n’) + Work Remaining (Day ‘n’). Taking only committed stories, the “planned” burndown slope can then be drawn. Hip pockets (un-committed or unplanned work) is recorded the first day that it is worked on (Day ‘n’) – and is NOT part of the planned burndown slope.
A potentially interesting statistic around the commitments is Total Commitment / Capacity. This will tell you how aggressive the team is in taking on board work. Used in conjunction with the (actual) capacity utilization, that might spur a change in behavior.
