Story Points

Story points are a unit of relative estimation used to express how large a piece of work is compared with other pieces, rather than how long it will take in hours or days. A team assigns points by comparison against reference items they have already completed, and the accumulated points delivered per iteration provide a basis for forecasting how much future work will fit.

The abstraction exists because people estimate relative size more reliably than absolute duration. Asked how long something will take, estimators anchor on optimistic assumptions, omit interruption and rework, and produce figures consistently biased downward. Asked whether one item is larger than another, the same people are considerably more accurate. Points exploit that asymmetry by capturing comparison and letting observed throughput supply the conversion to time.

Points are intended to reflect a combination of volume, complexity, and uncertainty rather than effort alone. A small change to unfamiliar code with unclear requirements may be larger than an extensive change to a well-understood area. Teams that reduce points to a proxy for hours lose this dimension and reproduce the estimation problems the technique was designed to avoid.

The measure is local by construction, which is the property most frequently violated in practice. Points are calibrated against a particular team's reference items and reflect that team's context, codebase, and composition. Comparing point totals between teams is therefore meaningless, and using velocity as a productivity measure across teams reliably produces estimate inflation, since the incentive is to score the same work higher.

The same distortion appears within a team when velocity becomes a target. A team asked to increase velocity can do so immediately by estimating more generously, and the number improves while nothing changes. Because the metric is trivially manipulable and was designed as a planning aid rather than a performance measure, its use in performance reporting destroys its usefulness for its actual purpose.

Estimation carries a real cost that deserves scrutiny. Refinement and planning sessions consume substantial team time, and for work with a reasonably consistent size distribution the forecasting benefit over simply counting items is small. Teams practising no-estimates approaches count completed items and forecast from historical throughput, which is frequently as accurate and considerably cheaper. Whether estimation earns its cost is a legitimate question rather than a heresy.

Recalibration is necessary whenever the reference items stop being representative, which happens as a codebase matures, as a team's composition changes, or as the nature of the work shifts. Teams that carry an original scale forward for years find that their points describe a context that no longer exists, and the resulting forecasts drift without anyone identifying the cause.

Where points remain useful is in surfacing disagreement during estimation. When team members assign very different values to the same item, the discussion that follows usually reveals that they understood the requirement differently, or that one person is aware of a complication the others are not. That conversation is frequently worth more than the resulting number, which is an argument for keeping the discussion and being pragmatic about the arithmetic.

Because the technique only functions as a planning aid within one team, its value depends entirely on how the surrounding organization uses the output. In practice estimation practice is settled within product development, and where several teams work on one product the coordination is better handled through dependency management and flow measurement across a product department than through attempts to normalize estimates between teams.