Most teams don’t struggle with estimation because they lack experience.
They struggle because they follow a loose process.
This post gives a clear checklist to run planning poker story points properly, without confusion or wasted time.
Full guide + resources.
If planning poker sessions feel slow, inconsistent, or full of guessing, this will fix that.
Below is a step-by-step checklist you can apply in your next sprint planning.
What planning poker basics actually require
Planning poker is not just voting numbers.
It is a structured way to:
- surface hidden work
- align understanding across the team
- avoid one person deciding estimates
At its core:
- A task is read
- Everyone picks a number privately
- All numbers are revealed together
- Differences trigger discussion
That last step is the most important.
If there is no discussion, planning poker is just silent guessing.
Implementation Checklist
Use this exactly as-is in sprint planning.
Phase 1: Inputs
- [ ] Task is clearly described in simple language
- [ ] User goal is understood (example: user resets password)
- [ ] Scope is limited to one piece of work
- [ ] Team understands what is included and excluded
- [ ] Any unclear parts are called out before estimation
Phase 2: First Vote
- [ ] Each person selects a story point independently
- [ ] Use a fixed scale like 1, 2, 3, 5, 8
- [ ] No discussion before revealing cards
- [ ] All votes are revealed at the same time
Phase 3: Discussion
- [ ] Identify the highest and lowest estimates
- [ ] Ask both sides to explain reasoning
- [ ] Look for hidden steps (testing, edge cases, dependencies)
- [ ] Clarify assumptions (example: does this include error handling?)
- [ ] Update shared understanding of the task
Phase 4: Second Vote
- [ ] Team votes again after discussion
- [ ] Check if estimates are closer
- [ ] If still far apart, repeat discussion briefly
- [ ] Avoid over-discussing small differences
Phase 5: Finalize
- [ ] Agree on one story point value
- [ ] Record the estimate clearly
- [ ] Move to next task
Why the story point scale matters more than people think
The number scale is not random.
It is designed to prevent false precision.
Most teams use a sequence like:
1, 2, 3, 5, 8
This is called a growing scale.
Why it works:
- Small tasks can be estimated closely
- Large tasks cannot be predicted exactly
- Bigger gaps force rough thinking instead of fake accuracy
Example:
- Login feature → 2 points
- Checkout flow → 5 or 8 points
No one needs to argue about exact hours.
The goal is relative size, not perfect measurement.
How to handle estimation gaps correctly
Large gaps are not a failure.
They are the most valuable part of the process.
Example:
- Developer A picks 2
- Developer B picks 8
What this usually means:
- A is thinking of the basic flow
- B is thinking of edge cases or system impact
Instead of averaging the numbers, do this:
- Ask why the lowest number was chosen
- Ask why the highest number was chosen
- Identify missing details
- Align understanding
- Re-vote
This is how estimation consensus is reached.
Consensus does not mean agreement at first.
It means shared understanding after discussion.
Common mistakes (and quick fixes)
❌ Mistake: Talking before voting
✅ Fix: Always vote first, then discuss
❌ Mistake: Letting one person decide the estimate
✅ Fix: Everyone must vote independently
❌ Mistake: Using hours instead of story points
✅ Fix: Focus on effort, not time
❌ Mistake: Ignoring large differences in estimates
✅ Fix: Always explore gaps before finalizing
❌ Mistake: Over-discussing small differences
✅ Fix: Close enough is better than perfect
Quick example you can reuse
Task: Add password reset feature
First vote:
- Person 1 → 2
- Person 2 → 5
- Person 3 → 5
Discussion reveals:
- Email delivery needs setup
- Error cases for expired links
- UI confirmation states
Second vote:
- All agree on 5
Without planning poker, this might have been estimated as a quick task.
With the process, hidden work becomes visible early.
When to stop estimating
A simple rule:
If the team understands the task and estimates are close, move on.
Do not aim for perfect accuracy.
Planning poker is meant to:
- reduce surprises
- improve alignment
- keep planning fast
If a task is too unclear to estimate, do not force it.
Break it into smaller tasks first.
Wrapping Up
Planning poker story points work when the process is followed, not just the voting.
The checklist above ensures:
- every estimate is discussed
- hidden work is surfaced early
- the team aligns before building
This post focuses on execution.
The full guide goes deeper into why this method works, how teams improve over time, and how to avoid long-term estimation drift.
Top comments (0)