One of the recommended practices when doing agile software development is to get estimates from each of the individuals in the team without having them influence each others thinking.  That way you get multiple points of view on an item and avoid the issues of having one person estimate on behalf of everyone else in the team.  You also foster greater communication amongst those estimating and greater collective ownership of the estimates themselves.

Another recommendation is to use relative estimating and banding/bucketing of estimates.  Relative estimation is just a matter of estimating the size of one job compared to another.  Doing so makes it easy to understand the relative difference between an estimate of 1 and 2 but the relative difference between a 28 and 29? Who cares – it’s so small it doesn’t really matter.  For that reason the use of banding is encouraged to avoid wasting time trying to get the perfect estimate.  An estimate is what it is – an estimate.

Enter Planning Poker.  Planning Poker is a very simple process that helps teams estimate using the above recommendations and works as follows:

  1. Everyone on the team is given a deck of cards.  Cards contain valid estimate numbers, typically something like 0,1,2,3,5,8,13,21,40,100,200 & ?. (The “?” is when you are unable to estimate)
  2. As each item comes up for estimation the team asks enough questions to get a reasonable idea of what’s involved so they can each make a valid estimate.
  3. Each individual selects from their deck a card that matches their size estimate and either puts it face down on the table or holds it up against their chest or forehead (face hidden) to indicate that they have made an estimate.
  4. When everyone is ready all team members show their estimates at the same time.
  5. If the estimates are within one banding of each other the high number is chosen as the estimate.  i.e. if everyone selected a 5 or an 8, then the estimate is 8.
  6. If the estimates differ markedly then the people who made the lowest and highest estimates defend their reasoning.  Once that reasoning is understood, the process repeats from step 3, until a consensus is reached.

All pretty simple, right?  Well it is, until you try to do it in practice.  I’ve found that a lot of teams find the idea of playing with cards during work hours just a little too geeky and it makes the adoption of the planning poker process a little harder than it should be.  Oh yeah, and you also need to make sure you have a deck of cards for everyone in the team.

To make adoption a little easier I use a “rock, paper, scissors” style of planning poker. I make sure the team know the valid numbers they can choose from for estimating and then do all the same steps as for normal planning poker, but instead of holding up a card to indicate they are ready, they just hold two fists out  (or put them on the table) to indicate they have an idea in mind.

Once everyone is ready it’s then just a case of saying “1, 2, 3, go” to get everyone showing their estimates at the same time.  The number of fingers held up indicates the estimate.  For numbers above ten, e.g. 21, people would show two fingers on the right hand and one on the left.  Simple enough.

The advantages? It feels less geeky than using cards, you don’t have to ensure everyone has a deck of cards to start with, and you don’t have to watch people fumble around getting the card they need to choose for the estimate.