Why not burndown tasks instead of storypoints?

TD;DR; event if it is really tempting: don't burn down tasks... ever!

After a while wondering what was wrong, I finally managed to put words on a problem I've seen in more than one agile transition projects: bloated stories and task burndowns.

Panic Burndown

Writing good stories is hard. Writing really good stories is really hard. In order to produce more business value, the tendency is to write bigger stories. One thing leading to another, you end up with big stories that fit a big chunk of a sprint (it will go up to one story per sprint). In this context, at the end of the sprint, your burndown will look like this:

Little to no progress 80% of the sprint and a "big" magical drop toward the end of the sprint. What can we learn from this burndown during the sprint? Nothing... beside panicking.

On this graph, the sprint ended well with all the content delivered, but often enough, a sprint which has such a burndown will not end well.

Tasks

If you have such burndowns, I am willing to bet that you have a lot of tasks too (each story must be cut down to pieces by the devs into millions of tasks). One easy solution for our burndown is then to burn those tasks instead of story points. The tasks flow is more constant and the burndown thus looks like more or less steadily going down.

The problem is, this will work quite well, until it does not.

Tasks do not directly represent real business value. Pushed to the extreme we could imagine a scenario where you solved all your tasks but one in the sprint - your burndown looking almost perfect - yet you will deliver zero Business Value at the end of the sprint because the story is not done.

Story Size

Let's flip the problem up side down (and this is the part I almost never saw written anywhere yet).

Let's say you have a 10 Days sprint. If you want to see progress everyday on your story point burndown, you need to close (at least) one story per day, meaning that you should have about 10 stories in your sprint. Then and only then, will your burndown look like the green one below.

If you have fewer stories in your sprint, your burndowns will look more like the orange one, or event the red one.

What it means to us?

As a team member, it basically means that you have to pay attention to the size of the stories and help your product owner(s) cut down their stories in more chew-able chunks.

If you follow the scrum practices, you must be using story points to estimate the stories you will tackle. And if you do, you also probably use the Fibonacci-like sequence of numbers (0, 1, 2, 3, 5, 8, 13, 20, 40, 100). What do your teams deliver in a sprint? 10? 15? 30 Story Points? Divide this number by the number of days in your sprint and you have the median size your stories should have... last time I checked, we were faaaaar away from that.

#NoEstimates

You might have seen this hashtag on twitter lately as Vasco Duarte started questioning the relevance of estimates in a world where 75% of them are consistently wrong (the original title of the discussion was "Estimation Waste").

Leaving the discussion and the title (that I find utterly misguiding and thus a great marketing and communication mean in itself :P ) aside, getting your stories smaller and smaller until they are consistently of a similar size is basically the essence of the #NoEstimates movement. If your stories are of a similar size, you do not need to estimate them anymore, you just need to count them to have your velocity. That is a promise that many an agilist would like to see one day don't you think?

What are your burndown like? Do you prefer a burnup to better visualize the rescopes? What do your estimates look like and how do you help your Product Owners to achieve such a goal?

Nota: I avoided talking about "Swarming" - e.g. how well we focus on closing a story before starting with the next one - in this article. It sure also has an impact on the burndown since the lack of swarming produces late-closing stories too... e.g. what we saw in the red burndown.