Task Sizing in Agile Software Development

We are commonly asked how big our tasks should be. That should be a pretty simple question to answer. How big is too big for a couch to fit into my house? Simple — how large are your doors and does the couch come apart? Determining how big our tasks should be is a little bit more complicated than that, though.

task sizing agile software developmentHow big is too big for a task on an Agile development team? How small is too small? How would Goldilocks pick a story that is “just the right size”? In a lot of ways, the answer is do what works best for the team. With that said, what we’ve seen work very well across many different teams in many different industries is: Keep your task size to one day or less. Breaking tasks down to one day or less exposes enough detail to define the boundaries, but not too much design to constrain ideas and take a lot of time to plan. It also seems to help mitigate estimation error as well. There are some costs and risks involved with breaking tasks down this small though.

People are notoriously bad at estimating the time and effort that any task will take because a significant part of the estimation process involves intuition. Domain/subject matter experts and experienced senior people can provide slightly more accurate estimates, but they are not significantly better than those of less senior technical people.

In some ways it’s as much human nature to want to know exactly how long it will take to do something as it is to not be able to answer that question accurately. We’re bad at it but we need to do it, so how do we work with it? By balancing the duration of the time estimate with the amount of time it takes to define the work. The greater the time, the more likely our time forecast will be off. And the more time it takes to define the work and the greater detail we design, the less efficient and adaptable we are when we implement the work.

This is why breaking tasks down to one day or less works well. Doing this lowers exposure and lessens the risk of bad intuitive guesses. Limiting task size to one day or less lowers the amount of time affected by our innate inability to accurately predict work and effort, while increasing possible feedback cycles and visibility. The discussion and knowledge required to break tasks down to one day is enough to expose problems that would cause the task to take longer than a day. When a task is mis-estimated and goes longer than a day, it generally spans multiple stand-ups and becomes visible to the team. This feedback gives the team an opportunity to reflect, adapt ,and offer help. The amount of time that the task breakdown discussions take, although initially longer, tends to quickly be acceptable to developers.

There are some caveats to breaking down tasks to small sizes, though. When breaking down tasks to one day or less, it often takes conscious thought to not design and get distracted and go “into the weeds” while tasking. There will be many “small” tasks to track and maintain. This is a necessary evil, though, and while this can be a bit tedious it does increase visibility/accuracy and shortens the feedback loop. Initially, breaking tasks down to one-day chunks will take a little extra planning time, but as the team becomes more practiced in this skill it will become second nature and not take longer.

Creative Commons License
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 United States License.