What Story Points Actually Are
Story points measure relative complexity, not time. A practical explanation of comparison, velocity, and why hours are a different kind of estimate.
A common mistake during Scrum estimation is to convert story points directly into time. But a story point is not an hour or a day: it is a relative measure that helps a team compare one backlog item with another.
Relative rather than absolute
Imagine someone asks how tall a wine bottle is. Instead of measuring it in centimetres, we could say it is about three cups tall. The cup becomes our unit of comparison. It is not a conventional measurement, but it still lets us reason about the bottle relative to something familiar.
Story points work in a similar way. Suppose item A is simple enough that the team assigns it one point. If item B appears twice as complex, it receives two points.
If item C seems three times as complex as B, it could receive six points. What matters is not the exact number but the relationship between the items.
Why not estimate everything in time?
Estimating every item in days encourages us to analyse work in detail before we have learned enough about it. That can be expensive in an agile setting, where requirements may change from one sprint to the next. Relative estimation lets a team compare new work with examples it already understands.
Time also changes with the person doing the work. A senior developer and a junior developer may agree that B is twice as complex as A, while giving very different answers when asked how many days each will take.
The relationship remains stable even when the duration changes. That is the useful distinction: time is an absolute estimate; story points are a relative estimate made by a particular team.
But stakeholders still need a date
That is where team velocity can help. Velocity is the number of story points a team completes in a sprint, usually considered over several sprints rather than as a single isolated result.
If a team has recently completed an average of roughly 32 points per sprint, and a group of features is estimated at around 60 points, the historical data suggests approximately two sprints. It is a forecast based on the team's own evidence, not a permanent conversion formula.
Velocity should not be used to compare teams or as a productivity target. It is most useful as a local planning signal: the estimate says how pieces of work compare, while observed delivery helps the team reason about time.