Planning Poker (Time Estimations)

Time estimating using planning poker

Estimating is a team activity - every team member is usually involved in estimating every story. Why?
  • As per Agile at the time of planning, we normally don’t know exactly who will be implementing which parts of which stories. Stories normally involve several people and different types of expertise (user interface design, coding, testing, etc).
  • In order to provide an estimate, a team member needs some kind of understanding of what the story is about. By asking everybody to estimate each item, we make sure that each team member understands what each item is about. This increases the likelihood that team members will help each other out during the sprint. This also increases the likelihood that important questions about the story come up early.
  • When asking everybody to estimate a story we often discover discrepancies where two different team members have wildly different estimates for the same story. That kind of stuff is better to discover and discuss earlier than later.

If you ask the team to provide an estimate, normally the person who understands the story best will be the first one to blurt one out. Unfortunately, this will strongly affect everybody else’s estimates.

There is an excellent technique to avoid this – it is called planning poker (coined by Mike Cohn I think).

Each team member gets a deck of 13 cards as shown above. Whenever a story is to be estimated, each team member selects a card that represents his time estimate (in story points) and places it face-down on the table. When all team members are done the cards on the table are revealed simultaneously. That way each team member is forced to think for himself rather than lean on somebody else’s estimate.

If there is a large discrepancy between two estimates, the team discusses the differences and tries to build a common picture of what work is involved in the story. They might do some kind of task breakdown. Afterwards, the team estimates again. This loop is repeated until the time estimates converge, i.e. all estimates are approximately the same for that story.

It is important to remind team members that they are to estimate the total amount of work involved in the story. Not just “their” part of the work.The tester should not just estimate the amount of testing work.

Note that the number sequence is non-linear. For example there is nothing between 40 and 100. Why?

This is to avoid a false sense of accuracy for large time estimates. If a story is estimated at approximately 20 story points, it is not relevant to discuss whether it should be 20 or 18 or 21. All we know is that it is a large story and that it is hard to estimate. So 20 is our ballpark guess.Want more detailed estimates? Split the story into smaller stories and estimate the smaller stories instead!

And NO, you can’t cheat by combining a 5 and a 2 to make a 7. You have to choose either 5 or 8, there is no 7.

Some special cards to note:

0 = “this story is already done” or “this story is pretty much nothing, just a few minutes of work”.

? = “I have absolutely no idea at all. None.”

å = “I’m too tired to think. Let’s take a short break.”


kousalya said...

Excellent sharing Thanks for share i am sure its must help me. thanks for doing this.

Scrum Process

Paul Eisenhower said...

Excellent comments with interesting topics and very useful resources. Thanks for sharing. pokerrulesguru