Planning Poker for Agile estimation – Thou shalt not be inscrutable!

You don’t need a poker face to win this one. In fact, you need just the opposite. But hold on, let us start this properly.

Software estimation can be your worst nightmare, and no matter how many fancy statistical models you use, you may still end up not being totally accurate. Agile offers a unique method for estimating your user stories – planning poker. Yes, it uses cards, and yes, it is sort of a gamble like the game, and yes, it is FUN. And yet, you end up with pretty good estimates for your user stories, and hence your sprint or iteration. And you get to play this every other week, or every month, depending on your sprint length.

Wikipedia provides some good background on planning poker here. So does Mountain Goat software and http://www.planningpoker.com/. There is an oldish post  here which has several good comments that offer differing points of view and experiences. Ken Schwaber also wrote of this recently.

Ok, so now that we have enough links and sources to read around this, I would like to paraphrase the game simply. Planning poker is ‘played’ by the Scrum team or the developers to come up with grounded estimates for each story. Actual cards are/can be used. These cards have numbers such as 1, 2, 3, 5, 8, 13, 20, 40, 100, ∞, ? etc. printed on them. This is how the process goes -

• A moderator is appointed by the group. The moderator reads out the story, the product owner elaborates a bit and then everyone thinks about it for a minute or two. A sand clock or kitchen timer may be used.
• At the call of ‘Show’, everyone turns their selected card up. It is important that everyone be quiet until this moment to avoid creating a bias.
• The person with the highest and lowest card explains why they came up with that particular number. This is not to convince anyone; they justify their choice and that’s all.
• The process is repeated where the group thinks for the minute or two and selects a card again. Everyone ‘shows’ and the high and low estimator again explains their choice.
• The card selection process is repeated until the team reaches consensus on a number and that is allotted as the effort estimate for that particular story.

The higher numbers on the cards are more widely spaced to denote the uncertainty that follows large estimates/tasks. These numbers resemble a modified Fibonacci sequence. Distributed teams can use an online tool that is available at http://www.planningpoker.com/.

Planning Poker works because it takes estimates from the actual performers themselves, and encourages dialogue and hence forces people in diverse roles to think about dependencies. There is also some literature on how averaging individual estimates gives better  results. Also, you have actual performers from different functional areas coming up with their numbers as opposed to one higher-up manager( however experienced) assigning a number for the whole project.

What method do you use to estimate your projects - agile or otherwise? Have you tried planning poker yet? Do you think estimating at the story or requirement level by actual performers will give a more grounded estimate?