Monday, October 28, 2013

Top tips for Planning Poker

Planning Poker is a simple exercise that delivers outstanding results when performed well. It can quickly lead the team to a shared understanding of the work and an accurate estimate of the size of the work. However I often see it performed sub optimally, leading to waste, inaccurate estimates, misunderstanding and division within the team.

These are my Top Tips for performing Planning Poker in an efficient, effective and fun manner.

Bring Reference Stories

Bring a range of Reference User Stories on index cards to your estimation session. I find that a range of sizes and types of work helps immensely when we are sizing. I recommend that you have between 3 to 10 Reference Stories, in the size range of 1 Story Points to 8 or even 13 Story Points. The reference story index cards can just have the story title written on them (provided the team is well aware of what the story entails).

Reference user stories

Bringing these reference stories serves two purposes. 1. There is no need to recall the Reference Stories from memory, they are right there in front of you. This makes the process of sizing stories easier and faster. 2. It stops ‘size creep’ / ‘story point inflation’, which unintentionally affects some teams.

Involve Everyone

Everyone should display an estimate each round. We do not want the situation where Developers put out a ‘?’ card each time there is a testing focused story and vis-versa.

But how can Testers size Development work you ask? By using Relative Estimation along with asking some probing questions, is the answer. The questions that we need to train the team members to ask, highlight the differences of the Un-sized Story to the Reference Stories. 

Some sample probing questions:

  • Testers can ask: How many components does it affect? How many components were affected in the reference story?
  • Testers can ask: How much development work is there per component, compared to this reference story? 
  • Developers can ask: Do we need to test it on multiple platforms, like we did for this reference story?
  • Developers can ask: Are there more functional areas to tests than this reference story?

With this information out on the table, everyone should have enough information to compare the Un-sized Story to the Reference Stories and hence select a Relative Estimate. This is one the key reasons that Planning Poker works in a cross functional team.

Talk about Complexity, Effort & Doubt

Story Points are made up of complexity, effort,& doubt, with Complexity being the most important aspect. Everyone in the team needs to understands what these all mean and how it relates to their work.

Talk about:

  • More/less complexity (more interactions between components, technical debt that makes it harder to make changes, difficult algorithms, availability of assistance from an expert in the area, availability of documentation that explains how it all works, etc.)
  • More/less effort (extra tasks, extra components to work on, less test cases to create, ability to reuse existing work, available of a tool that automates part of the work, etc.)
  • More/less doubt (lack of tests, uncertainty regarding the current design, unclear expectations from the Product Owner, new technology, not sure if the documentation covers it, etc.)

Don’t talk about numbers

Don’t let team members talk about changing your estimate. E.g.  'I will go down to a 5.' 'Ok, ok it's a 2.', ‘Alright I’ll go up’.

This results in or is the result of peer pressure. ‘Story Points are only one third of the reason for estimating’, peer pressure prevents the team from gaining the other two thirds worth of benefits. 

Also try to avoid talking about how much time it will take to do things. ‘Story Points do not equate to Time’, so we should minimise our mention of time.

Instead of talking about numbers, get the team to focus on Effort, Complexity & Doubt, and then re-vote.

Choose the Majority answer

Create a team rule that ‘When there is a lack of consistency in estimates after two rounds of estimation; the estimate which the majority of team members have chosen is selected as the estimate.’ 

Picking the majority answer instead of picking the highest answer (or the lowest) ensures that the team’s estimates will average out over the long term. Always picking the highest estimate will inflate the team’s estimates, and lead to less predictability.

Example voting results, showing to choose the majority, not to average the results
In the above example, with 4 votes to 3 votes, the team would choose 5 as their estimate.

Use estimation to confirm shared understanding

Watch out for stalled/circular discussions and call for the team to estimate. 

Sometimes you will find that the team all throws out the same estimate! When they do you can move on. Even though the conversation was going around in circles the team had a similar idea of the size of the work. Which means you can sort out the details in the sprint, instead of trying to sort it out in your estimation session.

If some team members do throw out different estimates; then you need to head back to the discussion to try and clear it up. The good news is that the attempt at sizing will have only taken a minute or so.

Combined result

Once you and your team are practiced in how to run an effective Planning Poker session; it should be fast, accurate and fun.

Do you have any other tips that have lead your team towards great Planning Poker sessions?

Interested in more tips?

Interested in estimation?

Training available in South East QLD, Australia

If this article was interesting to you, then your team would likely benefit from face to face training on Agile Estimation. I run a one-hour Agile Estimation training session, that is highly interactive, immensely fun and teaches the foundation of agile estimation along with how to effectively run Planning Poker as well as Fast Estimation. Please contact me to set up a training session for your team:


  1. This comment has been removed by a blog administrator.

  2. There are many sources today for free play video poker; some of them are good, some not so good. Hopefully this article will enable you to cut through the clutter and find the top sources. Bandar Bola

  3. With so many books and articles coming up to give gateway to make-money-online field and confusing reader even more on the actual way of earning money, situs judi online

  4. I will really appreciate the writer's choice for choosing this excellent article appropriate to my matter.Here is deep description about the article matter which helped me more. power detail sander

  5. I don t have the time at the moment to fully read your site but I have bookmarked it and also add your RSS feeds. I will be back in a day or two. thanks for a great site. situs judi online

  6. In playing online poker, human players are up against two major advantages. One is the computer generated code created by the poker sites to determine shuffles, deals and outcomes of a hand, while the other disadvantage,bandar poker terbesar just as dangerous to your bankroll, is the poker bot, that is pre-programmed with all the statistics and probabilities of the game.

  7. Very useful post. This is my first time i visit here. I found so many interesting stuff in your blog especially its discussion. Really its great article. Keep it up.
    bandar taruhan online

  8. If you visit your local department store in order to pick up a pack of plastic poker chips, such as those offered by Bicycle, you will find that they only weigh about 2 to 3 grams a piece.bandar poker online terbaik