How Many Hours Is a Story Point?

Why there is no standard conversion

A story point measures size relative to other items on the same team’s backlog. One team’s 3 might be another team’s 8. Points also bundle complexity and uncertainty with effort, so two 5-point stories can take very different amounts of time: one goes smoothly, the other runs into a flaky test suite.

That’s why charts saying 1 point equals 4 hours, or 1 point equals one day, are conventions some teams chose, not a standard. Copying one gives you a number that looks authoritative but has nothing to do with how your team works.

Should you convert story points to hours?

For sprint planning, usually not. Velocity already accounts for meetings, reviews and interruptions, and converting back to hours invites people to treat each estimate as a personal deadline.

There are fair reasons to want hours, though: quoting a fixed-price project, budgeting a team, reporting effort for finance, or explaining a roadmap to people outside engineering. In those cases, derive the number from data, give it as a range and say what it includes.

Often the better unit is sprints. If a release is about 90 points and the team finishes about 30 a sprint, plan for three to four sprints, and sprints convert cleanly to calendar weeks.

How to derive hours per point from your own history

You need two numbers for each completed item: its story points and the hours actually logged against it. The more sprints of data you use, the steadier the result.

• Collect finished items from recent sprints with their point estimate and logged hours. Leave out items that were re-scoped partway through.
• Group the items by point value.
• For each group, find the median hours and the middle range (for example, the 25th to 75th percentile). Medians resist the one story that went badly wrong.
• Check whether hours rise with points. If 8-point stories take about as long as 5-point stories, the scale needs recalibrating, not converting.
• Separately, divide the team’s total available hours per sprint by its average velocity. This team-level figure includes meetings, reviews and support that item-level logs usually miss.
• Use the item-level range for questions about a single story and the team-level figure for budgets and capacity. Recalculate every few months or when the team changes.

Worked example (illustrative numbers)

The numbers below are made up to show the method. They are not benchmarks, and your team’s will differ.

Team level: a team of four runs two-week sprints. Over five sprints it finished 30, 34, 28, 32 and 36 points, an average of 32. Each developer has about 6 focused hours a day, so the team has 4 × 10 × 6 = 240 hours per sprint. That works out to 240 ÷ 32 = 7.5 team hours per point.

Item level: grouping the same sprints’ finished items by points gives these median logged hours, with the middle range in brackets:

• 1 point: 4 hours (2 to 8)
• 2 points: 7 hours (3 to 12)
• 3 points: 10 hours (5 to 18)
• 5 points: 17 hours (9 to 30)
• 8 points: 28 hours (16 to 48)
• 13 points: too few items to say; this team splits anything that large

So how many hours is 8 story points?

For the example team, a single 8-point story typically logged about 28 hours of hands-on work, but anywhere from 16 to 48 was normal. Budgeting from team capacity, the same 8 points cost about 60 team hours (8 × 7.5), because that figure includes reviews, meetings, support and everything else that never gets logged against a story.

Both answers are right for different questions, and both apply only to that team. For any other team, the honest answer to "how many hours is 8 story points" is: look at your own 8-point stories.

Keep effort separate from duration, too. A story with 28 hours of effort can still take a week or more of calendar time if it waits on review or another team.

Common mistakes when converting

Most conversion problems come from treating the ratio as more precise or more universal than it is.

• Using one ratio for every team in the company.
• Multiplying points by a fixed number and presenting the result as a commitment.
• Quoting an average without a range, which hides the risk.
• Re-estimating finished stories so points match hours, which breaks the relative scale.
• Judging people by hours per point, which inflates estimates and spoils the data.