Watermelons or Grapes? Visualising work not done for Agile teams.
A murder of crows. A school of fish. An eloquence (I kid you not) of lawyers.
I’m pretty sure that the most apt collective term for a group of Agile coaches working together as a team is “an argument of coaches.” (I’m only half-kidding about that.) If I could coin that term, I could say proudly that I get into a lot of arguments.
But enough of my sterling wit. I want to talk about fruit.
Charts: Who needs ‘em?
In one “argument” in which I participated, the following question was raised:
Does an Agile team really need sprint burn-up charts?
It’s a fair, and understandable, question. The maintenance overhead of multiple charts — and boards and tickets and stories and tasks — can seem daunting for a team when it starts out.
But. But.
Be clear
While the burden of these administrative tasks may be an annoyance, there’s an enormous benefit to making work not done highly visible. And it’s not that we then all get to feel bad about what we’re not accomplishing, or get to put further pressure on ourselves and our colleagues. This visibility isn’t related to punishment. It’s related to clarity.
Humans are visual creatures, and a sprint burn-up chart can help bring what really matters into sharp focus, and do it quickly. Seeing the work we’re not getting done can help the Product Owner and Scrum Master, as well as the whole team, start to ask different questions — the right questions.
These questions might include, Why is this story taking forever to complete? Where are our real blockers? Will we meet our sprint goal and our team commitment?
The transparency and visibility afforded by the dreaded charts are key to understanding real progress.
Be exact
Another key to moving ahead is knowing exactly what thing we actually need to track. Is it stories, or tasks completed? Tracking either stories or tasks can be helpful to an Agile team. It can be useful in understanding the estimation process in a Retrospective. And it can help inform Sprint Planning.
But estimating at such a granular level can also be associated with a false sense of accuracy, and it veers away from collaborative ownership. The latter is probably a subject for another post, but the main issue with tracking a story’s tasks in a burn-up is that doing so can show false progress.
Be honest
If a team has committed to five stories with 10 tasks each, they have 50 “things” to do in one Sprint in order to meet their goal. So everyone starts picking off tasks, one by one, and as long as they finish all the tasks in the Sprint, they figure they’re golden.
Easy, right?
But then things come in from left field. A task takes twice as long to complete due to an unknown problem with an API. Or there was illness on the team. Or there were deployment issues. Or. Or. Or.
So two weeks pass, and now, at the end of the sprint, we find we have 40 tasks done.
Not bad going, team! Eighty percent of our sprint backlog is complete! Woohoo!
But we didn’t complete any of the stories . . . well, completely. As in 100 percent. The 40 tasks that were done actually equate to zero percent of the sprint backlog.
Wait. What?
Everything was tracking perfectly. We only had ten things left to do!
The real issue here is that the focus of the team was on completing tasks rather than completing stories. They were not swarming over a single item to get it through to the finish line.
And as my Dad used to say, three-eighths of nothing is nothing.
Be focused
A small tweak to focus the team on completing stories, and not just tasks, would have meant that four stories would now be ready to ship. You know, instead of zero.
There is a human toll to this too: Seeing amazing progress reported throughout the sprint, only to be told that none of it was useful or shippable, can be a blow to team morale — and to a Product Owner’s confidence in the team.
Back to the argument: watermelons
In the discussion I referred to at the beginning of this article, this task-oriented approach was termed “Watermelon Reporting.” Why? Because this kind of tracking (mis)leads a team to something that looks green-for-go on the outside, but is actually stop-right-there-red in the middle. You think — and report — that everything is going well, but actually, it’s not. And you can’t see just how red that watermelon is inside until you break it open. And then it’s too late to fix things; you can’t put it back together again.
Care for some grapes?
To stay with the fruit metaphor for a moment, I prefer to strive for something I think of as “Grape Reporting.” This method results in a focus on the delivery of small, bite-sized morsels. Yes, some green grapes will get over the line, while some red grapes may get left behind. But everything will be small enough to measure the real progress of done things throughout the sprint.
What does and does not get delivered won’t surprise the team, because they’ll be tracking the story completion right from the kick-off of the sprint.
An argument, resolved
So in our discussion, the real question ended up being
What is the value to the Agile team of burn-up charts?
This, of course, is down to each team; different approaches work differently for different people. But as coaches, our job is to help any given team identify how it can improve. If burn-up charts help a team visualise its work, and provide transparency and an opportunity to have conversations — then they can be really good things.
The key? Making sure you’re talking about the right type of fruit.