Story Points and Estimation

Story points are agile's answer to 'how long will it take?': relative units of effort, complexity and uncertainty, assigned by the team that will do the work. They exist because humans estimate comparatively better than absolutely — and because the honest answer to most software estimates is a range, not a date.

What It Is

A story point is a relative sizing unit — typically a simplified scale (1, 2, 3, 5, 8, 13...) — expressing the combined effort, complexity and risk of a story compared to a reference story. Teams estimate together (planning poker being the ritual: independent estimates revealed simultaneously, divergence discussed). Points are deliberately not hours: they resist the false precision of calendar conversion and absorb the reality that different team members work at different speeds. Velocity — points completed per sprint — converts estimates into forecasts: a 200-point backlog running at 25 points per sprint forecasts roughly eight sprints, always as a range with confidence attached.

Why It Matters to You

Two executive disciplines make estimation useful rather than fictional. First, treat all software dates as probability distributions: a team giving a '90% confident' date and a '50% confident' date is being honest; one giving a single date is telling you what you want to hear. Second, never compare teams by velocity — points are calibrated per team and inflation follows pressure like a law of physics. Estimates improve as work is decomposed; the reliable forecast horizon in software is short, and plans should be confident near and directional far.

When You'll Meet It

In sprint planning, release forecasting, and any commitment negotiation. Ask for ranges and confidence, not dates — and be suspicious of any long-horizon software date offered without them.