The “Perfect” Burndown Chart: A Case of Tools Over Interactions

They called me in to coach this Scrum team because their product owner wasn’t accepting their user stories. “I don’t understand it,” the Scrum Master told me. “Our burndowns are perfect!”

And I looked, and they were. I mean text-book perfect. Going back at least six sprints, the team’s daily completed task rate nearly always matched the guideline set out by the tool. They rarely added tasks after the first day of the sprint and never after the second. Tasks totals matched their overall capacity, were updated every day, and all were completed by the end of the sprint. It was perfect.

It looked too perfect. As I learned more about the team, I discovered I was right. Their tasks were generic: “write code,” “test code,” “deploy code.” And at the end of every workday each team member moved an appropriate number of tasks to the “done” column. Their “tasks” were basically just timecards.

This is an extreme example: an untrained team sprinting for three months without understanding the purpose of tasks and burndown charts until I stepped in. It took little effort for me to discover what had gone wrong.

And I don’t blame them. The team had no training in Scrum, and they were technically using the burndown chart correctly. Tasks had estimates (or at least there was a number in the “estimate” field of each task), and they were updated daily. But the tasks did not accurately predict the work needed to get their user stories accepted. It just showed they were busy working.

A Useful Burndown

• Team members write tasks to help them understand the specifics of the work required to implement each user story and share that understanding with the rest of their team. Tasks are intended to break down user stories into specific bite-size chunks, typically items that can be completed in under a day each.

• The burndown chart helps the team visualize how close they are to completing that work by the end of the sprint. It’s only meant to be used by the team.

• For the burndown chart to work:

• Tasks must have estimates (usually in hours).

• Tasks must be updated each day, recording the estimated remaining work left.

Personally, I don’t like burndown charts. Don’t get me wrong – I love breaking down work into small, bite-sized tasks (preferably less than a day each) so everyone can collaborate on, understand, and follow the work. I think tasks are incredibly useful. But I have problems with estimating tasks — at least estimating them accurately enough to properly leverage a burndown chart.

Online Agile tools make it easy to generate a burndown chart (I’ve done them by hand with graph paper; online tools are much better), but estimating tasks is time consuming and typically either imprecise (rounded) or inaccurate. I always prefer imprecise, accurate estimates to inaccurate ones, but imprecise estimates don’t usually produce useful burndown charts.

Instead of using a task burn-down chart I suggested the team use a story burn-up chart. Instead of tracking how many tasks are left to do to complete user stories, they track how many user stories, or story points, have been finished and accepted. They track the work completed – which is more accurate and precise – rather than the work left.

Once the team saw the new chart, they realized a) they had serious scope creep and b) that they needed to engage with their Product Owner a lot more. But those are both subjects for other articles!

#agilesoftwaredevelopment #scrummaster #productowner #agileteams #fishingwithdynamite