Planning Poker

As a way of introducing a game, I’ve started to implement planning poker to estimate a Product Backlog, aka feature list, for two of my project teams. The experiments have gone fairly well so far. Basically everyone reviews the list of user stories, use cases, features, or tasks hopefully be then the poker rounds start:

  1. You hand out a stack of cards with numbers on them 1,3,5,8,11,13.
  2. You explain that the numbers are ‘story points’ and simply represent the relative complexity of a task.
    • A ‘1’ might be creating an error message popup.
    • A ‘5’ might be implementing validation of a HTML form.
    • A ’13’ might be implementing some complex set of business rules in a rules engine that no one is familiar with.
  3. Then you start with the first item.
  4. Everyone selects the card they thing corresponds to the estimate for that item.
  5. On the count of 3 everyone reveals.
  6. If everyone is the same you’re done.
  7. If there are differences people speak up about why they thought it was a 3 versus a 5 until everyone’s had a chance to comment.
  8. Then you repeat the process. At this point generally estimates start to converge. If need be run a round or two more.
  9. Continue until you run out of items.

The developers I’ve sprung this on so far seem to enjoy it at least for the novelty period. The group today was a bit disappointed though that it didn’t involve real money and poker chips. You then use the estimated story points to plan your iterations based on what the team thinks they can do. I’m experimenting with this still, but the general idea comes from Mike Cohn one of the heavyweights in the Scrum arena.