Story points explained

Why not hours

An hour is a personal unit. The same work takes two engineers different amounts of time, so an estimate in hours is always “how long this would take me” — which then somehow gets treated as everybody’s number.

Worse, hours read as a promise. “Six hours” said on Monday turns into “why is it not done” on Tuesday, even though review, testing, someone else’s blocker and three support interruptions all sit between the estimate and the delivery.

A point avoids that trap. It says “this item is about twice the size of that one” — a claim the team can check and disagree with without having to justify itself.

What size is made of

A point is not just the amount of code. Three things go into it at once, and the confusion starts wherever only the first is remembered.

• Volume: how much there is to do — screens, fields, cases, tests.
• Complexity: how hard it is — an unfamiliar area, tricky logic, somebody else’s codebase.
• Uncertainty: how much is unknown — an external service that may behave any way it likes, requirements still being clarified.

Where to start: a reference item

Estimating in points from nothing is impossible: a “one” on its own means nothing. So a team picks a reference — an item everyone remembers, small but not trivial. It is given, say, a two, and everything else is compared against it.

Two or three references of different sizes work better: one for a two, one for a five, one for an eight. With three anchors a new item finds its place faster than with one.

References age with the team: six months later something that was a five may be a two simply because the area became familiar. That is fine, but rescale deliberately rather than one item at a time.

How velocity comes out of points

Velocity is the sum of points for items finished in a sprint. It counts only what actually got done: a half-finished item contributes nothing.

It starts to mean something around the third or fourth sprint, when both the average and the spread are visible. With those, planning stops being an argument and becomes arithmetic: “we usually take forty, this backlog is fifty-five, so something will not fit”.

Velocity is a forecasting tool, not a target. The moment people are praised and scolded for it, points inflate: the team will not work faster, but it will estimate more generously by the very next sprint.

What not to do with points

A few habits drain the whole exercise of value.

• Converting points into hours. “A point is four hours” puts you back exactly where you started.
• Comparing velocity across teams: each has its own scale, and there is no shared unit between them.
• Turning velocity into a goal. A rising number with unchanged output is the first sign the metric is being fed.
• Measuring people in points. The item is being sized, not the person who picked it up.
• Changing an estimate after the fact. It describes what was known at the time, and that is precisely what makes it useful for forecasting.

How many points is too many

Anything a team sizes above an eight usually means the item is not understood as a whole. Such a card is not estimated but split — not because large items are forbidden, but because the estimate has nothing to stand on: there is too much unknown inside it.

A good rule: an item should fit into a sprint with room to spare. If it fills the sprint entirely, any surprise turns that sprint into zero delivered.