Are you an estimating guru? Have you never missed an estimate in your life? Can you even do estimates for others? Then this is not for you. However, if you don’t recognize yourself in the previous description this still might be something for you.
When I introduced Scrum to my organization, we quickly started to use planning poker. So what’s planning poker? Here’s what planningpoker.com says:

"Individual stories are presented for estimation. After a period of discussion, each participant chooses from his own deck the numbered card that represents his estimate of how much work is involved in the story under discussion. All estimates are kept private until each participant has chosen a card. At that time, all estimates are revealed and discussion can begin again."

How we use planning poker in Contiki

At Contiki we use planning poker to estimate all our user stories, or features if you want. When the backlog starts filling up with un-estimated backlog items, we gather the team for a round of poker. We also have a team in Ukraine, so using planningpoker.com works great for us. Here’s what we do step by step:

1. The product owner reads the user story and adds any additional information he think is necessary. No comments or input is allowed from the others at this time (our experience is that starting the table discussion before the first estimate takes a lot longer and will not make the estimate any better).
2. Everyone vote for an estimate.
3. When all estimates are in, all estimates are revealed. When we see that the estimates vary (which usually is the case), we ask the person with the lowest and the person with the highest estimate to discuss why they differ. This usually results in highlighting the different perceptions of the user story and helps clarify other aspect previously unknown to the story. The person with the lowest estimate might know something that will make implementation easier or the person with the highest estimate might know some other implications that the other person didn't.
   
4. At this time other people might jump in to add extra knowledge to the story if they think this will help.
5. After a short discussion a new voting is started, if not the estimates are very close to each other that is.
6. If the estimates are still not the same, pick an average.
7. In rare cases we allow a third vote if the team agrees.
   

Using a team to do the estimates has several advantages:

• If one person is doing the estimate, it’s not definite that he’s the person to implementing the functionality, making his estimate less valid. I’ve never understood people doing estimate for others.
  
• If only one person does the estimate, he estimate is based on his background and his knowledge.
• Having several people with different experience, knowledge and perception to agree on an estimate, usually results in a better result. It will usually help people visualize aspects of a functionality that was previously unknown the one person.
• It’s more fun!
  

Later I'm thinking of talking about:

• The anchoring effect
• Story points vs. days
• Why does planning poker work?