It’s important that we keep close track of our PBIs and bugs, and that we have estimated the effort on each. It’s also important – especially when the Development Team is swarming around work – that items have been broken down into easily digested tasks. Is it important that we estimate those tasks, though?

My definitive answer here is maybe.

Tasks tend to not be tracked using Story Points, but in hours, which is less than optimal. Having hours on tasks and tracking remaining work does help to feed your burndown chart, if such a thing is important to you. If the digital tool you are using requires hours and you need a chart, then you might find great importance in having all of the tasks associated with a given Backlog Item estimated.

I would, however, argue against doing so. Tasks are small parts of a larger PBI and do not actually deliver value on their own. If the task delivers value, shouldn’t it have been broken out into a separate PBI? If we have half the tasks done on a PBI, we are not done. No value has been created or delivered, and there is still work to do before the team can realize the points associated with that Backlog Item. It should go without saying that we don’t assign credit for undone work, so we don’t burn down some random portion of the story points assigned based on being partway to done. Estimating tasks is a level of granularity that is not needed to get our work to Done.

The added level of detail that is gained from estimating down to the task level is minimal, and the accuracy actually decreases as you get more and more granular. The sweet spot is to find where you have just the right about of detail, and that spot is invariably at the Product Backlog Item level. Estimating in tasks – particularly if those estimates are in hours – make our estimates increasingly meaningless. The other bad part of estimating in hours is that it becomes far too easy for someone to simply add up the hours and say “well, clearly if is a three point story and it should take 18 hours, I can now extrapolate that every story point is 6 hours and I know exactly how long all the work will take!” Don’t fall into this trap, as only bad things can happen here.

Again, I can see where it might be needed. I’ve worked with tools that only generated a burn-down chart based on tasks, which had to be estimated in hours, regardless of how the parent Product Backlog Item was being estimated. I’ve also seen where throwing out those estimates and focusing on getting the PBI to Done was the only thing that mattered. Tasks are useful for splitting the work, particularly when multiple developers are swarming around a single PBI. Spending time guessing at how much time each task will take is largely time wasted. Split the story if the task is delivering value on its own, or focus on the entire PBI, and you will have exactly the right amount of detail in your estimates.