A little while ago I was talking with a Product Owner at a company just beginning its Scrum adventure. The topic of discussion was the Sprint burndown chart, its data points, and how to interpret the trend line indicated by those data points. The fact that the Sprint burndown is designed to serve as a planning tool for the team was not an issue. The Product Owner’s concern was to ensure that the information radiated was interpreted appropriately by others in the organization, particularly those who might consider an upward spike in the burndown to be a sign that the team spent the day water skiing instead of working.
A teaching moment ensued and after a brief conversation and help from a colleague of the Product Owner, the purpose of the burndown was clear and agreement reached on using task hours remaining, among the alternatives I offered up, as the data point collected.
The discussion then turned to why one would use a burndown chart instead of tracking hours expended by the team in pursuit of the Sprint goal. Again, a teaching moment about the purpose of the chart, and then the insightful comment from the Product Owner that tracking hours expended would be plotted on the “Burnout Chart.”
All joking aside, this strikes me as an interesting idea. Perhaps teams that are having difficulty working at a sustainable pace should use a Burnout Chart internally as a way of monitoring collective adherence to this vital agile principle. Perhaps teams in that situation could use the Burnout Chart to raise unsustainable pace as an organizational impediment.
Next time you notice that your team is showing signs of exhaustion, perhaps a Burnout Chart would be a useful way of determining – and radiating – the cause.
All for now….