Get certified - Transform your world of work today


Tips for Playing Planning Poker

12 September 2017

Shane Billings

Planning Poker® can be confusing to those who are just getting started with it. Here are some tips and hints to help.

Basic rules

Before pointing is done, the team identifies a reference story. The complexity, length, and risk associated with the story are understood by all team members. The reference story is given a numeric value of 2 or 3. This story is the basis for all future stories and is used to compare new work.

A story is discussed until all members of the team understand its content. Using cards or electronic methods, team members select a Fibonacci number (1, 2, 3, 5, 8, 13, 21, . . . ) that represents the new stories relation to the reference story. This “bid” by each team member represents the complexity, size, duration, and risk of the new story in relation to the old. For example, if a reference story is a 2 and the new story is 4 times as big, then 8 would be selected. Hide your numbers until it’s time for the entire team to show them in the same instant. Compare numbers and discuss differences of opinion. Repeat until all team members are within one Fibonacci sequence of each other. Settle on the right number as a team.

Tips and hints

  1. You can’t be 100% accurate, so don’t spend a ton of time on this. No one knows the future.
  2. In spite of the fact that you can’t predict the future, you will find that the team is very accurate, and they are accurate with very little time invested.
  3. Don’t overthink it. Determine how the story “feels.” Because you are using relative sizes, your brain intuits the number pretty well without overthinking it. The conversation regarding different estimates will allow for enough depth to estimate more accurately.
  4. The Fibonacci sequence has gaps that increase over the span of the sequence. Use this gap to indicate the unknown. The larger a piece of work is, the more unknown it contains.
  5. Consider risk in the number. Use higher numbers to include risk by indicating that the work will remain less than the selected number. Risk pushes a number higher.
  6. Don’t go back and fix your estimates that are wrong. Your errors will average out over time.
  7. The discussion is just as valuable as the estimate. The point of the game is to align, communicate, understand, and remove misconceptions. Everyone should have a voice.
  8. Use the “?” option instead of a number for stories for which you are unsure of the estimate. This should feel more comfortable for many who are not able to give an estimate.
Again, keep your bids hidden until it’s time to play. Someone will always match your bid based on someone else’s number. That cuts down on the conversation.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 4 (3 ratings)


Ankur Mistry, CSP,CSM, 9/14/2017 12:04:53 AM
Thank you for sharing this Shane Billings.
Tim Baffa, CSM, 10/9/2017 4:59:21 PM
Shane, I find more success through an affinity exercise using a number of stories, in order to help a team realize a baseline for pointing.

Relative estimation is really about placing items into size categories of work (i.e. - small, medium, large, etc.).

I do have a constructive comment on your blog post though. Relative estimation is not about determining whether a story is a multiple size bigger (4x) than another story. Team members should simply assess whether the story is bigger than the one they sized at a 2. If so, is it bigger than a 3 that they sized? Bigger than a 5? And so on...
Julian Bayer, CSM, 10/13/2017 6:00:03 AM
Tim, while the approach you point out will certainly also achieve relative estimation, it's not what Mike Cohn had in mind when he designed Planning Poker (cf. "Agile Estimating and Planning"). In his view, and that of many others, a 4 will indicate that the size is twice as much as a 2.

Your approach is also vulnerable to inflation. If you change the point of reference frequently, the estimates can no longer be compared. While that may work for some teams, others may require a more stable frame of reference.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up