Purpose
We use planning poker to build shared understanding before committing to an estimate. The estimate is a planning aid, not a promise, and it should capture the team's current view of effort, complexity, and uncertainty.
What a card includes
- Implementation work needed to satisfy the agreed acceptance conditions.
- Testing, review, and reasonable refactoring required to complete the item.
- Known integration, release, or data work directly tied to the item.
- Uncertainty that remains after normal clarification.
What a card does not include
- Unrelated cleanup that should be planned separately.
- Future scope that is not part of the current acceptance conditions.
- Work blocked by a decision or dependency that needs discovery first.
- Pressure to match a delivery date or individual capacity target.
Voting rules
- Clarify the item before voting.
- Vote privately without announcing numbers first.
- Use ? when the item cannot be estimated responsibly.
- Discuss high and low estimates after reveal.
- Revote if the discussion changes the shared understanding.
- Record assumptions next to the final estimate.
When we split or pause
We split an item when it contains multiple user outcomes, unrelated technical risks, or a vote spread that remains wide after discussion. We pause estimation when an important decision, dependency, or research question prevents the team from forming a responsible estimate.
Review cadence
Revisit this agreement after several sessions or when estimation meetings stop producing useful conversations. Adjust the deck, the definition of a card, or the discussion rules based on observed problems rather than one isolated disagreement.