Planning Poker

  • Article

At the Agile 2005 conference, I attended a session given by Mike Cohn on Release and Iteration Planning (see blog post ).  In Mike’s session, he introduced ‘Planning Poker’ as a fast track approach for using Wideband Delphi for doing high level estimates.  

We are just completing the high level planning phase for a three month milestone and I had the opportunity to try out Planning Poker for estimation on three different teams.  The estimation team size varied from 5 to 15.  Using Mike’s process was an incremental change from what we had been doing, but I found it expedited the process and made it more fun.  The experiment was a success and I plan to keep on playing Planning Poker!

In the session, Mike handed out a deck of cards.  A deck has 4 sets of cards, with each set containing the following cards: ?, 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.   At the estimation meeting, each estimator is given one set of the cards.  We then proceeded with estimation as follows:

  • The most knowledgeable engineer for a given feature provided a short overview.  The team was given an opportunity to ask questions to clarify assumptions and risks.
  • For each feature deliverable (doc, code, test, etc), we played planning poker:
    • Each individual laid down a card (face down) representing their estimate in days of effort.
    • Everyone showed their cards simultaneously.
    • People with high estimates and low estimates discussed their justification for their estimate.
    • We repeated the estimation process until a consensus is reached.  The engineer who was likely to own the deliverable has a large portion of the "consensus vote".

We had been using a lightweight approach to Wideband Delphi for some time, so this was a pretty familiar process.  The main changes to the old process were the use of the deck of cards and estimating in days instead of hours.  Both were an improvement in the process.  The cards facilitate the process.  As moderator, you know when people are ready to estimate and people are less likely to change their estimate after hearing someone else’s estimate.  Estimating in days, particularly in increments that are spaced much further apart as the numbers get larger, allowed us to estimate more quickly at an appropriate level of precision.  

We differed in the approach that Mike taught in two key ways.  First of all, he recommended that you estimate User Stories instead of Feature Deliverables.  We are not using User Stories at this point, although I’m interested in seeing how to apply them to help break down our features.  Second, he recommended that you estimate Story Points instead of days of effort.   I also am very interested in experimenting with the use of points as a size measurement, but we’re starting with days initially to help calibrate our points.  We’ll see if and when we take that next step as this is a more controversial topic on our overall team.

The estimation session is just one step of our milestone planning process.  I will go into more detail on the overall process in an upcoming post.