Getting Better Story Point Estimates

Close

Teams get better story point estimates by improving the conversations that produce them.

The estimate is the visible output. The useful work is noticing assumptions, comparing against known items, discussing disagreement, and learning from surprises. A team that does those things well can create estimates that are accurate enough to support planning and prioritization without spending too much time estimating.

The goal is useful estimates, not perfect ones.

Start with the Decision

Before estimating, ask what decision the estimate will support.

A Product Owner may need to decide whether a feature is worth doing. A stakeholder may need to decide whether a date is plausible. A team may need to decide whether an item is small enough to consider for an upcoming sprint.

Different decisions require different levels of accuracy.

A rough estimate may be fine when the Product Owner is comparing two large options. A more careful estimate may be needed when an item is near the top of the product backlog. A large uncertain estimate may be enough to show that the team should split the item or learn more.

Estimating gets wasteful when the team estimates more precisely than the decision requires.

Estimate by Analogy

Analogy is stronger when the team can name the comparison. "This feels like a five" is less useful than, "This feels like the account-settings change we estimated as a five because it has a similar amount of testing and a similar integration risk." The named comparison gives the team something to challenge or confirm.

Story point estimates improve when teams compare a new product backlog item with items they have already estimated or completed.

Estimating by analogy means asking, “What have we done before that this item resembles?” Instead of trying to build an estimate from parts, the team compares the new product backlog item with familiar items.

Ask questions such as:

  • Is this item more like the two-point item or the five-point item?
  • What makes it larger than that previous item?
  • What uncertainty would push it higher?
  • What could make it smaller?
  • Have we done something similar before?

Analogy keeps the discussion grounded. It also helps the team avoid drifting back into time estimates.

When someone says, "This will take a week," redirect gently: "What item does it feel similar to?" That question moves the team back to relative effort.

Triangulate Against Several Items

Triangulation means comparing a new product backlog item with several previously estimated items.

A team might compare a new item with:

  • A completed two-point item
  • A completed five-point item
  • A larger item that was estimated at thirteen
  • A recent item that turned out to be harder than expected

The team is looking for consistency. If the new item is clearly smaller than a known eight and larger than a known three, the useful range may be five. If the new item has similar work but more uncertainty, the team may choose the next larger bucket.

Triangulation is one of the easiest ways to improve estimates because it reduces isolated guessing.

Discuss Disagreement Before Converging

When estimators disagree, pause long enough to learn why.

A high estimate may reveal hidden testing, deployment risk, integration complexity, or missing information. A low estimate may reveal a simpler path, reusable code, or a narrower interpretation of the item.

Teams sometimes rush through disagreement because they want to be efficient. That can be false economy. A few minutes of discussion may prevent a bad estimate, a misunderstood scope decision, or a surprise in the sprint.

Focus the discussion on the reason for the difference, not on persuading someone to give up a number.

When the reasons are understood, the team can choose an estimate everyone can support.

Avoid Averaging Away Information

Averaging can be useful in some statistical contexts, but it often weakens team estimation.

If one person estimates three and another estimates thirteen, the average does not explain why. The high estimate may be based on an important risk. The low estimate may be based on an assumption that changes the scope. The team needs that information before choosing a number.

If the team is stuck, ask:

  • What would have to be true for this to be a three?
  • What would have to be true for this to be a thirteen?
  • Which assumptions are we comfortable making?
  • Is the item really one item, or should it be split?

The estimate should come after the important information has surfaced.

Treat Estimate Values as Buckets

Think of a story point value as a bucket.

A five-point item is not exactly five units of effort in a mathematical sense. It belongs in the same approximate bucket as other items the team calls five.

This matters because teams can waste a lot of time looking for a perfect number. They may debate whether an item is really a five or an eight when either number would support the same decision.

Ask whether the decision changes. If the Product Owner would prioritize the item the same way whether it is five or eight, the team probably does not need a long debate.

If the decision changes, discuss further.

Learn from Estimating Surprises

Teams improve by reviewing surprises.

After an item is done, occasionally ask:

  • Was the estimate useful?
  • What did we miss?
  • Did the item include hidden work?
  • Did uncertainty turn into real effort?
  • Was the item larger because it should have been split?
  • Would our baseline items have helped us estimate it better?

Do this selectively. The team does not need a formal postmortem on every estimate. Look at items that were dramatically easier or harder than expected.

The goal is learning, not blame.

A team that reviews surprises becomes better at noticing the same signals earlier next time.

Refine the Product Backlog Item Before Estimating

Sometimes the best way to improve an estimate is to refine the product backlog item.

If the team cannot tell what must be true for the item to be considered complete, the estimate will be weak. If the item contains multiple user goals, it may be too large. If the Product Owner has not decided what matters most, the team may estimate options that will never be built.

Before estimating, ask:

  • What outcome does the Product Owner want?
  • What is included and excluded?
  • What assumptions are we making?
  • What risks or unknowns matter?
  • Is the item small enough to compare with previous items?

A clearer item usually leads to a better estimate.

Know When Not to Estimate

A team does not need to estimate every item immediately.

Do not estimate when no one will act on the estimate. Do not estimate far-future items in detail if the Product Owner will not make a decision based on the number. Do not estimate unclear items as if a number will make them clear.

Estimate just enough, just in time, for the decisions the team and Product Owner need to make.

This advice works in both directions. Avoid estimating so far ahead that the estimate changes nothing. Also avoid waiting until Sprint Planning if the Product Owner needed the estimate earlier for prioritization.

Use Ranges When Uncertainty Is High

Sometimes a single story point estimate suggests more confidence than the team actually has.

If a product backlog item might be an eight or might be a twenty, that range is useful information. The Product Owner may decide to split the item, learn more, change priority, or accept the uncertainty because the decision only requires a rough sense of size.

Ranges should not become an excuse to avoid decisions forever. But they can be more honest than forcing a single number too early.

A useful follow-up question is: "What would we need to learn for this estimate to become a narrower range?"

Keep a Short List of Repeated Surprises

Teams often make the same estimating mistakes repeatedly.

They forget data migration. They underestimate testing across browsers. They miss accessibility work. They underestimate the time needed to coordinate with another team. They assume a third-party API will work as advertised.

A short list of repeated surprises can improve future estimates. It does not need to be formal. The team can keep a simple checklist and glance at it before estimating larger or riskier items.

The goal is not bureaucracy. The goal is to stop being surprised by the same things.

Separate Accuracy from Blame

Teams improve estimates when they can talk honestly about what happened.

If every missed estimate becomes a blame conversation, people will protect themselves. They will inflate estimates, resist estimating, or hide uncertainty.

A healthier review asks:

  • What did we know when we estimated?
  • What did we learn later?
  • What assumption was wrong?
  • What kind of work did we forget?
  • Would a baseline, spike, split, or clearer acceptance criteria have helped?

The purpose of reviewing estimates is to improve future decisions, not to make the past look tidy.

Improve Facilitation, Not Just Numbers

Many estimation problems are facilitation problems.

A good facilitator helps the team slow down when assumptions are hidden and speed up when the estimate is good enough. Useful prompts include:

  • "What are we assuming?"
  • "What makes this larger than the three-point baseline?"
  • "What would push this into the next bucket?"
  • "What did the high estimate see that others missed?"
  • "What did the low estimate assume that may simplify the work?"
  • "Is this an estimating problem or a refinement problem?"

Better questions often produce better estimates than more elaborate estimation processes.

Spend Estimating Effort Where the Decision Matters

Not every product backlog item deserves the same estimating effort.

If the estimate will influence a near-term priority, milestone forecast, staffing decision, or scope tradeoff, spend enough time to make the estimate useful. If the item is low in the backlog and may never be built, a rough estimate may be enough or the team may choose not to estimate yet.

The goal is not to make every estimate equally good. The goal is to make estimates good enough for the decisions they support.

FAQ

How accurate should story point estimates be?

Accurate enough for the decision being made. Early prioritization may need only rough estimates. Near-term planning may need more discussion.

Should we re-estimate stories?

Sometimes. Re-estimate when the old estimate no longer supports the decision, such as after a major scope change, story splitting, or new information.

Should we track estimate accuracy?

Use caution. Reviewing surprises can help teams learn. Turning estimate accuracy into a performance measure can make teams inflate estimates or avoid honest discussion.

What should we do when one person will not budge?

Ask what concern is behind the estimate. If the concern is valid, address it. If the team has discussed it and still disagrees, choose an estimate the team can support or split the item.

How do we make estimates faster?

Use baselines, compare against previous items, timebox discussion, and defer items that need more information. Use a faster estimating technique when only rough estimates are needed.