First I need to start off by saying that my experience is related to combining planning poker with agile development. For me this is Scrum. For planning poker to work I believe you need to use commitment driven planning as part of your sprint or iteration planning. I think that without this, planning poker will not be equally efficient.  One of the tools a team has in agile development is velocity, so let me first explain velocity.

Velocity is the average amount of story points your team successfully has committed to over one or more sprints. A team’s velocity will evolve over time, and be more and more accurate if you can:

1. Keep the number of members in your team stable
2. Have the same length on all sprints
3. Keep doing the same estimating mistakes
   

If you change either one of these, you will weaken your velocity. Here are some examples of the above:

1. By removing a member from your team, you will not be able to do as much work as before, resulting in a sprint with fewer story points than in previous sprints.
   
   
2. If you have a shorter sprint than your normal sprint length, you will be able to commit to less story points which gives a wrong outcome for your velocity.
   
   
3. If there is a sudden increase/decrease in the amount of story points estimated for a user story compared to a previously similar user story, the velocity will be less accurate.
   

One important thing about velocity is that it’s not necessarily this number you should use when your team is committing to user stories for a sprint. The velocity main purpose is to plan ahead for more than a sprint, e.g. for release planning. Typically the product owner uses the team’s velocity to calculate how much work can be fitted into one release.

When you sit down for a game of planning poker you focus on estimating user stories. Before you start a sprint the team goes through the estimated user stories and commits to do a certain number of these in the sprint. The first time they will probably miss by committing to too much. The second time they will do better and so on. Eventually the team will get a feeling of how much they can commit to. Remember what I said earlier, the team should not USE the velocity to commit, but rather use it as a warning sign. E.g. if the team commits to much more than the current velocity, you might want to check your commitment again.

So, back to estimation. If a team consequently estimates to low on their user stories, this will be corrected by how much the team is actually willing to commit to in the sprint. This is also indicated by the velocity. It’s much easier to control and to see when the team misses a sprint, than to keep track of all estimates and figure out which were estimated too high or too low, and try to learn from that. This also means that you can’t try this couple of times, see that it didn’t work, and give it up. You need to give it time.