If you are familiar with Scrum then you will recognize this chart as an iteration burndown. One line is the ideal pace for completing the work planned, the other is pace at which the team actually completed its work, and the chart is intended to communicate the progress of the team during an iteration.
If you were the product owner, or other stakeholder for this project, what would this burndown actually tell you? As in all burndowns, the remaining work line always reaches zero, but how did the team actually get there? How much work did the team really complete compared to what it expected to complete? Should you be pleased with the progress of the team? Did you see the visible, predictable progress that we hope to achieve by working in iterations?
Experienced agile teams will know the answers to all those questions, but not particularly from the burndown. A team that is collaborating well will be in sync with the rhythm of the iteration and can interpret the burndown in context of what they already know. The iteration review and demo will just confirm (and celebrate) that.
Those new to the ways of agile teams however may struggle to understand the burndown and the iteration review and demo could be a significant shock to the project stakeholders; not the openness and transparency agility aims to achieve.
Consider then an alternative; actually an iteration burnup that provides some more information to communicate how the team is progressing.
First the legend:
- Red – the hours the team collectively expected to have available to work during the iteration.
- Black – the work the team initially planned.
- Blue – the revised plan as the team either discovers new tasks to complete that were not initially planned, or removes tasks not needed or that will not be completed.
- Green – the work team actually completed.
Note the completed line is not actual hours worked; it is the sum of the original or revised hours estimated for the tasks completed. Tracking actual hours is tempting, particularly for traditional project mangers, but it is not at all helpful in determining the pace or progress of the team. Knowing that it took 15 hours to do a task I thought was only 8 doesn’t help me understand how much work I have left to do for the iteration. Nor does it help me assess the accuracy of any of the other estimates.
I want to know what work is complete and what work remains. From that I can better forecast what work will be completed for the iteration based on the reality of the team’s progress. The only interest I have in actual hours worked is to discourage the team from working significant overtime to meet the iteration goal.
So what can I deduce from this burnup?
- First, the team is likely overly optimistic about the hours they are really available to do productive work for the iteration.
- Second, the team is not adjusting the work in iteration based on the reality of their progress. It was clear from day 2 forward that the iteration goal was in jeopardy, even as work was being added to the iteration, but the team did not react to it until day 9.
- Third, the team is completing work at an erratic pace. Work completed actually varies from 9 hours on day 6 to 48 hours on 4.
Certainly there are a number of circumstances that could cause these results, but now I have a clearer picture of the questions to be asking as the team plans future iterations.
- Does the team feel safe in stating their true availability for the iteration?
- Does the team know enough about the work they take on?
- Is the team breaking the work down into small enough tasks to accurately estimate?
- Is the team empowered to say no to new work being added to the iteration?
- Is the team able to assess their day-to-day progress and make good decisions about what work they can really complete?
Simply completing the number of hours of work intended during an iteration is not the goal however. That’s just a means to an end. The end is for the team to routinely deliver working software at the end of every iteration that adds the new features or functionality deemed most important by the product owner. A team that can accurately access the work involved, and monitor it closely throughout the iteration can then also decide how to achieve the best possible result for the iteration. That may be to set aside some work to complete later to ensure that at least one new working feature is delivered for the iteration; or it may be the discovery that more can be achieved that initially thought and another feature can be added and delivered.
No tool will make a team adopt better agile practices. Finding ways like this to help the team understand why they achieve the results they achieve however, will help the team make better decisions and grow into those practices. That’s what agile leadership is about.
