What needs to be finished first
For every item to be estimated, acceptance criteria in bullet format are available and understandable by another team member without clarification.
A shared estimate scale (Fibonacci values) with two to three calibrated reference stories is established in the team.
What needs to be ready before start
Planning poker cards (physical or a tool such as PlanningPokerOnline, Scrum Poker, Miro plugin); open backlog in ticket system; timer; visible list of reference stories; low-noise environment or calm call channel.
One facilitator (Scrum Master or PO proxy); one Product Owner as item presenter; the delivery team implementing the work (3-9 people); optionally one QA or design participant who also estimates.
Backlog items sorted by priority; acceptance criteria per item; definition of done; reference stories with assigned point values; known dependencies and risks.
2-5 min per item
Set max number of items per session (experience baseline: 6-12 in 60 minutes). Announce timeboxes: 2 min clarification, 1 min estimation, 3 min discussion for deviations. Ensure cards or tool is available for everyone.
The one question this method answers
How large is this item relative to our reference stories, and which assumptions or risks drive variance within the group?
Marker: Minute
| Step | Duration | Action | Hint |
|---|---|---|---|
10-2 min: Present item | 2 min | PO reads title, description, and acceptance criteria. Team asks clarifying questions. No solution discussion, no task breakdown in this phase. | If basic questions are still unresolved after 2 min, return item to refinement. Estimation without clear scope produces garbage. |
22-3 min: Estimate in secret | 1 min | Each person selects a card from the Fibonacci scale in private. Participants submit values simultaneously. No one talks about their estimate. | If someone shows or comments on their card before reveal, discard the round and restart. This preserves estimation integrity. |
33-4 min: Reveal and inspect spread | 1 min | Reveal cards simultaneously. If the spread is smaller than two Fibonacci steps (for example 3-5), take the higher value. Otherwise move to discussion. | Consensus is not the goal; sufficient alignment is enough. Anyone hardening on one value blocks refinement. |
44-7 min: Discuss divergence | 3 min | Highest and lowest estimators explain assumptions without justifying. Others add risks or assumptions. Then estimate privately again. | Timebox discussion strictly. After at most two rounds, either park or split. Endless estimation debates are a signal of unclear requirements. |
What comes out at the end
Updated backlog items in ticket system (Jira, Linear, Azure DevOps) with story-point value, assumptions in comments, marked split candidates, and explicit risk note for large items.
Keep estimates on the item. For re-estimation after scope change, document in comment thread without overwriting silently. Keep assumptions and risks as item comments.
Compact working template for Planning Poker with context, input, output artifacts, and next step.
Collaborative estimation method where team members choose cards privately and discuss differences.
When and for what do we use this method?
Which data, observations, decisions, or materials are available?
Short notes along the runsheet.
Owner, date, and success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Item: Tenant export API endpoint
Item: Multi-tenant tenant management
Recognize symptoms and steer against them
A senior person names a number before the round and everyone follows the same value.
Keep estimation private. Politely interrupt anyone who speaks a value early. For tool-based sessions, enable simultaneous reveal mode.
Instead of clarifying assumptions, the group starts sketching implementation or decomposing tasks.
Facilitator interrupts: We estimate, we do not design. Park design questions for refinement or spike tickets. Continue estimation with existing assumptions.
Spread remains 8 vs 21+ even after second round, with no convergence.
Split or reclassify as spike. Do not estimate over 13 without a split attempt. Very large items are discovery tasks, not estimation tasks.
Product Owner submits their own card, often too low ("this is simple").
Only delivery team members estimate. PO clarifies scope and acceptance criteria. If PO shares complexity perspective, document it as an assumption, not as an estimate.
Stakeholder asks for estimate and treats it as delivery promise in days or weeks.
Story points are relative complexity, not time. Keep velocity separate and use range in forecasts. Do not publish estimate without context.
Group estimates the same item three or four times without convergence.
After two rounds, force a decision: take higher value, split the item, or add a spike first. Three rounds without convergence is misuse of the method.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.