What Are Story Points? (And Why Your Velocity Isn't a Score)
Story points estimate how large a piece of work is relative to other work — not how many hours it takes. Like user stories, they aren't in the Scrum Guide at all. And the most common thing organisations do with them, comparing velocity between teams, is mathematically meaningless.
Story points are one of the most widely used practices in agile teams and one of the most reliably misunderstood — including by the managers who report on them. The confusion causes real harm: teams get compared on numbers that can't be compared, and people get judged by a measure that was never designed to judge anyone.
Why relative, and not just hours?
The reasoning is more practical than it first appears. People are genuinely poor at estimating absolute durations — ask how many hours a task will take and the answer is usually wrong, and confidently so. But people are surprisingly good at comparison. Asked whether this piece of work is bigger or smaller than that one, most teams agree quickly and are right often enough to plan with.
Relative estimates also survive changes that break hour-based ones. If the team gets faster, the work doesn't become smaller — a five-point item is still five points, the team simply completes more points per Sprint. Estimates in hours would have to be redone every time the team improved.
Why the odd numbers?
Most teams estimate using a Fibonacci-like sequence — 1, 2, 3, 5, 8, 13, 21 — and rarely stop to ask why the gaps widen. The reason is a real principle from psychophysics, Weber's Law: we perceive differences proportionally, not absolutely.
Concretely, a team can meaningfully argue about whether something is a 2 or a 3. Nobody can meaningfully argue whether it's a 20 or a 21 — the distinction is beyond what anyone can perceive at that size. Widening gaps force the scale to stop offering precision it can't deliver, which is exactly right for a large item nobody yet understands well.
They aren't part of Scrum
This is the same situation as user stories, which also come from outside Scrum — we cover that in what is a user story. The practical consequence is the same too: nobody can tell you that your team is "doing Scrum wrong" for estimating differently, or for not estimating in points at all. It also matters for certification exams, which test the Guide rather than adopted practice.
Velocity: what it's actually for
Velocity is simply the number of points a team completes in a Sprint, averaged over recent Sprints. Its legitimate purpose is narrow and useful: it helps the team forecast how much they can plausibly take on next Sprint, and helps a Product Owner sketch roughly when a chunk of backlog might be done.
That's the whole job. It's a planning aid for the team that produced it, and it stops being meaningful the moment it leaves that context.
The three ways it goes wrong
Each of these is common, and each does damage — the first most of all.
| Misuse | Why it fails |
|---|---|
| Comparing teams | Each team calibrates its own scale — the units aren't the same quantity |
| Treating it as productivity | Points measure size, not value delivered or work done well |
| Setting it as a target | Estimates inflate to meet the number, and the forecast stops working |
The first deserves spelling out because it's so widespread. Team A's five points and Team B's five points are not the same quantity — each team built its scale from its own reference item, independently. Comparing them is like comparing two rulers where each team decided privately how long a centimetre is. The numbers look comparable and aren't.
What to do instead
- Judge a Sprint by whether the Sprint Goal was met, not by points completed
- Use velocity as a range for forecasting, never as a score or a commitment
- If leadership wants a productivity measure, offer outcome measures — cycle time, delivered value, defect rates — rather than a scale the team defined itself
- Consider skipping points entirely: some teams simply right-size items so each fits comfortably in a Sprint, then count items
- Re-estimate the scale, not the team, when velocity moves oddly — a big shift usually means the reference item drifted
Who estimates?
The people who will do the work. The Scrum Guide is clear that sizing belongs to the Developers, with the Product Owner able to influence by helping them understand trade-offs — but not to set the numbers. A Product Owner or manager who assigns point values has removed the only thing that made the estimate informative, which is the judgement of the people doing it. See what a Product Owner actually does.
For how estimates fit into the wider mechanics, see what a product backlog is — where refinement and sizing happen — and what a Sprint is, which explains why finishing every item matters less than meeting the goal.
Frequently asked questions
What is a story point equal to in hours?
Nothing fixed — that's the point of them. Story points measure size relative to other work the team understands, not duration. Converting them to hours reintroduces the absolute estimates they were designed to avoid, and the conversion breaks as soon as the team's pace changes.
Are story points part of Scrum?
No. The Scrum Guide never mentions them and prescribes no estimation technique. It requires that backlog items be sized by the Developers who will do the work, but leaves the method to the team. Story points are an adopted practice, like user stories — see what is a user story.
Why do teams use the Fibonacci sequence?
Because we perceive differences proportionally rather than absolutely — Weber's Law. A team can meaningfully debate whether something is a 2 or a 3, but nobody can distinguish a 20 from a 21. Widening gaps stop the scale offering precision it can't actually deliver.
Can you compare velocity between teams?
No, and it's one of the most damaging things organisations do with it. Each team builds its scale from its own reference item, so one team's five points and another's are not the same quantity. Comparing them also encourages estimate inflation, which destroys velocity's only real use — forecasting.