Planning Poker: Why Independent Estimates Matter
You've probably seen this happen during a refinement session.
A developer reads through a ticket, considers the requirements and says, "Looks like a five to me."
They're experienced. They know the codebase. They've worked on similar features before.
A few moments later, the rest of the team agrees.
Five points it is.
The meeting moves on, everyone feels productive, and nobody particularly questions the outcome.
But did the team genuinely agree? Or did everyone simply accept the first reasonable number?
This is one of the problems Planning Poker is designed to address.
The first estimate changes the conversation
Imagine four developers discussing a GitHub issue to add notification preferences to an application.
The most experienced developer estimates three points.
Another developer initially thinks eight because the change might require updates to an existing API and database schema.
But after hearing three, they reconsider.
Perhaps they've overcomplicated it. Perhaps the senior developer knows something they don't.
They settle on five.
The remaining developers follow with three and five.
The team quickly reaches a consensus.
Except the original concern about the API and database changes never gets discussed.
This is an example of anchoring: the tendency for an initial piece of information to influence subsequent judgements.
It doesn't require anyone to behave badly. The senior developer might have offered their estimate with the best intentions.
But once a number is in the room, it can influence how everyone else evaluates the work.
And in a team with different levels of experience, that influence can be considerable.
Why Planning Poker hides estimates
The central idea behind Planning Poker is simple.
Everyone considers the same requirement and selects an estimate independently.
The estimates remain hidden until everyone has made their choice.
Then they're revealed together.
This small change removes the opportunity for the first estimate to become the reference point for everyone else.
It also encourages developers to think about the work before seeing what their colleagues believe.
That matters because different developers bring different knowledge.
A frontend engineer might recognise complexity in component state management.
A backend engineer might identify an API compatibility issue.
A QA engineer might notice that the acceptance criteria don't describe what happens when a request fails.
None of these perspectives should automatically outweigh the others.
Independent estimation gives them an opportunity to surface.
Disagreement is useful information
Let's return to the notification preferences issue.
This time, the team estimates independently.
The scores are revealed:
| Contributor | Estimate |
|---|---|
| Developer A | 3 |
| Developer B | 5 |
| Developer C | 8 |
| Developer D | 13 |
At first glance, that might look like a failed estimation round.
Four people, four different estimates.
But it's potentially much more useful than four people agreeing on five without discussion.
The next question shouldn't be, "How do we get everyone to agree?"
It should be, "What is everyone seeing differently?"
Developer A explains that the application already has a settings component that could be reused.
Developer D points out that notification preferences are currently stored differently across two services.
Developer C raises a concern about how existing users will receive default settings.
Suddenly, the conversation isn't about numbers.
It's about architecture, dependencies and behaviour.
The estimates have exposed assumptions that might otherwise have remained hidden until implementation.
That's valuable.
Don't automatically average the estimates
A tempting response to disagreement is to calculate an average.
Three, five, eight and thirteen produce an average of 7.25.
Round it to eight and move on.
Convenient, but largely pointless.
Story points aren't precise measurements, and averaging them doesn't resolve the underlying differences in understanding.
If one developer believes a database migration is necessary and another believes it isn't, choosing eight points doesn't answer that question.
The team needs to investigate the disagreement.
Perhaps the migration is unnecessary.
Perhaps the requirements need updating.
Perhaps the issue should be split into smaller pieces of work.
Only after resolving the important assumptions should the team consider estimating again.
Senior developers still have an important role
None of this means experienced engineers should remain silent.
Their knowledge is often essential to understanding the work.
They may recognise architectural constraints, identify opportunities to reuse existing code or explain why an apparently simple change has wider consequences.
The distinction is between sharing technical context and establishing the estimate before everyone else has considered it.
A senior developer saying, "There's an existing service we can reuse here," adds useful information.
A senior developer opening with, "This is definitely three points," may unintentionally narrow the discussion.
The objective isn't to remove experience from the process.
It's to ensure that experience informs the team's judgement rather than replacing it.
What happens after the reveal?
A productive Planning Poker session doesn't need endless rounds of voting.
A practical approach is:
- Give everyone time to review the requirement.
- Ask contributors to choose estimates independently.
- Reveal all estimates simultaneously.
- Invite people with different estimates to explain their reasoning.
- Identify any missing requirements, dependencies or risks.
- Estimate again if the discussion has materially changed the team's understanding.
Sometimes the second round produces agreement.
Sometimes it doesn't.
That's not necessarily a problem.
If significant uncertainty remains, the team might need to investigate the work before committing to an estimate.
Forcing consensus simply to complete refinement can create false confidence.
And false confidence has a habit of becoming somebody else's problem halfway through a sprint.
Consensus doesn't mean identical thinking
A team doesn't need everyone to approach a problem in exactly the same way.
In fact, that would remove much of the value of collaborative estimation.
What matters is that everyone understands the important assumptions behind the agreed estimate.
A developer might still personally consider the work closer to eight points than five.
But if the team has discussed the risks, clarified the scope and reached a reasoned decision, that's a much stronger outcome than simply following the first number suggested.
Consensus should be the result of shared understanding, not social pressure.
See Pointwise in action
This principle of independent estimates is central to Pointwise, the GitHub-integrated Planning Poker application I've been building.
Contributors select estimates independently, scores remain hidden until the session leader reveals them, and the GitHub issue stays available throughout the discussion.
Here's a short walkthrough of the workflow:
Watch the Pointwise walkthrough on YouTube
Final thoughts
Planning Poker isn't valuable because it produces a number.
It's valuable because it creates space for different perspectives before the team reaches a decision.
Independent estimates reduce the influence of the first opinion.
Simultaneous reveals make disagreement visible.
And the discussion that follows helps the team understand the work more clearly.
The next time everyone immediately agrees with the most experienced developer, it might be worth asking whether you've reached genuine consensus or simply skipped the conversation.
How does your team handle large differences in estimates? Do you explore the reasoning or try to reach agreement quickly?
Top comments (0)