Flocci Projects

Home › Agile answers › How do I estimate story points consistently across a team?

How do I estimate story points consistently across a team?

Consistency comes from reference stories, not discipline. Pick two or three already-delivered stories and fix them as your 1, 3 and 8. Estimate every new story by comparing it to those anchors rather than to a feeling, and re-anchor once a quarter as the team's capability changes.

Step by step

  1. Choose your anchors. Pick three completed stories everyone remembers and agree they are a 1, a 3 and an 8. Write them somewhere visible — a Library wiki page works — because an anchor nobody can recall is not an anchor.
  2. Estimate by comparison. For each new story ask only 'is this bigger or smaller than the 3?', then narrow. Never start by imagining hours; that reintroduces the bias points exist to remove.
  3. Reveal simultaneously. Everyone commits a number before anyone speaks. Sequential estimation collapses into anchoring on whoever spoke first, usually the loudest or most senior person.
  4. Discuss only outliers. If the spread is 2 to 8, ask both ends what they know. The gap is almost always hidden scope or hidden risk — that conversation is the actual value of the session.
  5. Split anything above 8. A 13 is a signal, not an estimate. Split it into vertical slices that each deliver something demoable, and re-estimate the pieces.
  6. Re-anchor quarterly. As the team gets faster the old 3 starts feeling like a 1. Re-pick anchors every quarter and accept that velocity numbers before and after are not directly comparable.

Why teams drift

Estimation drifts because the scale is implicit and lives in individual memory. Two months in, one person's 5 is another's 3, velocity gets noisy, and the team concludes points do not work. The failure is not the unit; it is the missing shared reference.

The three-anchor method

Fix a 1, a 3 and an 8 from work you have actually delivered, and estimate by comparison against them. New joiners can be calibrated in ten minutes by reading three stories, which is far cheaper than absorbing a scale by osmosis over two months of planning meetings.

What to do about unknowns

If a story cannot be estimated because nobody understands the problem, do not guess a number — create a timeboxed spike (a fixed-length investigation) and estimate the real story afterwards. Points measure size, not ignorance, and a guessed 8 poisons the velocity average for months.

Try it on a free Flocci Projects board

Related questions

Should new team members estimate from day one?

Let them vote but weight the discussion toward experienced members for the first few sessions. Their outlier votes are still useful — a newcomer's high estimate often reveals genuine complexity the team has stopped noticing.

What if the team keeps under-estimating?

That is normal and self-correcting through velocity, provided you plan against velocity rather than against the estimate total. Chronic under-estimation shows up as velocity below committed points every sprint; the fix is committing less, not estimating higher.

Do we need to re-estimate stories that carry over?

No. Re-estimating carry-over work double-counts effort and inflates velocity. The story keeps its original points and they count in the sprint where it finishes.

More agile answers