Estimation Using Planning Poker in Scrum

To do estimates we use planning poker. The concept is really simple. Here I’ll tell you how.

The cards

Everyone gets their stack of cards, from which one picks one card per round of estimating a task. The numbers represent hours, “?” means just what you think (“I have no clue”) and infinity means it’s larger than 21 — which is the upper limit for what the estimate can be.

The procedure

Poker face discussion
Once tasks has been broken into presumably manageable pieces during the second segment of Sprint Planning,The Team members puts on their poker faces and starts discussing the fabric and nature for each task, one task at a time. Anything that can enlighten how much work the task will require is useful.

Choose your card
Then everybody has to make up their mind and pull a card from their deck. Count to three and everybody turns their selected card.

Deciding on the estimate immediately
Ideally everybody agrees, and the estimate is set. Done. We can move on to the next task.

If we have only 5’s and 8’s, the majority wins (the are no cards in-between these two estimates) and we are settled immediately as well.

Resolving differences of opinion
What often happens, however is something like this. Stefan’s card shows 5 hours, Håkon’s card shows 8 hours and Geir’s card shows 13 hours. Now Stefan (with his 5) and Geir (with his 13) will have to discuss. Why so few hours, Stefan? And why so many hours, Geir?

Then, we play cards once more. Repeat this until agreement is reached or a fist-fight breaks out. Normally there is not fist-fight and the second draw results in an agreement.

4 reasons why estimating is good for your project

For estimation, planning poker is by far the best mechanism we’ve used for estimation to date, and the accumulated estimates usually turns out quite realistic.

  1. You’ll achieve sprint goals. History shows that we’re spending from one-third to twice the estimated time for each task(!) That does not sound all that great, but remember that these are the extremes. The most important, however, is that for the sum of tasks the estimates are usually quite accurate, which means that the sprint will be finished on-time, which is the goal of this procedure.
  2. Discuss only the important. The mechanism for picking the right two people to discuss (the one with the low, and the one with the high estimate, if more than marginally different) leads to both efficient and effective resolution of the differences of opinion and understanding of a task.
  3. Improves the specifications. Estimation reveals lacking task-specifications. When people are way off to either side in their estimates, the triggered discussion will resolve the weaknesses in the specification that caused different estimates, and the specification must be detailed accordingly.
  4. The estimate tells you something about the task. Estimation adds another level of description to a task in and of itself. If a task “Create customer list for product X” is estimated at 1 hour, you know it’s not about developing a fancy application for it. Whipping up a text-file or installing a wiki might be the solution you’re looking for. Estimation is time-boxing and constraining the solution. Constraints yields creative and effective solutions.

Please let us know in comments if you have experiences using planning poker or if you use other techniques to accomplish the same results.

(Want to play poker with us in Gothenburg?)