Why tasking matters

Something I perhaps neglected in my talk about breaking down user stories into tasks is why you'd want to do that. Let me illustrate by analogy. When you're hiking, there's a question you're continually asking: "where am I in relation to where I should be?"

The more often you can answer that question, and the more accurately, the sooner you know if things are going wrong, and the easier it is to recover from your mistakes. Five minutes tromping in completely the wrong direction is trivial to correct; five hours is not.

How do you answer those questions more frequently? Better tools which enable more granular reporting. A small scale map can tell you that you're on the correct side of the valley, or that you should have reached a town by now, but it won't tell you which side of a cairn of stones you should have passed. There's not enough resolution to make it worth checking more than once an hour. By contrast, a large scale map has representations of all the small bridges, hillocks and burial mounds nearby that allow you to narrow your position down to a small area. You can check it every few minutes and get meaningful information.

Of course you don't want to spend so much time getting bearings that you fail to walk anywhere. That's where the other side of tooling comes in; helping you orient quickly. Sight checking is slow. Using a compass and a pace estimate to do dead reckoning speeds things up a bit. GPS is instant.

Staying on the path

In your sprint, the stories and relative-sized estimates thereof are your small scale map. You know that you're vaguely on track, because you're halfway through the sprint and you've closed off half your stories. But you can only really stop and get your bearings when you finish a story. It's easy to end up way off track by getting blocked on one or two trivial things; your sprint could look a disaster just because a couple of stories need business owner sign-off and they're on holiday until the last couple of days.

If you have estimated tasks, then you've got a large scale map. You can stop and get your bearings every time you log some work - as long as you keep your estimate of "how long is left?" accurate, the resolution of your map is practically infinite. You always know how far off track you are.

Here are some examples, to illustrate further:

When things are going well, all you get is extra resolution. But in the second example, where the team get blocked or start waterfalling (e.g. doing all their testing at the end of the sprint) you can see that overall progress isn't quite as bad as the coarse-resolution story point chart makes out.

The third example is the most interesting, and the one I've seen well-estimated tasks help most with. If you look at the story point chart, things look mostly okay until the last couple of days of the sprint. But the hourly chart pinpoints the instant things went awry. A scrum master using the right-hand chart could take action half a sprint earlier than one using the left-hand chart!

Getting a grid reference

When I'm not sketching examples on a notepad, I tend to get the computer to generate the graphs for me. JIRA has a fairly robust time tracking feature, and there are plugins for other common solutions like Trello. It takes a little bit of discipline for developers to keep remaining estimates up to date (I've not yet seen a team who didn't need to be kicked into action by their scrum master every once in a while) but once you put that effort in it's like having a GPS - getting your position is instant.

Cartography

I mentioned above that developers need to log "remaining estimates" rather than "hours" above, and that was deliberate. The real aim of navigating in the outdoors is so you don't end up stranded miles from civilisation as night draws in. It doesn't matter how far you've walked; it's how far you've got left to go.

The same applies to tasks. It doesn't matter if a quick task turned into hours of headbanging; the important part is whether that headbanging was the end of it, or if there are still hours left to go. It's normal to see tasks get added and the number of hours actually go up when a team discovers something unexpected that needs to be done. Like detouring around a landslip, you can't ignore the extra distance you need to go.

On the other hand, when things are quicker than expected you get to claim the full estimate. Discovered a way to implement a gnarly task with a one-line code change? You can claim the full four or five hours of estimated time, because the important thing is that you don't have to do it any more. Like finding you can jump over a stream you expected to have to detour around - those extra miles just disappeared from your trip effort-free.

In conclusion

Your burn-down charts are the maps by which you navigate your sprint progress, and understand whether you're on track, ahead of schedule, or lost in the wilderness. Tasking gives you a much more accurate map, and gives you the feedback that much quicker; and being able to quickly orient and act on feedback is what agility is all about.