Are you using Planning Poker for estimating tasks? Maybe you should reconsider it

If you are using Planning Poker for estimating tasks in the Sprint Backlog, maybe you’d better reconsider it. It’s a tool that can be very useful when estimating user stories or Product Backlog items. But the characteristics of the tasks in the Sprint Backlog are very different from those of the Product Backlog items, and most times Planning Poker, or any other estimation tool based in orders of magnitude, is not adequate for supporting those estimations.

The main reasons of Planning Poker not being a good tool for estimating tasks are:

• Task estimates are usually given in hours, and because of the very nature of the tasks, they should be in the range of a few hours, from less than one hour to a maximum of 16 hours. That is, tasks estimates not necessarily grow by orders of magnitude, as user stories estimates tend to do, but instead of that, they stand within a small magnitude. Planning Poker only provides a few cards for the range of small estimates, and we also have cards to provide large estimations, which shouldn’t even occur if the tasks had been decomposed properly.
• As a result of this, when working with Planning Poker we’ll miss some values ​​that are not present (on purpose) in a Planning Poker deck, since for estimating tasks we need a ​​more accurate range of values than for estimating user stories. For example we will not be able to give an estimate of 4 or 6 hours for a task, which a priori should be perfectly possible. I’ve even found teams that were taking more than one card at a time to reach the desired amount for the estimate, which demonstrates the limited usefulness of the tool for this purpose.

Therefore, it would be appropriate to leave Planning Poker, and other methods based on orders of magnitude as T-Shirt Sizing, to estimate user stories. To estimate tasks, we can simply use Wideband Delphi, or even simpler tools such as analogy, decomposition or expert opinion.

Apart from this, it might even be questionable whether it is better to estimate tasks in groups or individually. Ken Schwaber himself recommends the latter (http://kenschwaber.wordpress.com/2010/10/, Example 2), although this would be a good subject for another discussion.

And finally, remember that sometimes it’s even better to not estimate the tasks. Estimates are not value that we can deliver to the customer, but rather they can represent waste, and if we can properly do planning without doing the effort of estimating, we will earn this time to advance in the delivery of value. Some teams simply break down the work into tasks of a similar size, so that planning can be based on counting the tasks that we’re going to be able to finish.

I’m leaving you with the slides from my session on agile estimation at the last TechEd Middle East, it’s mainly about estimation for user stories, but the concepts can be useful in a wider sense.