How many hours is 5 story points?

There is no universal answer. For the example team on this page, 5 points is 37–52 hours of team capacity, median 41. Enter your own last sprints in the calculator to get your team’s range.

How many days is 8 story points?

For the example team, 8 points is 59–83 hours of team capacity, about 10–14 person-days at 6 focus hours a day. It is spread over the people who worked on it, so it is not 8 calendar days of one developer.

Why estimate in story points and not in hours?

Points let people who work at different speeds agree on a size: Cohn’s example is a senior who finishes a story in 8 hours and a junior who needs 16, who can both call it one point. The team’s velocity then turns points into a forecast. Ron Jeffries, who may have invented them, now prefers slicing stories small over estimating at all.

Where do I find completed story points per sprint in Jira?

In a company-managed Scrum space: Reports, then Velocity Chart. Atlassian’s documentation describes the grey Commitment bar as the estimate of all work items when the sprint begins and the green Completed bar as the completed estimates when it ends. Use the Completed numbers here.

Is my data sent anywhere?

No. The calculation runs in your browser, nothing is sent or stored, and the page works offline once it has loaded.

Story Points to Hours Calculator: Your Team’s Real Range

One point is not 8 hours, for any team. Enter what your team finished in its last sprints and the hours it had: get the range of hours a point really costs you, and how long a backlog will take.

Usual sizes for this team, in hours of team capacity
Size	Range	Median
1 point	7–10 h	8 h
2 points	15–21 h	16 h
3 points	22–31 h	24 h
5 points	37–52 h	41 h
8 points	59–83 h	65 h
13 points	95–134 h	106 h

How the calculator works

For each sprint it divides the hours your team had by the points it finished. That gives hours of capacity per point, sprint by sprint. Then:

Hours for N points = N × hours per point, using your fastest sprint, your median sprint and your slowest sprint. You get a range, not a number.
Sprints for N points = N ÷ velocity, using your highest, median and lowest completed points per sprint.
Person-days = hours ÷ the focus hours one person gives sprint work in a day (after meetings, reviews and support). Six is a common planning figure; use yours.

“Team hours available” is everyone’s working hours in that sprint minus leave, holidays and meetings. If you do not track it, the sprint capacity calculator works it out from the team’s days off.

A worked example

Five people, two-week sprints, some leave. What they finished and the hours they had:

Sprint	Points completed	Team hours	Hours per point
Sprint 1	34	300	8.8
Sprint 2	41	300	7.3
Sprint 3	26	240	9.2
Sprint 4	38	285	7.5
Sprint 5	29	300	10.3
Sprint 6	36	270	7.5

Sprint 2 cost 7.3 hours per point and Sprint 5 10.3: the same team, a month apart. A 13-point story is therefore 95–134 hours of team capacity, median 106. A 120-point backlog takes 2.9 sprints at the best velocity and 4.6 at the worst, median 3.4. The popular “1 point = 8 hours” would have said 104 hours: close to this team’s median, but it hides that the same 13 points cost 95 hours in the best sprint and 134 in the worst.

Should you convert story points to hours at all?

Usually only after the estimate exists, and only as a range. Mike Cohn, whose books made story points mainstream, puts it this way: “the relationship between points and hours is a distribution”. One point has a typical number of hours behind it and a spread around it; a 13-point story and a 1-point story should not overlap, but a 1 and a 2 often do. The calculator shows that spread from your own sprints instead of hiding it in one ratio.

Points exist so that people who work at different speeds can agree on a size. Cohn’s example: a senior developer finishes a story in 8 hours, a junior needs 16, and both can call it one point. Converting each story to hours up front brings back the argument points were meant to avoid.

Ron Jeffries, one of the authors of Extreme Programming, writes: “I like to say that I may have invented story points, and if I did, I’m sorry now.” In early XP, stories were estimated in ideal days and multiplied by a load factor. He now prefers slicing stories so small that estimating hardly matters. The Scrum Guide (2020) does not mention story points at all; it says only that “The Developers who will be doing the work are responsible for the sizing.”

When someone outside the team needs hours (a budget, a contract, a release date), give them a range from history, as above, and say which sprints it comes from.

In Jira

Completed points per sprint are on the Velocity Chart (company-managed Scrum spaces: Reports, then Velocity Chart). Atlassian describes the grey Commitment bar as “the total estimate of all work items in the sprint when it begins” and the green Completed bar as “the total completed estimates when the sprint ends”. Copy the Completed values into the calculator.

Workload & Capacity Planner shows the other side of the same question inside Jira: its board can sum any number field, such as Story Points, per column, so you see each person’s points at a glance, and its Workload view puts each person’s estimated hours against their weekly capacity, green, amber or red. It does not convert points to hours; use this page for the ratio and the board for who has room.

Sources

Mike Cohn, Mountain Goat Software: Don’t Equate Story Points to Hours.
Ron Jeffries: Story Points Revisited (2019).
Ken Schwaber and Jeff Sutherland: The Scrum Guide (November 2020).
Atlassian: View and understand the velocity chart.

Story points to hours calculator

How the calculator works

A worked example

Should you convert story points to hours at all?

In Jira

Sources

Frequently asked questions