Planning Poker is an estimating technique used by many agile software development teams. Like many agile development techniques, Planning Poker is very simple. Simple, but effective.
First of all, agile teams should ideally estimate together. As a team. If the team is big, and people are working on different products, it’s okay to split the team into smaller groups. But estimates should still be done in groups.
The logic behind this is simple. Each person in the team has different experience. When you get the input of multiple people, you multiply the experience applied to the problem.
The benefit of doing this is based on the wisdom of crowds. You get the benefit of the team’s collective intelligence. 
In addition, you are likely to generate more ideas. Ideas about different ways of solving the problem. Ideas about how to design the solution. And ideas about obstacles that might be encountered.
All this leads to better estimating. And perhaps more importantly, better solutions.
Here’s how it works…
First of all, agree an estimating approach. For instance, many agile teams estimate in points, perhaps using the Fibonacci numbering sequence. Others use T-shirt sizes or some other abstract numbering system. Estimating in an abstract form has several benefits. The key thing is to estimate each item’s relative size, compared to other items.
Then, prepare cards with the numbers on. You can buy Fibonacci Planning Poker cards, or make your own. Alternatively you can just ask people to write the numbers you’ll be using on post-it notes.
The actual process of Planning Poker is then to discuss each feature in turn, clarifying requirements and asking questions that help to understand how it might be designed. When questions about a feature have run out, or are no longer materially important to the size, each member of the team indicates they are ready to give their estimate.
Then, on the count of three, the whole team reveals their estimate by showing the appropriate card, all at the same time.
As I mentioned earlier, each member of the team has different experience. So it’s very unlikely that everyone will come up with the same answer. Maybe someone saw issues and risks that others did not. Maybe someone else thought of an easier solution. The team uses this difference of opinion as the basis for discussion, sharing ideas and concerns.
Following the discussion, the whole team e-votes. This process continues until there’s only a small difference, or ideally until the team has agreed on the size of the feature.
Then the team moves on to the next feature, doing the same again.
And that’s it! Planning Poker is a very simple but powerful technique, designed to extract the collective wisdom of the team.
For those of you who haven’t encountered estimating in points before, I guess there’s one outstanding question: How do points make an estimate in time?
The team tracks how many points it can deliver in a Sprint (or iteration). That’s effectively their Velocity. Estimating in an abstract form – e.g. points – combined with tracking Velocity, allows a team to understand how much it can usually deliver, enabling it to forecast delivery without the need for detailed planning.
Kelly.