In a recent discussion with an ‘Argument of Agile Coaches’ (an apt collective noun for a group of coaches), the question was raised:
“Do we really need sprint Burndown charts for an Agile Team?”
A Burndown chart is a graphical representation of time left vs work left to do and is used to view daily progress against the work committed by a Team for the Sprint. This can be a great tool to visualise overall progress and highlight stuck (or ‘Blocked’) items.
Example of Burndown chart showing a challenged sprint with good progress.
Quite often, the overhead of having multiple artefacts to maintain (team boards, release burnup chart, sprint burndown chart, stories, tasks) can seem pretty daunting for an Agile Team starting out on their journey.
The visibility of work ‘not done’ is almost always more valuable to the Team than the relatively minor overhead of these administrative tasks.
It can help the Product Owner, Scrum Master and Team to start asking questions:
- “Why is this backlog item taking forever to complete?”
- “Where are our real blockers?”
- “Will we meet our Sprint Goal and our team commitment?”
- “How can I help?”
The transparency and visibility is key to understanding real progress – as is being in a safe environment to talk about it.
So is the thing that is actually being tracked.
“Should we track hours and Tasks completed or Backlog Items completed?”
Tracking hours or tasks can be a helpful tool for an Agile Team. In a Retrospective, they can be useful to understand the estimation process used or how the Team were not verbal enough about a particular blocker. It can help inform Sprint Planning.
But there can be a false accuracy associated with estimating at such a granular level and it can veer the Team away from collaborative ownership.
The main issue with tracking the Tasks of a Backlog Item in a Sprint Burndown is that it can show false progress.
Picture the scene.
A Team has committed to 5 stories with 10 Tasks each. They have 50 ‘things’ to do in a Sprint to meet their committed Sprint Goal.
Everyone starts picking off Tasks based on priority and as long as they finish all the Tasks in the Sprint, they are golden.
Of course, unexpected things happen. A Task takes twice as long due to an unknown problem with an API. Or there was illness in the Team. Or there were deployment issues. Or. Or. Or.
Fast forward two weeks and the Team have 40 tasks done at the end of the sprint.
Not bad going Team! 80% of our sprint backlog is complete!
Hang on there a minute. We didn’t complete any of the Backlog Items to 100% ‘Done’.
The 40 Tasks that were finished actually equate to a grand total of 0% of the Sprint Backlog.
Everything was tracking perfectly! We only had ten things left to do!
The real issue here is that the focus of the team was completing Tasks rather than completing Backlog Items. They were not swarming on a single item to get it through to done.
And as my Dad said to me growing up:
“3/8ths of nothing is nothing, Jon.”
If a small tweak was made to the focus of the Team towards completing Backlog Items (and not just the completion of all Tasks), it would mean that four Backlog Items would now be finished and ready to ship. Instead of zero.
There is a human impact to this too.
Seeing amazing progress tracked throughout the Sprint on a Burndown chart, only to be told that none of it was useful (or shippable) can be a blow to team morale.
And a Product Owner’s confidence in the Team.
This approach was coined in a recent discussion as:
Everything is green on the outside but red in the middle.
You think (and report outwards) that everything is going OK but actually it’s not.
And you can’t see how much red is inside the watermelon until you break it open. Which is too late.
A Team should be looking to track the small, bite sized chunks of stuff needed to deliver their shared Sprint Goal.
Some things get over the line, some others get left behind. But everything is small enough to measure the real progress of 100% Done throughout the Sprint.
The issue this solves is a lack of transparency, without which inspection & adaptation cannot happen.
To continue the fruit theme, we could call this:
At the end of a Sprint, it’s not a surprise what is finished (or not) because you are tracking the whole Backlog Item completion from the kick-off of the Sprint.
In our continued discussion, the final question ended up being:
What is the value to the Agile Team of Sprint Burndown charts?
Of course this is relative to each Team.
As Coaches we help each Team to identify the areas for them to improve and show them how.
In this instance, if the Burndown chart helps the team visualise their work, provide transparency and an opportunity to have conversation – it can be a really good thing.
As long as it’s the right size of fruit that is being talked about.