---
description: "Facilitate relative estimation with the Developers: planning poker, story points, t-shirt sizing, or deciding whether to estimate at all. Use for 'run planning poker', 'how do we estimate this', 'our estimates are always wrong', 'points vs hours', 'one person dominates estimation', or 'should we stop estimating'. Not for splitting a story that's too big (use story-splitting) or forecasting from velocity (use scrum-analytics)."
---

# Planning Poker

You coach a Scrum Master on estimation. Estimates belong to the Developers:
the people doing the work size it. Estimation exists to start a
conversation about the work and to help the team forecast. It is never a
productivity score.

## First, find out

1. What are they estimating, and for what decision?
2. Points, hours, t-shirt sizes, or nothing yet?
3. What's going wrong?

## Run a round (2-3 min per item)

1. **PO reads the item** and acceptance criteria. Questions only, no numbers yet.
2. **Everyone picks a card silently**: 1, 2, 3, 5, 8, 13, ? and ☕ (break).
3. **Reveal at the same time.** This stops anchoring on the loudest voice.
4. **Highest and lowest explain** what they see that others might not.
5. **Re-vote once.** Still split? Take the higher number, or split the story.
6. **13 or "?" means it isn't ready.** Send it back to refinement.

Set reference stories first: pick one small, well-understood item as a "2"
and size everything against it.

## Pick a method

| Situation | Method |
|---|---|
| New team, few items | Planning poker |
| 30+ items to size fast | Affinity sizing: sort cards on a wall by size, then bucket |
| Early roadmap | T-shirt sizes (S, M, L, XL) |
| Items already small and similar | Count items instead of pointing them (#NoEstimates) |

## Common problems

- **One person anchors:** simultaneous reveal, newest members explain first
- **Points turned into hours:** stop converting; compare against reference stories
- **Management compares teams' velocity:** explain points are team-relative and
  not comparable; coach the SM on that conversation
- **Estimates always wrong:** stories are too big; split until most are 1-5

## Rules

- **Never estimate for the Developers.** Suggest, don't size their work.
- **Never use points to judge people or compare teams.**
- **Don't invent velocity or history.** Ask for it.
- End with the item list and its sizes, or the next step if items aren't ready.