What Are Story Points?

Story points are an abstract unit used in agile and scrum teams to estimate the relative effort, complexity, and uncertainty involved in completing a user story or task. Unlike time-based estimates, a story point doesn't map to a specific number of hours — a 5-point story is simply understood to be roughly twice the effort of a 3-point story. The abstraction is intentional. It frees teams from the false precision of hour estimates and focuses discussion on complexity and risk instead.

Hour estimates sound precise but rarely are. They're optimistic by nature — developers consistently underestimate how long tasks take, especially when unknowns are involved. Hour estimates also vary by individual: a senior engineer might complete a task in 2 hours that takes a junior 6. Story points sidestep both problems. Teams estimate relative to each other — "this is about twice as hard as the last one" — rather than committing to a clock time. Individual productivity differences average out over time through velocity.

Most teams use a Fibonacci-like sequence for story points: 1, 2, 3, 5, 8, 13, 21. The growing gaps between numbers are deliberate. Small stories (1–3 points) can be estimated with reasonable precision. Larger stories (8–21 points) carry enough unknowns that pretending to distinguish between, say, 11 and 12 points would be false accuracy. The sequence forces an honest acknowledgement: the bigger the task, the less certain the estimate. A 21-point story is almost always a candidate for splitting.

Velocity is the number of story points a team completes in a sprint. Once a team has run several sprints, their velocity stabilises into a reliable range — say, 30–40 points per sprint. This makes sprint planning straightforward: if your velocity is 35 points and the next sprint's stories total 60 points, you know you're overcommitting. No estimation technique will ever be perfect, but velocity-based planning is consistently more accurate than hour-based planning.

• Treating points as hours — once a team starts saying "1 point = 1 hour" the whole system collapses. • Comparing velocity across teams — team A doing 50 points per sprint is not more productive than team B doing 30. Points are relative to each team's own calibration. • Never re-calibrating — if your reference stories drift (a "3" today is nothing like the "3" from six months ago), your velocity becomes meaningless. • Estimating too precisely — spending 20 minutes debating whether a story is a 5 or an 8 is a waste. If it's in that range, pick one and move on.

A story point only means something relative to other story points, so a team needs shared anchors. The usual approach is to pick two or three stories the team has already finished and agree what they were worth in hindsight — a small one everyone remembers as straightforward, and a medium one that had some genuine complexity. Write those down where the team can see them during estimation. When a new story comes up, the question stops being "how big is this in the abstract" and becomes "is this more or less work than the login form we called a 3?" That comparison is far easier to answer consistently, and it is what keeps velocity meaningful across sprints. Re-check the anchors every few months. Teams get faster, tooling improves, and a story that was a genuine 5 last year may be a 2 now. If you never recalibrate, your velocity will drift upward for reasons that have nothing to do with productivity.

Anything the team sizes at 13 or above is usually telling you the story is not understood well enough to start. The fix is to split it — but split it in a way that still delivers something end to end, rather than into horizontal layers that individually ship nothing. • By workflow step — take the happy path first, then the error and edge cases as separate stories. • By business rule — implement the common case, then the exceptions and special pricing later. • By data variation — support one file format, one currency, or one region, then add the rest. • By interface — deliver the API and a crude UI first, then the polished interaction. • By effort — spike the unknown part in a timeboxed investigation, then estimate the real work with what you learned. A useful smell test: if a split story cannot be demonstrated to someone at the end of the sprint, it is probably a task rather than a story, and the split has gone horizontal.

A team with no history has no anchors and no velocity, so the first few sessions will feel arbitrary. That is expected and not a problem — the numbers are not wrong, they are simply uncalibrated. Estimate anyway, note what you assumed, and compare against reality at the end of the sprint. Expect velocity to be unstable for roughly three to five sprints before it settles into a range. Resist the urge to set a target during that period: a team told to hit 40 points will reliably produce 40 points' worth of estimates, which destroys the signal you were trying to build. If a new team struggles with abstract numbers, start with T-shirt sizes for a few sprints and convert to points once relative sizing feels natural. The mental model matters more than the units.

Story points assume the constraint is human effort. When a developer spends most of a task directing an AI agent rather than writing the code themselves, that assumption gets shakier — the wall-clock time can collapse while the complexity and review burden stay exactly where they were. Most teams handle this by keeping points as a measure of complexity and risk rather than duration, which is what they were always supposed to be. Others find it more honest to size the compute directly. Both work; what does not work is leaving the definition ambiguous so half the team estimates effort and the other half estimates elapsed time.