2 years ago, I published a blog post called why you shouldn't burndown tasks instead of storypoints. It started like this:
Even if it is really tempting: don't burn down tasks... ever!
A short summary: first we break down the work we do into user stories that each bring value to the product. Then we prioritize those to create the most important pieces first. The team working on the user story will then usually break it into tasks to clarify its intent, decouple what can be parallelized and visualize progress. Finally, whatever we do, user stories are to be seen as 1 or 0, meaning either "done" or "not done". If 1% of the tasks are "not done", the story is still "not done".
Today I want to raise the bar and show that if you didn't follow that advice back then, you are now in the rare position to create really cool burndown charts of a whole new kind: "asympotical everything's fine" charts.
The closely guarded recipe
In order to produce this chart you need to start counting remaining effort for everything you do. Instead of considering an item either "done" or "not done", estimate how much effort is left on your stories or task... everyday:
Item XYZ was estimated with 4 bananas, we're about half way through so 2 bananas remain
Immediate effect on the burndown chart
A burndown chart shows progress day after day. If you consider the items either "done" or "not done", some kind of "stairs effect" will appear. One day nothing happens and the line is horizontal. The next day an item is closed and the line goes down.
If you use a degree "done-ness" i.e. have 4 bananas on the first day and 2 remaining on the next, your chart will most likely look quite fine for a while. Everyday you are showing progress, no more "stairs" behavior. Great!
I can't even...
We are only humans and have a tendency to overestimate good and bad events. When asked for an estimate of remaining work, we will often be too optimistic. This will produces a gorgeous distortion of those estimates over time. We tend to underestimate projects so often that this sentence is more than well known in our industry:
"After the first 80% of a project comes the second 80%"
or its variation:
"The last 20% of the project will amount for 80% of the costs"
If you've followed those instructions carefully, you should end up with a chart that looks too good to be true at the beginning but slowly flattens out when it closes as time goes.
The effect is simple:
- Day 1, initial estimate: 4 Bananas
- Day 2, "everything's fine, I'm almost done": 1 Banana left
- Day 3, "something is not right but I'm very close": 1 Banana left
- Day 4, "I have to rewrork that small thing": 1 Banana
- Day 5, "ok, now I'm really almost done": 1 Banana
- Day 6, "finished": 0 Banana
When you have only 1 point left, you cannot subdivide it any longer and the effort remains, even if the work is not done. Thus the asymptote! Have you experienced that before?
Don't freak out, it's curable
There are two scenarios where I have seen this commonly used: with stories and with tasks.
First, start by introducing a line on your chart that only goes down when an item is "done". This will most likely produce a "stairs pattern", but that's OK.
Then, gradually reduce the size of the items you are working on so that they are, in average, closed in a day. That way the need for splitting the estimates will become a lot less interesting.
This is what I described in the article why you shouldn't burndown tasks instead of storypoints:
If you cut stories small enough to be able to commit to ~10 stories for a 10 day sprint, you are golden.
Finally, put the focus on the one and only curve that matters: story points. And as soon as you can, get rid of the other ones.
The special ingredient
Once you reached this point, you can ask yourself the following questions:
- How can I consistenly produce items of roughly the same size?
- What happens when I then ignore the estimates and take the number of items instead?
- Can I then completely skip the estimates (for this purpose - #NoEstimates inside)?
Image Source: Asymptotical by Jed Sullivan (CC BY-NC 2.0)