↓ Skip to main content
eval ( code )
  1. Dev Handbook/
  2. 🥁 Rituals: Not Every Team Needs Every Meeting/

⚖️ Estimating: Measuring Risk, Not Time

5 mins
Table of Contents

When you need this
#

  • The team consistently misses delivery expectations and nobody can explain why.
  • Stakeholders are asking “when will this be done?” and the team has no framework for answering.
  • Some tickets take dramatically longer than expected, and there’s no conversation happening beforehand about complexity or risk.
  • The team is new to working together and doesn’t yet have a shared sense of what “this is a big one” means.

If your team is reliably delivering on time without formal estimation, you may not need this. Estimation is a calibration tool, not a requirement.

What estimation is (and isn’t)
#

Estimation measures risk, not hours. A “3” doesn’t mean “three days of work.” It means “this is unfamiliar, there are unknowns, and if our first approach doesn’t pan out we could be back to the drawing board.” The number captures how confident the team is, not how long they think it’ll take.

This distinction matters because time-based estimates invite micromanagement. If you say “this will take 3 days” and it takes 5, someone wants to know what went wrong. If you say “this is high risk” and it takes longer than expected, the team already agreed that was possible. The conversation shifts from blame to learning.

For the philosophy of how estimation connects to delivery expectations and how to communicate estimates to product, see the Estimation section in From Problem to Feature.

The pointing scale
#

The point estimate for a story is between 0 and 3. These values assess the risk involved, with 0 being the absolute lowest and 3 being the highest.

  • 0 - Copy changes, absolute no-brainer items.
  • 1 - Straight-forward change. The approach is known and comfortable to the developer.
  • 2 - Straight-forward with a small set of approaches available. If the first option doesn’t work out, another has to be tried.
  • 3 - Unfamiliar and risky. If an idea doesn’t pan out, it could be back to the drawing board to figure out other options.

Why 0-3 instead of Fibonacci or t-shirt sizing?
#

A small scale forces precision. With Fibonacci (1, 2, 3, 5, 8, 13), teams tend to cluster everything in the 3-5 range and the higher numbers become meaningless. T-shirt sizing (S, M, L, XL) is even vaguer. A 0-3 scale gives you just four options, which means every number has a distinct meaning and disagreements are easier to resolve.

Avoid using 0As a general rule, avoid estimates of 0 except in the most trivial cases. If a story is truly a 0, it’s probably too granular to be its own ticket. Frequent 0s also distort team velocity, making it look like the team is completing more work than they actually are.

How to run a pointing session
#

1. Read the ticket aloud
#

The team lead or facilitator reads the ticket. Everyone should understand the problem, the acceptance criteria, and any relevant context before pointing. If someone has a question, answer it now. Pointing a ticket nobody understands is a waste of time.

2. Everyone points at once
#

This is critical. On a count of three, everyone holds up their number simultaneously. If people point sequentially, the first person’s estimate anchors everyone else. You want independent assessments, not groupthink.

For remote teams, use a tool that hides votes until everyone has submitted, or simply count down and have everyone type their number in chat at the same time.

3. Discuss the outliers
#

If everyone points a 1 and one person points a 3, don’t just average it. Ask the 3 why. They may know something the rest of the team doesn’t (a hidden dependency, a past experience with a similar problem, a piece of the codebase that’s harder to change than it looks). Equally, ask the 1s why they’re confident. The conversation is where the real value is, not the number.

4. Re-point if needed
#

After discussion, if the team’s understanding has changed, point again. Usually one round of discussion is enough to converge. If the team still can’t agree after two rounds, go with the higher number. Optimism is the enemy of accurate estimation.

Point the ticket, not the personA common mistake is estimating based on who you think will pick up the ticket. “Well if Sarah does it, it’s a 1, but if I do it, it’s a 3.” Always estimate as if an average team member is doing the work. If you point based on the best person for the job, your estimates only hold if that specific person is available, which they won’t always be.

Common problems
#

Everything is a 2. If the team is pointing 2 on every ticket, the scale has lost its meaning. This usually means tickets are all roughly the same size (which could mean they’re well-scoped) or the team isn’t thinking critically about risk. Push back occasionally: “What would make this a 3? What would make this a 1?”

Estimates don’t match reality. If tickets estimated as 1 consistently take as long as tickets estimated as 3, the team’s calibration is off. Use retros to discuss which estimates were accurate and which weren’t. Over time, the team develops a shared sense of what each number means.

People treat estimates as commitments. An estimate is a confidence signal, not a deadline. If a 2 takes longer than expected, that’s useful information for next time, not a failure. The moment estimates become commitments, people start inflating them defensively and the whole system loses value.

The pointing session takes too long. If you’re spending 10 minutes on a single ticket, the ticket probably isn’t ready to be estimated. It needs more refinement. A well-written ticket with clear acceptance criteria should take under 2 minutes to point.