Two sticky-note characters standing back to back to compare their heights against a mark on the wall, pleased to have settled which is bigger.

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.

Sizing in effort rather than hours sidesteps three problems that dog hour-based estimates:

  • An estimate is not a commitment. Hours invite stakeholders to treat “8 hours” as a promise; points keep the estimate a forecast.
  • The same task takes different people different times. A point reflects the work, not the person.
  • Duration ignores risk. A short but uncertain task can be riskier than a long, well-understood one, so points fold that uncertainty in.

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.

A Fibonacci story-point scale from 1 to 20 whose gaps widen as the numbers grow The same scale, coarser at the top on purpose 1 2 3 5 8 13 20 Fine-grained: teams can tell these apart Coarse on purpose: less is knowable
The scale is fine-grained where teams can tell items apart and coarse where they can’t. A 5 versus an 8 is a real argument; a 19 versus a 20 is noise.

If an item comes out larger than about a 13, that is usually the scale telling you to split it into pieces the team can understand and finish inside a single sprint.

For a faster, rougher first pass, some teams size the whole backlog in t-shirt sizes and convert only the near-term work to points once it is refined.

In a round of planning poker, everyone reveals their card at the same time, so nobody anchors on the loudest or most senior voice. Where the high and low estimates diverge, those two people explain their reasoning, and that conversation, which surfaces the assumptions and hidden complexity behind the number, is usually worth more than the number itself. The full planning poker walkthrough covers the mechanics.

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.

Story points and the retrospective

Estimation is one of the most common things a team inspects in its sprint retrospective. When items are routinely under- or over-estimated, when velocity swings wildly, or when “done” work keeps reopening, the retrospective is where the team recalibrates its shared sense of size and tightens how it slices work. Estimation accuracy improves through that feedback loop, not by trying harder up front.

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.

Why use story points instead of hours?

People are poor at estimating absolute time but good at judging whether one thing is bigger than another, and story points lean on that strength. They also avoid the trap of treating an estimate as a commitment, account for the fact that the same task takes different people different amounts of time, and fold in complexity and risk, not just duration. Over a few sprints, a team’s velocity in points becomes a more reliable forecast than summing hour estimates.

How do you estimate story points?

Most teams use planning poker. Someone explains a backlog item, the team discusses it, and everyone privately picks a value from a shared scale, usually a Fibonacci-like sequence (1, 2, 3, 5, 8, 13). Everyone reveals at once; where estimates differ widely, the high and low voters explain their thinking and the team re-votes until it converges. The discussion that surfaces hidden complexity is often more valuable than the number itself.

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, so everything reads as tiny-or-bigger. Recalibrate against a recent reference story rather than shrinking the scale.

Can you compare story points between teams?

No. A story point is calibrated to one team’s own sense of relative size, so one team’s 5 is not another team’s 5. Comparing velocity or point totals across teams is meaningless and, used as a target, actively harmful: it pushes teams to inflate estimates. Story points are a planning tool for a single team’s own forecasting, not a productivity metric for comparison.