How to Calibrate Your Team's Estimation Scale

A team's first estimation session produces numbers that don't mean much. Calibration turns those numbers into a shared language - and keeps them meaningful as the team evolves.

Start with a reference story

Choose one story from your backlog that everyone understands well. It should be genuinely medium-sized - not trivial, not huge. Call this your "3" (or "5" if you use Fibonacci). Every other story is estimated relative to this one.

Write the reference story on the wall (physical or virtual) and leave it visible during estimation sessions.

Use your reference story in the first few sessions

When a new story comes up, ask: "Is this more or less complex than our reference?" This anchors estimation to real work rather than abstract numbers.

After a few sessions, most teams internalize the scale and stop needing the reference for every vote.

Re-calibrate when the team changes

When developers join or leave, your scale can drift. New members bring different intuitions about what "hard" means. Run a short calibration exercise at the start of the first sprint: show 5-6 historical stories with their point values and ask if they still feel right.

Re-calibrate when the codebase changes significantly

A major refactor, a platform migration, or moving into a new area of the codebase can shift what "hard" means. What used to be a 3 in the old payment system might be an 8 in the new infrastructure. Acknowledge this explicitly rather than letting estimates drift silently.

Signs your scale has drifted

• Stories marked "8" finishing in an afternoon
• "3" stories consistently spilling into the next sprint
• Wide disagreement on stories the team used to estimate quickly

Any of these is a prompt to revisit calibration rather than just shrugging off variance.

Calibration isn't a one-time activity. It's an ongoing practice that keeps your estimation scale meaningful as everything around it changes.