The Software Wiki

Estimation

Properties3
descriptionForecasting the relative size of work so a team can plan and predict, using techniques like story points and planning poker, or, in the other camp, avoiding per-item estimates entirely.
tagsprocess, concept
aliasesAgile estimation, Effort estimation, Relative estimation, Software estimation, Story point estimation, Sizing

8 min read

Estimation

By Allen Jay Bercero

Estimation in agile software development is forecasting the relative size of work, so a team can plan a Sprint, order a Product backlog, and predict roughly when things will be done. The point is a good-enough forecast, not an exact time prediction. Humans are bad at guessing how long a task takes in hours, but much better at judging whether one task is bigger than another, so most agile estimation compares items against each other instead of clocking them.

That framing splits practitioners into two camps. One estimates the size of each item (story points, agreed via planning poker) and forecasts from a team’s velocity. The other argues that per-item estimation is wasted effort and instead slices work small and uniform, then forecasts by counting finished items (throughput, the #NoEstimates position). This article covers both.

Also known as

agile estimation · effort estimation · relative estimation · “sizing” · story-point estimation · “pointing” (a story)

Don't confuse with

  • An estimate vs a commitment vs a deadline. An estimate is a probabilistic forecast (“about this big”). A commitment is a promise, and a deadline is a date. Treating an estimate as a promise is the single most common way estimation goes wrong.
  • Story points (relative size) vs hours (absolute duration). Converting points back into hours throws away the reason points exist. See below.
  • Estimation vs #NoEstimates (covered below). The latter is not a technique but a critique of estimating at all.

Why relative, not hours

Absolute time estimates (“this will take 6 hours”) are notoriously unreliable: they ignore interruptions, unknowns, and who ends up doing the work, and they invite treating the number as a promise. Relative estimation sidesteps this. Instead of asking how long, you ask how big is this compared to that. A team can consistently say “this item is about twice the size of that one” even when it can’t say how many hours either will take.

A relative estimate bundles three things into one number:

  • Effort: how much work it is.
  • Complexity: how hard or intricate it is.
  • Uncertainty / risk: how many unknowns it carries.

A gnarly, unfamiliar task is “big” even if the typing is small.

Story points

A story point is a unit of relative size assigned to a User story or backlog item. Points are meaningful only within a team: one team’s 5 is not comparable to another’s, because each team calibrates against its own past work. This is a feature, not a flaw. It stops points from being used as a cross-team productivity score.

Teams usually estimate on a modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20, 40, 100). It is modified because true Fibonacci runs 13, 21, 34, 55, and the scale rounds those upper values off; physical decks also add 0, ½, a ? for “no idea”, and ∞ for “too big to estimate.” The gaps widen deliberately: the bigger an item, the fuzzier the estimate, so offering “16 vs 17” would be false precision. If an item lands at 20 or higher, that is a signal to split it into smaller items during Backlog refinement.

In plain English

Don’t guess hours. Pick a reference item everyone knows and call it a “3.” Then size everything else against it: is this one about the same (3), half as much (1–2), or a lot more (8)? The number is a comparison, not a clock.

Planning poker

Planning poker is the most common way a team agrees on a story-point estimate. Each estimator holds cards showing the scale values. For each item:

  1. The item is read out and briefly discussed.
  2. Everyone privately picks a card and all reveal at the same time.
  3. If estimates differ widely, the highest and lowest explain their reasoning (they often know something the others don’t).
  4. The team re-votes until it converges.

Revealing simultaneously is the whole trick: it prevents anchoring, where the first number said out loud drags everyone else toward it. The discussion around disagreements is usually more valuable than the number itself, because it surfaces hidden assumptions and missing acceptance criteria.

Velocity: turning estimates into a forecast

Velocity is the number of story points a team completes in a Sprint, averaged over the last several sprints. It converts sizing into prediction: if a team averages 30 points per sprint and the remaining work is about 150 points, that is roughly five sprints. It is empirical, measured from real history, not assumed up front. See Sprint planning, where velocity guides how much the team pulls in.

Velocity is a planning aid, not a scoreboard

Velocity is not a productivity metric and cannot be compared between teams (their points aren’t the same unit). The moment velocity becomes a target, it stops measuring anything: teams inflate their estimates and the number goes up while nothing ships faster. This is Goodhart’s law: when a measure becomes a target, it ceases to be a good measure. Note too that the official Scrum Guide defines neither story points nor velocity; they are popular add-ons, not part of Scrum itself.

The other camp: throughput and #NoEstimates

Not everyone accepts that per-item estimation is worth doing. In a Kanban flow, forecasting leans on measured flow metrics instead of estimates:

  • Throughput: how many items finish per week (a raw count).
  • Cycle time: how long an item takes from start to done, read as a distribution (e.g. “85% of items finish within 9 days”), not an average.
  • Little’s law ties them together: average WIP = throughput × average cycle time.

From a throughput history you can run a Monte Carlo simulation (“how many of these will we finish in the next 4 weeks?”) without ever pointing an item. The catch, as noted in Kanban, is that throughput is size-blind, so this only works if items are kept small and similar.

#NoEstimates is the position, associated with practitioners like Woody Zuill, that per-item estimation is largely waste: slice work thin and uniform, count throughput, and skip the estimation ritual. The trade-off is real. Counting forecasts ongoing flow well, but it answers “how much will this whole fixed-scope, fixed-budget project cost?” less directly than a sized backlog, which is often what a business wants up front.

Other estimation techniques

Planning poker is slow for a large backlog. For coarse or early sizing, teams use faster methods:

  • T-shirt sizing: classify items as S / M / L / XL. Deliberately vague, good for early roadmap-level sizing before details exist.
  • Affinity estimation: silently sort a big pile of items into size groups on a wall, fast, then discuss only the disputed ones. Can size dozens of items in an hour.
  • Bucket system: like affinity estimation but into predefined numeric “buckets.”
  • Dot voting: used less for size and more for prioritizing which items to pull.

Common pitfalls

  • Estimates used as commitments. A forecast becomes a broken promise the moment someone treats “about 8” as “done by Friday, guaranteed.”
  • Converting points to hours. Doing this reintroduces exactly the false precision relative sizing was meant to escape.
  • Velocity as a target or a cross-team KPI. Causes point inflation and kills the metric (Goodhart’s law).
  • Anchoring. Saying a number out loud before everyone votes biases the room; this is why planning poker reveals simultaneously.
  • Over-investing in precision. Past a point, more estimation effort buys almost no accuracy. The map is not the territory.

See also

References

Graph View

Recent Notes

Backlinks