What is Planning Poker?
Planning poker (also called Scrum poker) helps agile teams estimate the time and effort needed to complete each initiative on their product backlog. The name from this gamified technique is planning poker because participants use physical cards. These cards, which look like playing cards, estimate the number of story points for each backlog story or task up for discussion.
The design of this process was to help software organizations more accurately estimate development timeframes, build consensus among the members of the cross-functional team, and more strategically plan the team’s work.
How Does Planning Poker Work?
Planning poker brings together stakeholders from across departments in the organization to reach a consensus on the estimated effort needed for several backlog initiatives. For an agile software organization, stakeholders can include a product owner, developers, UX designers, QA testers, and product managers, among others.
Step 1: Hand out the cards
Participants are all given an identical deck of cards (or chips), each with a different number. One common sequence is based on doubling each number: 1, 2, 4, 8, 16, 32, 64. The sequence recommended by Mountain Goat Software’s Mike Cohn, who popularized planning poker for agile development, is 0, 1, 2, 3, 5, 8, 13, 20, 40, and 100.
The decks are limited, with significant number-jumps, because the goal is for all participants to reach a consensus number for each story. Giving participants too many options—say, each number from 1 to 50—would make the process inefficient.
Step 2: Read the story
Next, the product owner (or possibly a product manager) will read each story out loud to the group.
Step 3: Discuss
Now that everyone has heard the story, the group will discuss it. Participants will describe how they envision handling the work, how many people they estimate would be involved, which skill sets will be required, and what if any obstacles they envision slowing progress. The group will also use this time to ask questions about the story.
Step 4: Estimate and share
After everyone has had their say and gotten any questions answered, each person will secretly choose a card from the deck to represent their estimate of story points. When everyone is ready, all participants reveal their cards at the same time.
The higher a participant’s card is, the more difficult that participant estimates the story will be to complete.
Step 5: Work toward consensus
If all participants’ reveal the same card, then that number becomes the consensus. The group can move on to the next story.
But if the cards differ, then the group continues its discussion about the story. Those with higher (or lower) estimates than the rest of the group will explain their reasoning and try to persuade their coworkers to see their position.
When the group has concluded this new round of discussion, everyone will again review their cards and either keep their previous choice or select a new one. All participants will again reveal their cards at the same time.
Where did Planning Poker Originate?
According to a paper written for Sacramento State University, the history of planning poker goes back to another estimation technique called Wideband Delphi, developed by the RAND Corporation in the mid-twentieth century.
Software entrepreneur James Grenning then refined the technique in 2002, calling it Planning Poker and tailoring it for agile development teams.
Finally, Mountain Goat Software’s Mike Cohn popularized planning poker in 2005 with his book Agile Estimating and Planning.
Which Organizations Should Planning Poker?
Planning poker can be a useful estimation technique for any team in any organization. But the approach works particularly well for smaller businesses and smaller teams. Larger organizations tend to have more substantial teams. The more people participate in a planning poker session, the longer it will take to reach a full consensus on each item.
Planning Poker’s Benefits and Drawbacks
For agile teams, planning poker is an excellent resource for prioritizing items on your agile roadmap.
1. The game framework encourages collaboration and team building.
2. Requiring a consensus among the team, rather than having one person dictate estimates, can increase morale by giving everyone on the cross-functional team a vote.
3. The conversational format can uncover valuable insights from members of the team who might not otherwise have a forum to share their thoughts and experiences.
But the process does have downsides.
1. Arriving at a consensus can give the team a false sense of confidence. They might still be missing important pieces of information, and their estimate might still be off.
2. A dominating person in the group can unduly influence the other participants. If you’re not careful, it can lead to estimate driven not by consensus but force of will.
3. Research suggests a group estimate tends to be more optimistic than the forecast that the group’s members would come up with in isolation. In this way, the discussion portion of a planning poker meeting can lead to a team talking itself into believing it can accomplish more with less time than they actually can.