Agile task breakdown and estimating can be a difficult conversation to have with teams. I had a conversation with one of our teams several days ago and we were discussing decomposing stories into tasks and estimating them. In particular, what kinds of guidelines and guardrails should we use for task estimation?

Agile Task Breakdowns

I’ve been breaking stories into tasks since I started doing agile as a developer. When we started, we had some strict guidelines on our tasks – more than a couple of hours but no more than eight. There is evidence that shows that estimation accuracy drops off significantly beyond one day’s work. We, as humans, are pretty good at estimating the amount of work we can complete in a single day but our accuracy drops off dramatically the more days are required. In traditional project management, this results in a rule that requires we “double engineer estimates”. To counteract this, we want to estimate our work as accurately as possible (and definitely as precisely as possible). Accuracy measures how close to the actual time our estimate is, but precision measures how consistent our estimates with one other.

Where the Rubber Meets the Road

Task estimates can really help us make sure that the team isn’t overcommitting during the sprint. Story points give us some level of the general size of things. Our sprint capacity (also called “planned velocity”) tells us how big our bucket of work is for the sprint. The stories need to fit inside the bucket, but that’s very high-level estimate. Our tasks can give us a lot more detail about whether we over-estimated or under-estimated the size of the stories.

Breaking down stories into “right-sized” tasks also has several benefits:

• The right level of granularity. When we break a story into tasks, it helps ensure that the team is asking the right questions of the Product Owner to understand what’s needed to deliver on it. It’s critical that the team have a good starting point for their work.
• Covering all the bases. A good practice is to do this exercise as a team. With a good cross-functional team, they should work together to identify all the steps needed to complete the story. It should cover all development, testing, and validation work needed.
• Incremental progress. By completing stories in small steps, the team can show progress toward their sprint goals.
• Burn-down charts. Using hours to track our burn-down charts (as opposed to story points) can provide more detail on our sprint progress.

What I coach is to keep our estimates small (less than a day) but not too small (they should be more than a couple of hours). I typically coach teams to track any work that takes more than a couple of hours. We want our sprint backlog to reflect reality – the work we’re actually doing. But we don’t want to track the random administrivia that happens. That’s one of the reasons many coaches require the team to estimate only up to 80% of the total hours in a sprint.

Arguments Against

There are some good arguments against doing task estimation. For some high-performing teams, it can be worthwhile to avoid the exercise, especially if the team has demonstrated good accuracy in the past. And for teams that are doing Scrumban or some other pull-model process, the goal is to move toward similarly-sized stories to help facilitate flow.

Some teams may argue that it’s a waste of time. For those teams, I often find the reason rooted in a desire to focus on working. They think that they’d be more productive if they can just “get to work”. There’s a tendency to believe that just jumping in and doing work is the best way to move forward. Without guidance, the team can splinter off, disrupting the harmonic.

What’s often forgotten is that agile tends to do as much as – if not more than – traditional processes. We, as coaches, need to push back against these tendencies.

Closing Thoughts

Task estimation is a great tool for agile coaches to help their teams deliver on their commitments. When done properly, breaking stories down appropriately can make certain the team has the focus their efforts. When a team has continuing success delivering on their sprint commitments, the team should move down the path toward becoming a high-performing team.