What is Pointing Poker?
Pointing Poker (also known as Planning Poker) is a consensus-based, gamified technique used by Agile teams to estimate the relative effort of development tasks. By using a Standard (1, 2, 3, 5, 8, 13, 21 etc.) or Modified Fibonacci Sequence (1, 2, 3, 5, 8, 13, 20, 40, 100), teams avoid the “illusion of precision” and focus on the complexity of a task rather than just the time it takes.
While there are other types of estimation scales like T-Shirt Sizing etc., we’ll focus on estimation using Story Points.
How to Play Pointing Poker
- (Step 1) The Story Introduction, Clarification, & Shared Understanding: The Product Owner or Scrum Master (or anyone from the team if needed) presents a User Story, task, or something else from the backlog. The team discusses & refines the requirements, acceptance criteria, and potential technical hurdles to ensure everything is correct and understood by everyone and meets the definition of ready to start the work in a sprint. This ensures everyone is estimating the same scope of work.
- (Step 2) Private Voting (Neutralizing “Anchoring Bias”): Once everyone understands the item to be estimated, every participant will choose their own Story Points estimation from a Fibonacci sequence based on their personal assessment of effort, complexity, and risk. You can have physical cards, or select the size on an online tool (it’s up to you). Just make sure that everyone keeps their selection hidden for now. By keeping votes hidden, you capture the honest, diverse perspective of the entire team, exposing hidden complexities that a single “expert” might miss. In many meetings, a senior developer or a loud voice “anchors” the room by saying, “This looks like a 3.” Junior team members or people who are maybe a little more introverted may tend to follow suit to avoid conflict, which is not what you want – sound familiar?
- (Step 3) The Synchronized Reveal: Once the “moderator” sees that all team members have voted, they prompt the team to reveal their Story Point estimates to the group all at once. The team immediately gets to see the “Spread.” A tight spread (e.g., all 3s and 5s) indicates relatively high alignment. A wide spread (e.g., a 2 and a 21) indicates a significant misunderstanding of the task’s complexity or requirements.
- (Step 4) Outlier Discussion & Consensus: If the estimates aren’t exactly aligned across all team members, the team should enter a focused discussion on the outliers. The team members with differing estimates should take turns explaining the reasoning why they selected their estimate, and have an open discussion to determine whether estimates need to change. Team members might have spotted a security risk others missed, or have prior knowledge of the real effort to do something from experience. After the discussion, the team typically re-negotiates their estimates and come to an agreement on a single number.
- (Step 5 – Optional) Break Down Large Items: In most mature Agile teams, a high estimate isn’t just a number, it’s a signal that a task is too complex to be handled safely in a single iteration. Identify your threshold: For most teams, an 8 or larger is a red flag. If the consensus lands on a high value, stop and ask: “Can we split this?” Break the item into smaller, independent tickets, each with its own Acceptance Criteria. Smaller tickets move through the “In Progress” column faster, reduce the risk of sprint carry-over, and provide the team with a higher “Win Rate” (Success) by the end of the sprint.
💡 Three Major Dimensions of Estimation
(#1) Complexity: Complexity refers to how intricate or “knotty” the logic of a task is. Is this a straightforward “search and replace,” or does it require deep architectural changes? A task might only take 20 lines of code (low “muscle”), but if those 20 lines interact with five different legacy systems, the complexity is high. High complexity necessitates a higher estimate to account for the mental focus required.
(#2) Effort: Effort, often referred to as “capacity” or “muscle”, is the sheer volume of work required to get the task across the finish line. Even if the logic is simple, is there a lot of it? For example, updating the brand colors on 50 different buttons is low complexity but high effort. It takes “muscle” to perform the repetitive actions. If a task requires a high volume of manual work, the estimate must scale upward to reflect the time the developer will be “occupied.”
(#3) Uncertainty: Uncertainty (or lack of certainty) is an important factor in sprint planning. It represents the “known unknowns.” Have we done this before? Is the documentation clear? Typically, a higher uncertainty equals a higher story point value to account for the additional unanticipated time it could take to do something.
5 Common Pointing Poker Pitfalls (And How to Fix Them)
- The “Points-to-Hours” Trap: Trying to establish a hard conversion rule, such as “1 Point = 8 Hours” may seem like a good idea, but you may want to reconsider. Story points are designed to measure relative effort, not absolute time. Senior developers and junior developers work at different speeds; while a task might take a Senior 4 hours and a Junior 12 hours, the complexity (the points) remains the same. Instead, use your team’s historical velocity (how many points you finish per sprint) to plan capacity, rather than trying to map points to the clock. If you’re a new team and have no baseline, focus on agreement and refine your sizing over time.
- Averaging the Votes: If three people vote “3” and one person votes “8,” averaging would mean everyone settles on a “5” to move quickly. Pointing Poker is a tool for discovery, not math. The person who voted “8” likely saw a risk or a technical hurdle that the “3” voters missed. By averaging, you ignore the very information that prevents sprint “carry-over.” In order to make accurate estimations, the team should always discuss the outliers. Let the “high” and “low” voters explain their reasoning, then re-vote. The goal is consensus, not a mean average.
- Estimating Without “Ready” Criteria: You’re destined for failure if a story doesn’t have clear acceptance criteria or the team doesn’t have a well defined “Definition of Ready” (DoR). If the team doesn’t know exactly what “Done” looks like, the estimate is just a guess. If the team is confused during the discussion, stop the vote. Move the story back to “Refinement” and only point it once the requirements are stable.
- Anchoring to the “Loudest Voice”: If someone says anything which could bias the decision before estimates are voted/shared, the rest of the team could subconsciously “anchor” to an estimate. This creates a false consensus and hides potential issues, and stifles discussion. This is why votes remain hidden and discussion happens after the moderator triggers the reveal, ensuring every voice is heard equally.
- Forgetting the “Buffer” for UX review, QA testing, and UAT: Estimating only the time it takes to write the code can get you in trouble. A story isn’t done when the code is written; in most teams it’s done when it’s tested, reviewed (and potentially deployed). Remind the team that a Story Point covers the entire lifecycle of the task. If a task is easy to code but difficult to test, it deserves a higher point value.
Master the Art of Estimation with Pointing Poker.
Eliminate “Estimation Bias” and align your engineering team with the world’s most popular agile consensus tool. No login required. Totally free.