Somewhere in your Jira instance, a story point already has a price in hours. Maybe it’s in a team agreement, maybe it lives in one person’s head, maybe an automation rule does the math where nobody sees it. Ask on this forum, though, and the answer is always the same: points don’t convert.
There’s a thread here that runs exactly that way. Someone asks to estimate stories in story points and tasks in hours. Someone replies that this isn’t how story points work. The asker says he still needs per-developer hours for sprint planning.
Nobody’s wrong, and nobody leaves with an answer.
So here’s the short version of what I’ve learned talking to teams who convert anyway: the conversion between story points and hours is fine-ish when your team sets the rate and knows what it costs. It goes bad when the rate comes from outside the team, or when people use it to estimate instead of to translate.
How many hours is one story point?
Story points measure relative effort, compared to other stories on the same board. A two point story is roughly twice the effort involved in a one point story. That’s how much effort it claims, and nothing beyond it.
People ask how to get story points calculated, and the verb is the problem. You don’t calculate them. Assigning story points is comparison, which is why it takes ten minutes for a sprint backlog while estimating hours for the same work takes an afternoon. That’s the relative estimation method working as intended — people are bad at hourly estimates and decent at comparing two things. Same logic behind t-shirt sizes and the Fibonacci sequence in planning poker.
Relative sizing also absorbs what time based estimates can’t: relative complexity, potential risks, the technical debt you’ll hit halfway through. Agile story points describe the effort required, not the time it takes.
And they’re relative units that only mean something at team level. Comparing story points across boards tells you nothing, and inside one development team, different team members will finish the same story in different actual hours. That’s why the estimate belongs to the entire team, not to whoever picks up the ticket.
No global rate. But absolutely a local one.
Why agile teams convert story points to hours anyway
Something downstream always needs a number: a stakeholder wants a completion date, a product owner is working out how many story points fit in the next sprint, finance wants a ballpark figure for project estimation, a client is billed hourly, and the invoice needs actual hours. “Points don’t work that way” answers none of it, so teams solve it themselves. Three ways, mostly.
- Standardize the point, automate the rest. One PM works somewhere that decided to equate story points with a day of dev work. The development team sizes user stories normally, puts a 2 on something, and a Jira automation rule multiplies by 8 and writes 16 hours into the Original Estimate. Developers never think about hours. It works because the team owns the rate — imposed from above, the same setup produces padded story point estimates within two sprints.
- Stay on points throughout. Another team logs nothing. Capacity comes straight from points per sprint, and for planning that’s genuinely enough. Reporting is where it gets thin: most reports assume scheduled time with start and due dates, so they export to CSV and rebuild in a spreadsheet.
- Drop points where they don’t fit. Not all work is software development. One PM runs infrastructure and migration projects where there’s no comparable backlog to size against, so her teams estimate from past experience. Points on digital projects, hours on the rest. Estimation practices aren’t a religion, and different estimation techniques suit different work.
What you lose when you equate story points with hours
- Your team’s velocity stops being a separate signal. If points are hours in a costume, velocity measures how many hours fit in a sprint, which you already knew.
- Uncertainty flattens. A 13 and a 5 differ in size and in how sure anyone is. Multiply both by the same number and the second difference disappears.
- Estimation accuracy drops. Once a five publicly means forty hours, people pad, and a few sprints later, you’re back to a guessing game. Plenty of teams adopted point estimation to break free of exactly that.
The rule that keeps it manageable: convert downstream, not upstream. Size in points, convert after the estimate exists, for whoever needs hours. Once the estimation process becomes a negotiation about timesheets, you’ve lost what made relative estimation fast.
Get your rate from your own data
The worst way to pick a story points vs hours rate is agreeing on a round number in a meeting. Gather data instead — you already have it.
Use cycle time, not lead time: how long an item took from started to Done, without the backlog sitting time. Bucket three to six months of finished work by story point estimate, then take the median and the average of each bucket. Median matters more; one ticket left open over the holidays wrecks an average.
Estimate | Median cycle time | Average | Items |
|---|
1 point | 1.2 days | 1.8 days | 64 |
2 points | 2.1 days | 3.4 days | 81 |
3 points | 4.0 days | 4.6 days | 47 |
5 points | 8.5 days | 12.1 days | 23 |
8 points | 15 days | 22 days | 9 |
Two things fall out, and only one is the rate. First, a conversion grounded in what happened — a range, not a clean “x story points = y hours”. Second, a free read on your sizing: if 2s and 3s share a median, your team isn’t distinguishing them and you can drop a step.
Then add a buffer and plan off that, not the median. Half your work lands above it by definition.
Honest caveat: cycle time is elapsed time, not effort. A three-pointer spanning four days might be six hours of work and a lot of meetings. If you need effort, run the same exercise against time spent per bucket. Jira’s Control Chart gives cycle time but won’t group it by points, so expect to export. And put a date on whatever number you get — revisit it in a quarter.
Jira runs points and hours at the same time
You don’t have to choose:
- Board → Board settings → Estimation
- Estimation statistic: Story Points
- Time tracking: Remaining Estimate and Time Spent
Stories get sized in points, so the Velocity Chart keeps working. Tasks carry hours for whoever needs them. Neither corrupts the other.
Question | Unit | Where you read it |
|---|
What can we commit to next sprint? | Story points | Velocity Chart, past velocity over a few sprints |
When does this epic land? | Story points | Remaining points ÷ velocity, across future sprints |
Does anyone have room Thursday? | Hours | Capacity vs assigned hours |
What did this cost the client? | Hours | Logged work |
The mistake is reading one row with the other row’s unit.
Capacity planning in Jira needs actual hours
Velocity can sit at a healthy 35, and the sprint still collapses, because two team members are away, one is half-time elsewhere, and the person who has to do the migration is out that week. Points describe the work, not the week.
You can get part of the way there natively — we wrote up how to do capacity planning in Jira with the gadgets and filters that give you a rough read. It thins out fast once people are part-time, split across projects, or in different countries.
That’s the gap Planyway fills, and it’s why the conversion matters at all.
(I work on it, so weigh this accordingly.)
Planyway for Jira is basically an all-in-one app for cross-project planning: roadmaps, resource management, time tracking, and reports in one subscription.
The part that matters here is that in Planyway, capacity comes from a real work schedule:
- Each person gets a custom workload scheme with their own hours per day — somebody on 30 shows 30, a full-timer shows 40
- Team capacity is the sum of those personal schedules, not headcount × 40
- Holiday schemes are per country, so a public holiday cuts hours only for the people it applies to
- Vacations and days off come off automatically
( ➡️ Planyway has a free trial, in case you want to poke at it.)
What you get is a workload view where the week fills up in front of you: who’s over, who has room, and what the team total is once absences are taken out. That’s the real question behind most conversion requests on this forum — not what a point is worth, but whether the sprint fits into the actual hours these people have.
What story point estimation still won’t fix
- It won’t make estimates right. It makes them honest about their uncertainty.
- It won’t produce defensible client hours. Billing needs logged work.
- It won’t survive being handed down. Setting the rate is team collaboration, not policy.
- It won’t give detailed timelines by the day — just reliable plans at sprint level.
Over to you
- Do you convert story points to hours, and did you set the rate or inherit it?
- Has anyone measured cycle time per point bucket? Curious whether your curve is as uneven.
