Story points to hours converter
There is no fixed number of hours in a story point, and any calculator that tells you one point equals four hours is making it up. A point is a measure of relative size, complexity and uncertainty that each team defines for itself — the conversion rate is a property of your team, not of the unit.
That said, the question comes up constantly and refusing to answer it does not make it go away. So this converter does the honest version: it derives hours per point from sprints your team has actually finished, and then shows you the spread between your fastest and slowest sprint. That spread is the real answer. If one point cost your team 4.2 hours in one sprint and 9.8 in another, the conversion exists — it is just far too wide to plan a deadline on.
Your sprint history
Use net hours that actually reached sprint stories, not paid hours — the sprint capacity calculator works that number out.
Quote the range, not the average. The average is the least informative number here.
How it’s calculated
Hours per point = average of (hours spent ÷ points completed) across your recent sprints
- Hours spent
- Net hours the team put into sprint stories — not paid hours. Use net sprint capacity, not gross availability, or every point will look far more expensive than it is.
- Points completed
- Only stories that met the Definition of Done in that sprint, matching how you calculate velocity.
- Spread
- Your slowest sprint’s rate divided by your fastest. Under 1.5× the conversion is usable as a rough check; above 2× it is not a planning tool.
Worked example: Three sprints from the same team
The same five-person team logged their net sprint hours and completed points across three sprints. Notice that nothing about the team changed between them.
| Sprint 1 | 183 hours ÷ 24 points = 7.6 h/point |
|---|---|
| Sprint 2 | 176 hours ÷ 42 points = 4.2 h/point |
| Sprint 3 | 181 hours ÷ 19 points = 9.5 h/point |
| Average | 7.1 hours per point |
| Range | 4.2 to 9.5 hours per point |
| Spread | 2.27× between fastest and slowest |
| A 13-point story therefore costs | 54.5 to 123.8 hours |
The average of 7.1 hours per point is arithmetically correct and practically useless: it says a 13-point story takes 92.5 hours, when the team’s own history says it could take anywhere from 55 to 124. Sprint 2 was mostly well-understood CRUD work; sprint 3 was one gnarly migration. That is precisely the difference points are designed to capture and hours are not.
Reference table
What your spread means. Spread is your slowest sprint’s hours-per-point divided by your fastest.
| Spread | What it means | What to do |
|---|---|---|
| Under 1.5× | Your work is unusually homogeneous | The conversion is a reasonable sanity check. Still do not quote it to stakeholders as a deadline. |
| 1.5× to 2× | Normal for a mixed backlog | Use it to sense-check an estimate, never to derive one. Plan with velocity instead. |
| Over 2× | Points and hours are measuring different things for your team | Stop converting. The spread is the signal: your backlog mixes well-understood work with genuine unknowns. |
How many hours is one story point?
For your team specifically, it is whatever your recent sprints say — typically somewhere between 4 and 12 hours, and varying by a factor of two or more between sprints. There is no industry-standard answer, and the widely circulated figures (one point equals a day, or four hours, or eight) are conventions someone invented rather than findings. If you need a number for a conversation today, use the average from your own history and quote the range alongside it.
Why do experienced agile coaches argue against this conversion?
Because the moment points map cleanly to hours, they stop doing the job they exist for. Points let a team say "this is about twice as big as that, and we are less sure about it" without committing to a duration — which is exactly what makes relative estimation fast and reasonably accurate. Fix a conversion rate and estimation quietly turns back into time estimation, with all the anchoring and optimism bias that relative sizing was introduced to avoid. Mountain Goat Software has argued this position for years and it is the mainstream view among practitioners.
When is converting points to hours actually reasonable?
Three cases. First, sanity-checking a sprint commitment against capacity — if the points you have committed to imply more hours than the team has, that is worth knowing before the sprint starts. Second, a rough budget conversation with someone outside the team who thinks in cost, where a range is genuinely more useful than a refusal. Third, spotting an estimation drift: if hours per point has been falling steadily for six sprints, your estimates are inflating even though velocity looks like it is improving.
What should you use instead for forecasting?
Velocity with a forecast range. Take the points your team has completed in recent sprints, use the low end of the observed range as the commitment, and express the delivery date as a span rather than a day. It requires no conversion, it automatically includes the interruptions and leave that hours arithmetic keeps forgetting, and it is honest about uncertainty in a way a single-point hour estimate never is.
Where this number misleads you
- Using gross hours instead of net. Dividing by paid hours rather than hours that actually reached the backlog inflates the cost of every point by roughly 40%.
- Publishing the conversion rate. Once the team knows one point is "supposed to be" seven hours, estimates start being reverse-engineered from schedules.
- Comparing hours-per-point between teams. It is a per-team unit twice over — once for points, once for what that team counts as sprint work.
- Quoting the average without the range. The average is the least informative number this calculator produces.
- Treating a falling hours-per-point as a productivity gain. It is at least as likely to be estimate inflation, which is the same phenomenon that makes rising velocity untrustworthy.
Frequently asked questions
How many hours is a story point?+
There is no universal answer, because story points are a relative unit each team defines for itself. In practice most teams land somewhere between 4 and 12 hours per point, but the same team will often see that vary by a factor of two between sprints depending on how much genuinely unknown work is in the backlog. The only defensible number is the one derived from your own recent sprints, quoted with its range.
Should you convert story points to hours at all?+
As a sanity check, sometimes. As a planning method, no. Fixing a conversion rate turns relative estimation back into time estimation and reintroduces the anchoring and optimism bias that points were adopted to avoid. If you find your team routinely converting points to hours to decide what fits in a sprint, it is usually simpler and more accurate to plan with velocity directly.
Why does our hours-per-point keep changing?+
Because points measure uncertainty as well as size. A sprint of well-understood work will always come in cheaper per point than a sprint containing a migration or an integration with a system nobody has touched in two years. A wide spread is not a sign your estimation is broken — it is a sign your backlog contains genuinely different kinds of work, which is normal and is exactly what relative estimation is designed to express.
Is 1 story point equal to 1 day?+
Only if your team has decided it is, and doing so is generally discouraged. The "one point equals one ideal day" convention exists and some teams use it deliberately, but it collapses the distinction between size and uncertainty: a task you understand perfectly and a task you have never attempted can both take a day, and only one of them deserves a low estimate. If you want to estimate in days, estimate in days — the value of points comes from not doing that.
The numbers say what happened. The retro decides what changes.
FocusRetro gives the same team a calm board for honest feedback, blind voting, and action items that survive until next sprint.
Start a retro freeNo credit card required