What are story points? Estimating effort, not time

Story points measure the relative effort, complexity and uncertainty of work — not hours. How to size against a reference story, and the questions that trip teams up.

Story points measure the relative effort of a piece of work — its size, complexity and uncertainty rolled into one number — not the hours it will take. You size a backlog item against a reference story the team already shipped (“this is about twice that one”) instead of guessing a duration. That single shift is what lets the estimate survive contact with reality.

Why measure effort, not time

A team that estimates in hours is really carrying two estimates: the one the senior engineer believes, and the one the junior engineer writes down after rounding up to look responsible. People are unreliable at “how long will this take” and surprisingly good at “is this bigger than the thing we finished last sprint.” Story points lean on the second.

Relative sizing lets the team agree that one item is larger than another without anyone committing to a number of hours — which sidesteps the anchoring and seniority bias that hour estimates invite. The number that comes out isn’t a duration; it’s a position on a shared scale.

The scale, and what points are for

Most teams vote on a Fibonacci-style scale — 1, 2, 3, 5, 8, 13 — in a round of planning poker. The gaps widen on purpose: the bigger the work, the less anyone really knows, so the scale stops pretending you can tell a 9 from a 10. Add up the points a team finishes each sprint and you get velocity — the one forecasting input points are actually meant to produce.

The single biggest failure mode is the team that starts converting points back into hours. The moment that conversion table goes on the wiki, every estimation conversation collapses into a duration argument and the relative-effort property is gone.

Which work should you point?

Two questions come up in every refinement meeting: does this even get points, and if so, how many. The “how many” is what the scale is for. The “does it” has a rule of thumb — point anything the team ships as part of its committed work, so the velocity signal reflects where capacity actually goes.

Bugs

A bug with a known cause and a clear fix is a story. It has acceptance criteria (“the form no longer accepts negative quantities”), a defined scope and a reasonable size — so vote it like any other story. Bug work and feature work compete for the same capacity, and velocity should show that.

The exception is the bug whose nature is “we don’t know what’s in there yet” — investigate the data corruption, figure out why p99 doubled, customers keep reporting it and we can’t reproduce it. The fix isn’t sized because the cause isn’t known, so a story-point vote just measures what the team hopes to find. Put those on a time-boxed investigation track: spend a day or two looking, then come back with a real story for whatever you found.

Testing and QA

Story points size the work between “story enters the sprint” and “story is shippable” — which includes whatever QA the team does as part of done: automated tests, manual verification, accessibility checks, security review. The story isn’t done when the PR merges; it’s done when it meets the definition of done.

Teams that point dev-only work and bolt QA on separately overcommit every sprint, because QA is the bottleneck nobody sized. If a separate QA team owns the testing, the story still carries the dev-side cost of working with them — preparing the build, writing the test plan, fielding questions. That part isn’t free, so it stays in the estimate.

Why you rarely want a 1-point story

Points are relative, so a 1 is only meaningful next to a 2, a 3, an 8. When a team has a steady stream of 1-point stories, that gradient is gone — everything tiny is a 1, everything bigger is a 2 or 3, and the scale has collapsed to a coin flip.

The fix isn’t to ban 1s — that’s the cargo-cult version of the rule. It’s to ask why so much work is sizing at the bottom. Usually the reference story has drifted: the team got faster, and the original “1” is now smaller than anything they ship, so pick a newer reference the team remembers and re-anchor. Sometimes the team is over-decomposing in refinement, pulling every acceptance criterion out as its own story — “update the button text” isn’t a story, it’s an acceptance criterion on a bigger one. And sometimes the work genuinely is small (a maintenance quarter, a copy change that needs legal review, a config tweak that touches production), in which case points are doing their job and there’s nothing to fix.

The signal to watch isn’t “no 1s ever.” It’s 1s making up most of the backlog. One or two per sprint is fine. Every other story a 1 means the calibration question hasn’t been asked in too long.

Frequently asked questions

What are story points in agile?

Story points are a unit of relative estimation: one number that captures how big a piece of work is — its effort, complexity and uncertainty together — compared with a reference story the team has already delivered. They are deliberately not a measure of time. The team sizes each item against the others rather than against the clock.

Should bugs have story points?

Yes, when the bug has a known cause and a clear fix — it is a story like any other, and pointing it keeps velocity honest about where capacity goes. The exception is the exploratory bug you cannot yet scope; put that on a time-boxed investigation track and size the real fix once you know the cause.

Do story points include testing?

Yes. Points size everything between a story entering the sprint and it being shippable, which includes the testing and QA the team does as part of its definition of done. Point dev-only work and the sprint overruns every time, because QA is the bottleneck no one accounted for.

Why should you avoid 1-point stories?

A few are fine. But if most of the backlog is 1s, the team’s reference story has drifted and the scale has collapsed — everything reads as tiny-or-bigger. Recalibrate against a recent reference story rather than shrinking the scale.