Thursday, August 14, 2008

Planning Poker... A Better Way to Estimate as a Group

I've mentioned in some previous post that I would explain the basics behind planning poker and how it could be used to make your team sprint planning session more fun and more accurate. This is a technique normally used for estimating the relative complexity of the items in a product backlog but it can also be applied to estimate the time for tasks in a sprint backlog. So, here it is.

Planning poker is based on the collective intelligence principal were it is said that the collective knowledge of a group will outweigh that of any one individual in that group. A detailed breakdown of this can be found in a book called the Wisdom of Crowds by James Surowiecki but I will try to sum up this idea as best as I can and explain how it applies to collective estimation.

A scrum team is generally formed of individuals having different expertise. Some people are good at testing; others at designing systems and writing code and some have knowledge relating to user interfaces. As a scrum team, each member should know enough about each feature (or user story) to implement them. This is what makes the scrum team work well as a group. Pooling this collective knowledge of the features, each member is able to estimate to the best of his knowledge and expertise the amount of time a feature can take. It is by combining these estimates that a consensus can amount to a very accurate estimation.

What planning poker brings to the table is a fun and an enticing way to get this collective knowledge out of each team member.

How to Play
  1. You will need a deck of planning poker cards (index cards or Post-Its can be used as substitutes)
  2. Each members of the team get a hand of cards
  3. Each hand is composed, for example, of cards with the following values ?, 0, 1/2, 1, 2, 3, 4, 5, 8, 13, 20, 50, 100
  4. Each number represents a unit of time such as real hours, man-hours, half-days, etc... You should define this for your group
  5. When estimating for a feature, each member picks a card and places it face down on the table
  6. When everyone picked a card, the cards are turned
  7. If the estimates vary a lot, the team discusses the reason why higher/lower values were drawn within a preset time limit and the hand is replayed
  8. This is repeated until the team converges to a similar estimate

The values of the cards can vary from deck to deck but the important aspect of the series to observe is that it is non-linear. The reason for this is that bigger features are harder to estimate so; the bigger numbers represent ruff estimates. The extreme values are explained here:
  • ? should not happen often but when it does, it is an indicator that the information about the feature is not know well enough by the person to estimate. This means that further explanations to the team might be required
  • 0 means that the feature is already done
  • 50-100 might be an indicator that a feature is too big and that in order to obtain a more accurate estimate, it should be broken down
When the estimation round is played it is essential that each team member finish picking his card before all the cards are revealed. This is to eliminate the estimation by a single subject matter expert that can potentially influence the estimate of others.

I hope I have made myself clear enough for you to better understand the usefulness of planning poker and if you are still confused, I suggest you look it up on Google for there are many explanations and perhaps variations of this out there.

Still not convinced? I suggest you try it at least once.


Steffen said...

Sounds nice, I hope the next project offers a chance to try this out :)

J said...

Actually, this kind of estimation technique can be applied right away. We actually started using this in our current scrum and I'll have some metrics to present on the overall accuracy we've attained in about 2 weeks.