Planning Poker Timer

READY
02:00

Common uses for a planning poker timer

  • Sprint planning and backlog refinement
  • Timeboxing estimation sessions
  • Keeping planning meetings finite
  • Remote estimation

Planning poker estimates work by having everyone reveal an estimate simultaneously, then discussing the outliers. The simultaneous reveal is the whole mechanism — it prevents the first or loudest estimate from anchoring everyone else, which is the failure mode of estimating by discussion.

Two minutes per story is a reasonable budget covering a brief description, a first vote, and one round of discussion. A story that cannot be estimated in two rounds usually needs splitting or investigation rather than more argument, and that is the useful signal.

The spread is the information

When one person says two and another says thirteen, the useful output is not the average — it is the discovery that the two of them are imagining different work. Converging quickly to a number hides that and the difference resurfaces mid-sprint.

The right response to a wide spread is to ask the highest and lowest estimators to explain, briefly. That conversation is where planning poker earns its time, and skipping it makes the whole exercise a slow way to produce a number.

Two rounds, then move on

Vote, discuss the outliers, vote again. If the second round is still widely split, the story is not well enough understood to estimate, and the correct outcome is a spike, a split, or a decision to defer it.

Continuing to a third and fourth round produces convergence by attrition rather than by understanding, which is worse than an honest admission that nobody knows yet.

Timebox the session, not only the story

Estimation sessions expand without limit because there is always another story. Setting a total budget — sixty minutes, whatever gets estimated gets estimated — forces the team to start with what matters most.

It also surfaces a real problem when a session repeatedly runs out with important stories unestimated: the backlog items are too large or too vague, which is more useful to know than to work around.

Per-story and session budgets. A story needing more than two rounds is a signal rather than a problem to push through.

Planning poker budget
Element Budget Note
Story description 30 s Enough to vote on
First vote 15 s Simultaneous reveal
Outlier discussion 60 s Highest and lowest explain
Second vote 15 s Usually converges
Still split? Spike, split or defer
Session total 60 min Whatever fits, fits
  • The spread is the information — a two versus a thirteen means two people are imagining different work.
  • Third and fourth rounds produce convergence by attrition rather than understanding.

Source: Planning poker practice and per-story budgets are agile estimation convention rather than a published standard

Sources

  1. Planning poker practice and per-story budgets are agile estimation convention rather than a published standard , TheTimerLab — accessed 2026-07-28

🔗 Related Timers

❓ Frequently Asked Questions

How long should each story take to estimate?
About two minutes — a brief description, a first vote, and one round of discussion. A story needing more than two rounds usually needs splitting or investigation rather than more argument.
Why reveal estimates simultaneously?
It prevents the first or loudest estimate from anchoring everyone else, which is the failure mode of estimating by open discussion. The simultaneous reveal is the entire mechanism.
What does a wide spread mean?
That the estimators are imagining different work. That discovery is the useful output — averaging it away hides a misunderstanding that will resurface mid-sprint.
How many rounds should we do?
Two. If the second round is still widely split, the story is not understood well enough to estimate, and a spike, a split or a deferral is the correct outcome.
Should I timebox the whole session?
Yes — estimation expands without limit because there is always another story. A sixty-minute budget forces the team to start with what matters most.
What if we keep running out of time?
That is a signal that backlog items are too large or too vague. It is more useful to know that than to work around it by scheduling longer estimation meetings.
TheTimerLab