What Are Story Points? Estimating Effort Without Hours

A story point is not an hour, a day, or a unit of anything measurable. It is a way of saying "this piece of work is about twice the size of that one" — and that turns out to be a much more reliable thing for humans to judge.

What a story point measures

A story point is a unit of relative effort assigned to a backlog item. It bundles three things that are hard to separate in practice:

• Volume — how much there simply is to do.
• Complexity — how intricate or interconnected the work is.
• Uncertainty — how much the team does not yet know.

Because all three are folded together, two stories can share a number for entirely different reasons. A migration that touches sixty files but holds no surprises and a single-function change against an API nobody has used before can both be 5s: one is large and known, the other small and unknown. The point value captures the cost of getting it to done, not the shape of the work.

Why not just estimate in hours?

Because people are bad at it, in a consistent and well-studied direction. Duration estimates are systematically optimistic: they capture the happy path and quietly omit code review, the flaky test, the afternoon lost to an incident, and the two days of waiting on someone else. Every engineer knows this and still does it.

Relative judgement holds up much better. "Is this bigger than that?" is a comparison people make accurately even when their absolute sense of scale is poor — the same reason you can tell which of two bags is heavier without knowing what either weighs.

The second problem with hours is social. An hours estimate sounds like a commitment, because it is expressed in the same unit as a deadline. Say "three days" in a planning meeting and someone writes it in a calendar. Say "5 points" and nobody can, which is exactly the point. Points push the schedule conversation to where it belongs: velocity.

Picking a baseline

Relative sizing needs something to be relative to. Without a shared anchor, one engineer's 3 is another's 8 and the numbers stop aggregating into anything meaningful.

The reliable way to establish one:

1. Find a story the team has finished. Recent, well understood, unremarkable. Not the smallest thing you have ever done and not the hardest.
2. Call it a 3. Starting at the low end of the scale leaves room to size things smaller without needing fractions. Some teams anchor at 5 instead; either works as long as everyone uses the same one.
3. Add a second anchor higher up. A known 8 gives the team two reference points, which makes the middle of the scale much easier to judge.
4. Write them down. Keep the reference stories visible during every session. Anchors that live only in memory drift within a couple of months.

Re-anchor when the team changes substantially — new members, a new codebase, a long gap. Do not re-anchor quietly mid-quarter, because it invalidates the velocity history you were about to use.

How points become a forecast

Velocity is the number of points a team completes in a sprint. Averaged over three or four sprints it becomes a genuinely useful planning number: a backlog of 120 points in front of a team averaging 30 is roughly four sprints of work.

What makes velocity work is that it is measured, not assumed. It already contains the team's meetings, their review cycle, their on-call rota, their holidays — everything an hours estimate leaves out. Nobody has to model any of it.

Two rules keep it honest:

• Never compare velocity across teams. The scales are anchored to different reference stories. A team doing 40 and a team doing 25 are not being measured in the same unit, and treating them as if they were is the fastest way to make both teams inflate their estimates.
• Never target velocity. The moment it becomes a goal, it stops being a measurement. Teams hit velocity targets by sizing the same work higher, which produces a rising number and no additional software.

A working sense of the scale

These are orientation, not definition. Your team's 5 is whatever your team's reference 5 is, and that is the correct way round.

Where teams go wrong

Estimating individually

"It's a 3 if Priya does it and an 8 if I do" is a real observation, but the estimate has to be team-level — you rarely know at planning time who will pick it up. Size it for the team as it is.

Sizing bugs on the same scale

Bugs are mostly investigation, and investigation resists sizing. Many teams either timebox bugs or track them separately rather than forcing them through a scale designed for planned work.

Treating points as productivity

Points measure size, not output or value. A team that delivers 20 points of the right thing has beaten a team that delivered 50 points of the wrong thing, and no dashboard will tell you that.

Inflating over time

Point inflation is the standard response to being held to estimates. It shows up as rising velocity with flat delivery. If you see that pattern, the problem is upstream of the estimation process.

When points are the wrong tool

For roadmap-level work months out, t-shirt sizing is usually a better fit — it is faster and far harder to mistake for a schedule. Some teams drop estimation entirely in favour of counting stories and slicing them to a consistent size, which works well on backlogs that are genuinely uniform.

If you are keeping points, the Fibonacci scale is the standard choice and it is standard for good reasons.

Common questions