Estimation Rituals
Planning poker, t-shirt sizing, and reference stories. The room outlier is the whole point. The number is a side effect of the conversation, not the goal.
Planning poker procedure
The senior engineer states their estimate first. The rest of the team says whether they agree.
Planning poker procedure
Each engineer picks a number privately. All numbers are revealed at once. The room discusses spreads, then re-estimates.
When the senior estimates first, the rest of the room rounds to that number. The disagreement that would have surfaced never does, and the team takes the implicit anchor into the sprint.
Independent estimates surface real disagreement. The reveal is the moment that lets the room see who saw what differently. Anchoring on one engineer's number first collapses the spread before it has a chance to inform anyone.
Who estimates
The team lead and the PM estimate together and bring the result to the team for confirmation.
Who estimates
Everyone who might do the work estimates: engineers, QA, design, on-call rotation. The PM brings the story; the team owns the number.
Pre-cooking the estimate excludes the people who carry the implementation cost. They will discover the missing scope mid-sprint and the team's trust in the planning ritual will degrade.
The number belongs to the people who do the work. Including QA, design, and on-call surfaces variations the dev-only estimate would miss. The PM's job is to bring the story; the team's job is to estimate it.
Output of pointing
Each story leaves with a number on it. Disagreements are averaged. The team moves on quickly.
Output of pointing
Each story leaves with a number, a one-line note on what made it that size, and any open questions for the next refinement.
A naked number tells the next reader nothing about the tradeoffs the room considered. When the story is pulled three sprints later, the team re-points it from scratch and the original disagreement reappears.
The number is a side effect; the conversation is the point. Capturing what made the size what it is plus the open questions means the next refinement starts with context, not from scratch.
Epic-level estimation
Each Epic in the next quarter gets a Fibonacci number (3, 5, 8, 13, 21).
Epic-level estimation
Each Epic in the next quarter gets a t-shirt size (S, M, L, XL). Stories inside the Epic get Fibonacci once they enter refinement.
Fibonacci numbers on Epics imply a precision the team does not have yet. The numbers will be wrong by 2x in either direction and stakeholders will treat them as commitments anyway.
T-shirt sizes match the precision available at the Epic stage: rough relative size for roadmap planning. Fibonacci comes in once the work is concrete enough to estimate against reference stories.
What gets pointed
Every backlog item including bug tickets, copy tweaks, and config changes is pointed at refinement.
What gets pointed
Stories and bigger Tasks are pointed. Tiny chores (copy tweaks, single-line config) ride along as no-point or 1-point items, capped per sprint.
Pointing a copy tweak as a 1 inflates velocity without telling you anything. Multiply it across 30 chores a sprint and the velocity number becomes unrelated to the size of real work.
Pointing every two-minute change costs more than the change. The right side reserves the ritual for work where the conversation matters and lets small chores ride along on a cap so velocity stays meaningful.