What is a story point worth in hours?
A story point has no universal value. It has your team's value, and that is measurable.
Hours per point
—
With no points delivered there is nothing to divide by. Enter the points completed in the sprints you measured.
Hours the next sprint would need
—
Points per hour
—
Formula: hours spent ÷ points delivered
What the number assumes
This only works across several sprints. One sprint tells you about that sprint. It also breaks the moment the team changes size or composition. The number belongs to a team, not to a project.
The formula defines the arithmetic. It does not define your business. A figure from this page is a starting point for a decision rather than the decision.
How to convert story points into hours
Divide the hours the team spent by the points it completed, across several sprints. That is your hours per point. Multiply it by the points planned for the next sprint and you have an hours forecast you can compare against capacity.
Use at least three sprints. A single sprint contains too much noise. One long illness or one unusually clean piece of work moves the ratio enough to make it useless as a predictor.
Why the number belongs to a team, not a project
A point is a unit of relative size agreed by the people doing the estimating. It encodes that team's skills, that team's codebase and that team's definition of done. Two teams that both call something a five may be describing work that differs by a factor of three, and neither is wrong.
This is why comparing velocity between teams produces nothing useful, and why using it as a performance measure is actively harmful: the one thing a team can reliably do in response is inflate its estimates. The unit is arbitrary, which makes it easy to move and impossible to audit.
What makes the conversion stable
A stable team, a consistent definition of done, and estimating the same kind of work. Change any of the three and the ratio has to be re-measured. A new joiner, a shift to unfamiliar work, or a tightened definition of done all move it, sometimes sharply.
It is worth recalculating every quarter as a matter of routine, and immediately after any of those changes. A ratio that is quietly six months out of date is worse than no ratio, because it is still being trusted.
Using the forecast honestly
The output is a range, even though the arithmetic gives a point. Take the best and worst of your recent sprints as the ends of it, and quote both. A forecast expressed as a single number will be heard as a commitment, whatever caveat is attached to it.
And keep the forecast away from the estimate. If the team knows the number the forecast needs to hit, the estimates will move to meet it, and you will have lost the only reliable input you had.
When to stop using points at all
Once a team's items are consistently similar in size, counting them works as well as pointing them and costs nothing. Several mature teams end up here: they slice work until each piece is roughly a day or two, then forecast on throughput, how many items finish per week, and drop estimation entirely.
That is a legitimate destination rather than a failure of the practice. Estimation is a means of forecasting, and if a simpler measure forecasts as well, the estimation meeting is pure overhead.
The signal to watch is the spread. If most items come out the same size, the points are carrying no information; if the spread is wide and hard to predict, estimating is still doing work and should stay.
Questions
Does this not defeat the point of points?
Partly, and deliberately. Points are useful for relative sizing during planning, and converting them is useful for answering when to someone outside the team. Use each where it belongs.
Why does my number keep moving?
Because estimation drifts as a team gets better at it. Recalculate every few sprints rather than fixing the number once.
How many hours is a story point?
Whatever your team's own history says, and nothing else. The conversion is your hours divided by your delivered points over several sprints. A point is a unit local to one team, so borrowing another team's conversion is the fastest way to make the number meaningless.
Should I tell the team the hours-per-point figure?
Use it for forecasting, and be careful about using it in planning. The value of relative estimation is that it avoids arguments about hours. Publishing a conversion rate brings them back and pushes the team towards estimating in disguised hours, at which point the practice has no advantage over estimating in hours directly.
Why not just estimate in hours?
Because people are consistently better at comparing two things than at estimating one in absolute terms. "About twice the last one" is a judgement most teams make reliably, while "seventeen hours" is one almost nobody does. Points keep the estimate in the form the team is good at and let the arithmetic convert it afterwards.
Related calculators
Same corner of the arithmetic, different question.