The process:

1. Product Owner describes a backlog item — what it is, why it matters, acceptance criteria
2. Team discusses — asks clarifying questions, identifies unknowns, talks through implementation
3. Everyone selects a card simultaneously — Fibonacci numbers: 1, 2, 3, 5, 8, 13, 21
4. Cards revealed at the same time — prevents anchoring bias
5. If estimates diverge significantly — the highest and lowest estimators explain their reasoning
6. Re-vote — consensus usually emerges in 2-3 rounds
7. Record the agreed estimate — move to the next item

Why Fibonacci numbers:

• The gaps between numbers grow deliberately: 1, 2, 3, 5, 8, 13, 21...
• This forces the team to acknowledge uncertainty — there is no "11" or "15"
• An item estimated at 13 is not precisely 13 units of effort; it is "bigger than 8, smaller than 21"
• The increasing gaps reflect the reality that larger items have more uncertainty

From estimates to forecasting:

• After 3-4 sprints, you know your velocity (story points completed per sprint)
• If velocity is 30 points/sprint and the remaining backlog is 120 points, you need ~4 sprints
• This is empirical forecasting — based on actual data, not wishful thinking
• Velocity naturally accounts for meetings, interruptions, and context switching

Common mistakes:

• Treating story points as hours (they are relative, not absolute)
• Letting the most senior person estimate first (destroys independence)
• Estimating items larger than 13 points without breaking them down first
• Ignoring velocity data in favor of "gut feel" timelines