Planning poker has become a popular technique for agile teams to estimate user stories. But how exactly does this consensus-based approach work? In this blog, we’ll dive into the mechanics of planning poker, from how to play to who should participate and when it’s most applicable. We’ll also discuss key benefits like improved communication and accuracy, as well as potential drawbacks to be aware of.
Table of Contents
Check out this YouTube video to go through a full course on Agile Project Management:
What is Planning Poker?
Planning poker is a consensus-based estimation technique used in agile software development by product managers to estimate the effort or relative size of development goals. In other words, it’s a way for the team to come to an agreement on estimates without extensive debate or argument. It involves members of the development team making estimates by playing numbered cards face-down on the table and then revealing their estimates simultaneously. The number represents a measure of effort, often using the Fibonacci sequence as a scale (1, 2, 3, 5, 8, 13, etc.).
The goal is to avoid biases such as anchoring or groupthink by having members independently generate their estimates and then discuss them as a group. Through discussion and the sharing of information, the group converges on a consensus estimate for the goal. Planning poker is a popular way for agile teams to estimate work during sprint planning. It enables more accurate estimation and better task commitment through group knowledge sharing and discussion.
Here is our Product Management Course by Intellipaat that will help you learn product management!
How Does Planning Poker Work?
Planning poker is very similar to playing Texas Holdem poker where you are given two cards, and based on your cards and board cards, you have to make a hand, here cards are distributed among team members and they also do not show the cards until they make a hand i.e., they make an estimation for the project or task delivery as it’s an estimation technique used in agile development to estimate user stories and tasks. It brings together executives from across the organization to achieve consensus on estimates for the product backlog. Here are the steps involved in planning poker:
- Step 1 – Product Owner Presents User Story: The product owner or team lead first presents a new user story or feature to the entire development team. This user story represents a distinct piece of work that needs to be estimated by the team before it can be scheduled for development. The product owner will provide all relevant details and background on what needs to be built and why.
- Step 2 – Distribute Planning Poker Decks: Once the product owner has presented the new story, each member of the development team is then given their own planning poker deck, which is a special set of cards used for effort estimation. The planning poker deck contains cards with different numbers, like 0, 1, 2, 3, 5, 8, 13, 20, 40, 100, etc., printed on them. These numbers represent story points, which are an abstract relative measure of estimated effort or complexity for user stories. The purpose of planning poker is to leverage the team’s collective insight for estimation rather than relying on one expert.
- Step 3 – Silent Independent Estimation: Going around the table, each developer quietly examines the new story, reflects on it, and privately selects one card from their deck that represents their initial independent estimate of the overall size or effort needed to complete the story. Each team member keeps their selected card face down in front of them without showing anyone else.
- Step 4 – Reveal Initial Estimates: Once everyone has had time to make their initial independent estimation in secret, all team members simultaneously reveal their selected cards with the estimated numbers facing up on the table for everyone to see.
- Step 5 – Seek Consensus or Explain Outliers: If the estimates are within 1-2 story points of each other, the team can quickly converge on a consensus estimate for the story. However, if there is a wide range of estimates among the team, the estimators who gave the highest and lowest estimates are allowed to explain their reasoning to the group. This allows everyone to understand the different perspectives that led to the different estimates.
- Step 6 – Discuss and Revise Estimates: After the high and low estimators justify their estimates, the whole team discusses the story further, clarifying details and assumptions. Following the discussion, another round of estimation is done, with each team member selecting a new card representing their estimate after considering the discussion. If there’s still no clear solution after several rounds of discussion, it’s advisable to take a pause. Encourage individuals to study more and obtain a clearer definition or a better understanding of technical requirements. Once prepared with more knowledge, return for another round of planning poker at a later date.
- Step 7 – Iterate to Convergence: The process of estimation, discussion, and re-estimation repeats in additional iterations until the team reaches a consensus on a final estimate, measured in story points. This consensus agreement on size allows the story to be scheduled for development.
- Step 8 – Repeat for All Stories: The planning poker process is then repeated for each new user story or task introduced into the sprint backlog that needs an estimate before development.
Over the course of multiple sprints, the shared understanding and calibration of what a story point represents helps the team get better at estimation. The planning poker approach allows the team’s collective insight and multiple perspectives to surface, rather than relying on one expert view. This builds buy-in across the team for the estimates.
Take a look at the most asked Product Manager Interview Questions and Answers! Prepared by our experts and crack the interview. Ace Your Interview Now
Example of Planning Poker
The development team assembled in the office conference room for their weekly sprint planning meeting to provide effort estimates for the user stories in the upcoming sprint. John, the scrum master, started off the meeting by reading the first user story from the top of the product backlog: “As a user, I want to be able to filter search results so I can find relevant information more quickly.”
“Alright, let’s play a round of planning poker to estimate this one,” John said. The five developers each grabbed a deck of planning poker cards from the center of the table. The cards had the Fibonacci numbers 1, 2, 3, 5, 8, 13, 20, 40, and 100 written on them.
“Ready, set, reveal!” John said. The developers all flipped over their cards at the same time to reveal their initial estimate. John held up a 20, indicating he thought it was on the higher end of complexity. Sue held up a 5, thinking it would be pretty straightforward. Tom and Mary held up 8s, meaning they thought it would be moderately complex. But Chris revealed a 13, suggesting he thought it would require a significant effort.
“Hmm, we’re a bit split on this one,” remarked John. “Chris, why did you go with a 13 for this story?” Chris explained his reasoning about the effort involved in modifying the search algorithms and filtering components. After some additional discussion, the team decided to converge on an estimate of 8 story points for the first user story.
They continued in this fashion, having a quick planning poker session to estimate each user story in the sprint. If estimates varied greatly, the team discussed their perspectives to understand the rationale and come to a consensus. Using planning poker enabled collaborative estimation, while the transparency and discussion allowed the team to align on sprint plans. After finishing estimating the last story, the team totaled the points and confirmed they had planned a reasonable scope for the upcoming sprint.
Who Should Use Planning Poker?
Planning poker is a tool used to estimate effort and size for projects, often in agile software development. It involves members of the development team “playing” rounds of poker to estimate user stories or tasks by assigning story points. Planning poker works well for organizations that:
- Use agile methodologies like Scrum or Kanban that rely on estimation and story points. It integrates smoothly into agile ceremonies like sprint planning.
- Have cross-functional development teams. Planning poker brings together perspectives from developers, testers, designers, etc.
- Want consensus-based estimates? Planning poker averages out individual biases and assumptions to reach team estimates.
- Need to estimate ambiguous or subjective work. The discussion during planning poker helps build a shared understanding of the requirements.
- Are transitioning to agile and need a simple practice to introduce estimation. Planning poker is easy to understand and adopt.
Preparing for interviews? You can surely refer to our Top Product Management Interview Questions!
Does Planning Poker Really Work?
Yes, planning poker can be an effective technique for agile teams to estimate effort and size for user stories. In planning poker, each team member privately selects an estimated card representing the amount of effort they think is required to complete a user story. The cards are then revealed simultaneously, and the team discusses any major differences in their estimates. Through this discussion, the team builds a consensus estimate, leveraging their collective experience and viewpoint.
Planning poker brings together multiple perspectives to arrive at estimates, reduces anchoring bias by having private individual estimates first, and increases buy-in through the group discussion process. Overall, planning poker enables teams to produce higher-quality estimates through collaborative estimation. However, this method is time-consuming because if someone does not agree with the idea or the story, it has to be reevaluated until everyone comes to the same estimation points. It is more beneficial for the organization as the ideology does not come from one expert, so it will be more efficient.
Benefits of Planning Poker
Planning poker is a useful technique for agile software development teams, and it has several key benefits:
- Promotes Discussion and Consensus: Having team members discuss and defend their estimates leads to a more accurate consensus estimate. The discussion helps bring out technical details and complexities that individuals may not have considered independently.
- Avoids Groupthink: Because each member provides an independent secret estimate at first, it avoids individuals just going along with the group estimate. Independent thinking leads to more accurate estimates.
- Focuses on Relative Sizing: Since planning poker uses story points for estimation rather than time units, it focuses the team on the relative size and effort of user stories rather than trying to come up with precise time estimates. This accounts for the inherent uncertainty in estimating.
- Proficient Sizing: It provides a quick way to size backlog items relatively. Estimates can be easily updated as the team learns more about the stories.
- Makes Estimation Interactive: Using decks of cards and a voting activity makes planning poker more fun and interactive than traditional estimation techniques. This leads to more active participation from team members.
Drawbacks of Planning Poker
While planning poker has many benefits for agile teams, the technique also comes with some limitations to be aware of. As with any estimation approach, there are some drawbacks that teams should consider:
- Time Commitment: Planning poker sessions can take a significant amount of time, especially if the team is new to the process or if there is disagreement on estimates. The time spent playing and planning poker is time not spent working on tasks.
- False Precision: Teams can sometimes place too much emphasis on the estimates derived from planning poker rather than treating them as rough approximations. This can lead to false precision and time wasted haggling over small differences in points.
- Losing Details: Estimates are often more complex than a single number. Important details can get lost in the pursuit of point values when planning poker. Some level of narrative should supplement the estimates.
- Difficulty Estimating Complex Work: For complex tasks, it can be quite difficult to estimate the level of effort accurately. Planning poker may give a false sense of precision. Teams should remember that estimates are not commitments.
- Losing Sight of Broader Goals: If the focus becomes too narrow on point values, the team can lose sight of the broader goals and problems being solved for customers and stakeholders.
Conclusion
Planning poker brings together teams to estimate user stories through discussion and consensus. By having each member provide an independent secret estimate, it reduces individual biases. The team can then discuss any differences in estimates to understand various perspectives. This builds shared understanding, enhancing the accuracy of estimates. Though time-consuming, planning poker enables more precise forecasting of work through collaborative estimation. Overall, it is an engaging technique for producing better estimates.
If you still need clarification, reach out to our Community Page!
FAQs
What is the ideal team size for planning poker?
Planning poker works best with teams of 5–9 people. Any smaller, and you lose the diversity of estimates. Any larger, and discussions take too long.
Do you need a deck of cards to play planning poker?
No, you can use apps and online tools instead of physical cards. The cards just provide a way to hide estimates from other participants.
What if the estimates are too varied when planning poker?
If estimates vary widely, have team members discuss their reasoning to understand the differences. It’s an opportunity to share unique perspectives and learn from each other.
When should we estimate user stories when planning poker?
Estimate user stories during release and iteration planning before the development cycle begins. This helps the team commit to a reasonable scope for the sprint.
How long does planning a poker session usually take?
A typical planning poker session for a two-week sprint might take 2–3 hours. But the length can vary greatly based on team size and how many items need estimation.