Posts

How to handle disagreements during planning poker

A diverse agile team sitting around a table during a planning poker session, holding up cards with different estimates showing disagreement, with a scrum master facilitating the discussion You reveal the cards. One developer played a 3. Another played a 13. The room goes quiet for a second, then everyone starts talking at once. If you have been facilitating planning poker for any length of time, you know this moment well. Most scrum masters treat it as a problem to fix quickly. Get to consensus, move on to the next story. But the disagreement itself is the most valuable part of the entire session. The gap between a 3 and a 13 means your team holds fundamentally different assumptions about the work, and surfacing those assumptions before the sprint starts is exactly what estimation is for. Here is how to turn those disagreements into better sprint outcomes instead of wasted time.

Why estimation disagreements are valuable

If your team agreed on every estimate immediately, you would not need planning poker at all. You could just have one person assign numbers. The reason simultaneous reveal exists is specifically to surface disagreement. When estimates diverge, it usually means one of three things: Hidden complexity. One developer sees a straightforward CRUD operation. Another sees an edge case involving concurrency or a fragile integration that will need careful handling. Without the disagreement, the team would commit to the lower estimate and discover the complexity mid-sprint. Different assumptions about scope. "Build the search feature" means full-text search with filters and pagination to one developer and a simple string-match dropdown to another. The gap in estimates reveals that the acceptance criteria need clarification before the team starts building. Missing requirements. A large spread often signals that the story itself is incomplete. When someone estimates high because they are accounting for unknowns that others have not considered, those unknowns need to be named and resolved.

The outlier discussion technique

The single most effective facilitation move during planning poker is asking the outliers to speak first. After revealing cards, always start with the person who estimated highest and the person who estimated lowest. This works for three reasons:

1. It gives the outliers the floor. In many teams, the person who played a 2 when everyone else played an 8 will stay quiet unless specifically invited to explain. They might know something nobody else considered, or they might be misunderstanding the story. Either way, you need to hear from them.
2. It prevents the majority from steamrolling. If five people played an 8 and one played a 2, the natural instinct is to pressure the outlier to conform. Starting with the outlier signals that their perspective matters regardless of numbers.
3. It focuses the discussion. Instead of a free-for-all where everyone restates their reasoning, you get a structured debate between the two ends of the spectrum. The rest of the team listens and adjusts their mental model.

Two software developers having a respectful, engaged discussion over a laptop screen, with one pointing at the screen explaining their technical approach while the other listens thoughtfully, with estimation cards visible on a whiteboard

How to facilitate the outlier discussion

Use these specific prompts to guide productive outlier conversations:

• To the lowest estimator: "Walk us through your approach. What does this story look like in your head?"
• To the highest estimator: "What risks or complexity are you seeing that might not be obvious?"
• To both: "What assumptions are you making about the scope?"
• After both speak: "Does anyone want to change their estimate based on what you just heard?"

Then re-vote. Most of the time, the team converges after one round of outlier discussion because the conversation revealed either a scope misunderstanding or a technical risk that changes everyone's mental model.

Common causes of disagreement

Understanding why estimates diverge helps you resolve disagreements faster. Here are the patterns you will see most often:

Different understanding of scope

This is the most common cause. Two developers read the same user story and picture completely different work. One interprets "add notifications" as an in-app toast message. Another interprets it as email notifications with templates, delivery tracking, and unsubscribe handling. How to resolve it: Ask the product owner to clarify scope on the spot. If the PO is not in the room, park the story and bring it to the next backlog refinement session.

Different technical approaches

Two developers might agree on the scope but disagree on how to build it. One plans to extend an existing service. Another believes the existing service cannot handle the load and wants to build a new one. How to resolve it: This is not an estimation problem; it is a design decision. Have the team briefly discuss the tradeoffs and pick an approach. If it needs more investigation, create a spike and estimate the story in the next session.

Experience gaps

A senior developer who has built similar features before estimates a 3. A mid-level developer who has never touched that part of the codebase estimates an 8. Both are being honest, and both are right based on their own experience. How to resolve it: Estimate for the team, not the individual. Ask: "If a typical team member picked this up, how much effort is it?" If only one person can do the work, that is a knowledge-sharing risk worth flagging, but it should not inflate the estimate. The estimate should reflect inherent complexity, not who happens to do the work.

Unclear acceptance criteria

When stories are vague, estimates become guesses. "Improve performance" without a target number. "Make the dashboard more user-friendly" without mockups. These stories are not ready for estimation. How to resolve it: Send them back. Stories that cannot be estimated should return to refinement. If you are seeing this pattern frequently, the issue may be in how user stories are being written. You can also use an estimation complexity analyzer to flag underspecified stories before they reach the estimation table.

Timebox your estimation discussions

This is where most facilitation goes wrong. A disagreement surfaces, the discussion is productive for two minutes, and then it spirals into a 15-minute architecture debate. The team estimates four stories in an hour instead of twelve. Set a hard five-minute timebox per story. Here is how to enforce it: A close-up overhead shot of a meeting table with planning poker cards showing different estimates, a timer, and sticky notes with user story text, conveying structured estimation debate

Why you should never average estimates

When a team cannot agree, it is tempting to split the difference. "We have a 5 and a 13, let's call it an 8." This feels fair and efficient. It is neither. Averaging hides the disagreement instead of resolving it. The person who said 13 has information about risks or complexity that does not go away because you wrote down 8. When the sprint starts, those risks are still there, and the team has committed to an estimate that reflects neither perspective accurately. Averaging also defeats the purpose of using a nonlinear scale like Fibonacci. The jumps between values (1, 2, 3, 5, 8, 13, 21) are intentionally large to force teams into meaningful distinctions. A 5 and a 13 are not "close enough to meet in the middle." They represent fundamentally different understandings of the work. For more on why story point scales are designed this way, see our deep dive. What to do instead of averaging:

• Use the outlier discussion technique to surface the root cause of disagreement
• If you must pick a number without consensus, go with the higher estimate. It is safer to overestimate than to underestimate
• If the gap is extreme (e.g., 2 vs. 21), the story is not ready. Send it back to refinement

Use simultaneous reveal to prevent anchoring bias

Anchoring bias is the tendency to rely heavily on the first piece of information you hear. In estimation, this means the first number spoken out loud becomes the anchor for everyone else's thinking. If a senior developer says "this feels like a 3" before cards are revealed, the rest of the team unconsciously adjusts toward that number. Anonymous planning poker solves this by ensuring all estimates are submitted before any are revealed. Nobody sees anyone else's number until everyone has committed. This is not just a nice-to-have; it is a structural safeguard against one of the most well-documented cognitive biases in decision-making. Tools like Kollabe enforce simultaneous reveal automatically. Cards stay hidden until every participant has selected their estimate. This is significantly more reliable than physical cards, where someone inevitably flips early or holds their card at an angle. Teams that lack psychological safety benefit especially from anonymous estimation. When junior developers feel that their honest estimate might be judged by senior team members, they default to whatever the seniors play. Anonymity removes that dynamic entirely.

When to stop discussing and split the story

Sometimes a disagreement is not about misunderstanding. Both sides fully understand the story, but the work is genuinely complex and uncertain. When that happens, the answer is not a longer debate. The answer is to split the story. Signs that a story needs splitting rather than more discussion:

• Estimates span more than three Fibonacci values (e.g., 3 to 21)
• The discussion keeps circling back to "it depends on..." multiple scenarios
• Different parts of the story could be delivered independently
• The team identifies distinct risk areas that could be isolated

How to split effectively: Split along value lines, not technical layers. "Build the API" and "Build the UI" are not good splits because neither delivers user value alone. Instead, split by user scenario: "Search by name" and "Search with advanced filters" each deliver something a user can actually use. After splitting, re-estimate each piece. You will often find that the sum of the parts is larger than the original estimate, and that is fine. The original estimate was wrong because the story was too big to estimate accurately. Smaller stories are easier to estimate, build, and verify.

The confidence vote technique

You have discussed the outliers, re-voted, and arrived at a number the team accepts. But acceptance is not the same as confidence. The "fist of five" confidence vote catches the difference. After reaching consensus on an estimate, ask every team member to simultaneously hold up one to five fingers:

Fingers	Meaning
5	Fully confident, no concerns
4	Confident, minor uncertainty
3	Acceptable, some reservations
2	Uncomfortable, significant concerns
1	Strongly disagree, should not commit

If anyone shows a 1 or 2, they get 60 seconds to explain their concern. Often it surfaces a risk that the team should note even if the estimate does not change, like a dependency on another team or a piece of legacy code that might resist changes. This takes 15 seconds per story when confidence is high and only adds time when there is a concern worth hearing. It is a low-cost safety net against silent disagreement.

Putting it all together: a facilitation checklist

Disagreements during planning poker are not a sign of dysfunction. They are the mechanism through which your team builds shared understanding. The goal is not to eliminate disagreement. It is to have a structured way of extracting the information that disagreement contains and turning it into better estimates and better sprint outcomes. For a broader look at estimation approaches beyond planning poker, see our guide to agile estimation techniques.