Purpose
Estimation lets you forecast scope and plan sprints. The key idea: estimate relative complexity/size/risk, not hours — people guess absolute hours poorly but compare "bigger than that" well. Relative estimates are steadier and faster than precise hour forecasts.
How it works
Story points — a dimensionless measure of relative size (complexity + volume + uncertainty).
Fibonacci: 1·2·3·5·8·13·21 — growing gaps reflect growing uncertainty with size.
Planning poker — the team reveals cards SIMULTANEOUSLY; on disagreement discuss "why" and converge.
Reference story — an anchor of known size; estimate new ones relative to it.
Velocity — points actually closed per sprint; for FORECAST, not team comparison, not a KPI.
Worked example 1 — poker
Story: "Filter cards by tags". Anchor: "Save to favorites" = 3 SP.
Cards revealed: 3, 3, 5, 8 → disagreement. The 8-voter cites multi-select + URL state + empty result.
Consensus: 5 SP. A 13 would signal "too big, split into 2".
Worked example 2 — velocity forecast
Velocity over 4 sprints: 18, 22, 20, 20 → avg ≈ 20 SP/sprint. Backlog: 62 SP.
Forecast: 62 / 20 ≈ 3.1 → ~3–4 sprints (a range, not a point).
Anti-example: "Team A does 30 SP, B 20, A is better" — wrong, SP scales aren't comparable, not a KPI.
When to use
Story points/Fibonacci/poker for team backlog estimation; an anchor always; velocity for forecasting/trend, not people performance.
Quality checklist
- Estimate relative to an anchor, not in hours.
- Use Fibonacci (coarser on big = correct).
- Team estimate (poker), not one expert.
- Split big stories (≥13–21).
- Velocity = forecast/trend, not a KPI.
Pitfalls
SP = hours; anchoring on the senior; velocity as KPI; comparing team velocities; estimating giants (21+).