Planning Poker

The definition of Planning Poker

Planning Poker, also known as Pointing Poker or Scrum Poker is an Agile estimation method used by many Agile teams, particularly Scrum teams.

It is easy to learn and provides a quick way to estimate stories, discover knowledge gaps, and encourage conversation.

Like it or not, in technology, delivery dates and time estimates are a day-to-day reality for the vast majority of teams.

To help teams provide realistic estimates without thinking in terms of days or weeks, story points are often used to measure effort and complexity instead of time.

This way, a team can agree on what a 1, 2, or 5 story point task looks like and use these baselines for all future tasks and stories.

Over a period of several sprints, the team establishes an average velocity which can then be used as a rough calculation for delivery dates and time estimates.

But how does a team agree on the number of points to give a user story? This is where Planning Poker comes in.

How to play — quickstart

  1. Bring the team together to discuss a story or group of stories.
  2. Present the story with acceptance criteria and relevant business and technical context.
  3. Ask the team to submit their votes.
  4. Look for large discrepancies in votes (e.g. 1 vs. 5)
  5. Encourage conversation to ensure the team has a shared understanding of the story.
  6. Revote, if necessary, and record the value with a majority of votes.

Planning Poker is most commonly played during sprint planning or backlog grooming sessions. Commonly, a modified Fibonacci sequence is used (e.g. 1, 2, 3, 5, 8, 13, 20) to avoid small discrepancies in estimation.

The Scrum Master or Product Owner presents the user story and technical or business context, answers any related questions, then asks team members to submit their votes.

There are many free tools to facilitate voting, but Slack will work in a pinch. As the votes come through, there is often a good median number to go with, but sometimes there are big discrepancies between scores.

When this happens, there will be a conversation about why each person voted the way they did. Often, one person is missing something or another person has specific knowledge that the others don’t.

Either way, the discussion will educate, level-set, and/or align the team and make sure there’s a shared understanding. If necessary, call for another vote and record the value with a majority of votes, assuming there are no longer large discrepancies between scores.