Story points measure how big a piece of work is relative to other work; hours measure how long one person expects to spend on it. There is no fixed conversion between them, because the same 5-point story can take one developer six hours and another sixteen. If you need dates, you get them from velocity (points completed per sprint), not from a points-to-hours ratio.
That's the short answer. The longer answer matters because "how many hours is a story point?" usually comes from a manager with a legitimate need: a delivery date, a budget, a staffing decision. This article explains why conversion breaks things and what to give those people instead.
Story points vs hours at a glance
| Story points | Hours | |
|---|---|---|
| What it measures | Relative size: complexity, volume of work, uncertainty | Expected time for a specific person |
| Who it belongs to | The whole team | Usually an individual |
| Changes when someone else does the work? | No | Yes |
| Changes when the team gets faster? | No (velocity rises instead) | Yes |
| How you get a date | Remaining points ÷ velocity | Sum of hours ÷ available hours |
| Typical failure | Treated as hours in disguise | Padding, false precision, pressure to shave |
The key line is the fourth one. When a team improves, an hour-estimated backlog has to be re-estimated. A point-estimated backlog stays the same and velocity goes up, so your forecast improves automatically.
Why converting story points to hours backfires
1. The ratio isn't stable
Say your team finished 30 points in a two-week sprint with five people. You might calculate "30 points over roughly 300 working hours, so 1 point is 10 hours." But look at the individual stories from that sprint:
| Story | Points | Actual hours |
|---|---|---|
| Admin filter dropdown | 2 | 5 |
| CSV export | 5 | 22 |
| Password reset email | 8 | 41 |
| Fix timezone bug | 3 | 31 |
| Settings page copy update | 1 | 2 |
These are hypothetical, but the shape is normal. The sprint-level "10 hours per point" figure already includes meetings, reviews, and interruptions, and per story the hands-on time ranges from 2 to about 10 hours per point. The timezone bug ran long because of an unknown, which is exactly what points are supposed to absorb in aggregate. Velocity is reliable over a sprint precisely because the variation averages out. A per-story ratio throws that away.
2. Estimation turns back into time estimation
Once people know "an 8 is about two days," every estimation conversation becomes "how many days is this?" followed by a lookup. You have hours-based estimation with an extra step, and you lose the comparison to reference stories that made estimates consistent.
3. Points start getting negotiated
Hours invite pressure: "Can't you do it in three days instead of four?" Abstract points resist that, until they are tied to hours. Then a manager can argue a story down from 8 to 5 because "that's only a day less." If this is already happening, see handling management pressure on estimates.
4. Velocity becomes a performance metric
If 1 point equals 10 hours, a team doing 30 points a sprint "should" do 40 if it worked harder. Points inflate, velocity stops meaning anything, and forecasting dies. Velocity is a planning tool for one team. It is not comparable across teams and it is not a productivity score.
What story points actually capture
Points blend three things: how hard the work is (complexity), how much of it there is (effort), and how much you don't yet know (uncertainty). A 5 might be a small but tricky algorithm or a large, boring config change touching 30 files. Hours can't express "this is probably 2 days but could be 6." Points can, because the uncertainty is part of the size. The breakdown, with a scoring rubric, is in complexity vs effort in story points.
How to forecast without converting
Step 1: Measure velocity
Estimate in points for three or more sprints without thinking about time. Track completed points per sprint (only stories that meet the Definition of Done).
| Sprint | Completed points |
|---|---|
| 1 | 23 |
| 2 | 31 |
| 3 | 26 |
| 4 | 28 |
Average: 27. Lowest: 23. Highest: 31.
Step 2: Forecast with a range
If the release backlog has 120 points remaining:
- At 31/sprint (high): about 4 sprints
- At 27/sprint (average): about 4.5 sprints
- At 23/sprint (low): about 5.2 sprints, so 6 sprints to be safe
"Four to six sprints, most likely five" is an honest forecast. It reflects the team's real history, not anyone's guess about hours. The sprint velocity calculator does this math for you.
Step 3: Update every sprint
Each sprint you have one more data point and less remaining work. The range narrows. This is Steve McConnell's cone of uncertainty in practice: early forecasts are wide, later ones are tight, and pretending otherwise just moves the surprise to the end.
When management insists on hours
Sometimes "don't convert" isn't an option you get to choose. Here's how to handle the common requests without wrecking your estimation practice.
| What they ask | What they actually need | What to give them |
|---|---|---|
| "How many hours is a point?" | A date or a cost | A date range from velocity (above) |
| "When will feature X ship?" | A delivery forecast | "Sprints 14 to 16, most likely 15," updated each sprint |
| "How much will this cost?" | A budget | Team cost per sprint × forecast sprints. A five-person team costing $X per sprint over 4 to 6 sprints is $4X to $6X. |
| "We bill clients hourly" | Hour totals for invoicing | Track actual time separately for billing. Keep points for planning. |
| "I need to compare teams" | Portfolio visibility | Compare forecast accuracy or throughput, never raw velocity |
| "Give me a single number" | Confidence | Give the 80% number (the pessimistic end) and say so |
A script for the conversation
When someone asks for a conversion ratio, try something like:
"I can give you a date, and it'll be more reliable than a conversion would. We average 27 points a sprint, with a low of 23. The remaining scope is 120 points, so we expect five sprints and I'd plan for six. I'll update that number at every sprint review."
Most managers asking for hours want exactly this. They rarely care about hours per point; they care about when and how much.
If a ratio is mandated anyway
If your organization requires an hours figure on every story (some contracts and government programs do), keep the damage contained:
- Estimate in points first, in planning poker, without discussing time.
- Derive hours afterward using a team-level ratio from recent sprints (total team hours available ÷ velocity), and label it as derived.
- Recalculate the ratio every few sprints instead of fixing it forever.
- Never estimate in hours and back-convert to points. That's the direction that destroys relative sizing.
- Report the range, not just the average. Showing the 2-to-10 spread from the example table above is often the fastest way to convince people the ratio is a rough average.
Task hours inside a sprint are fine
Some teams break committed stories into tasks during sprint planning and estimate those tasks in hours to check capacity ("we have 220 hours available and 240 hours of tasks, so we're overcommitted"). That's a reasonable use of hours. It happens after sizing, at the task level, inside one sprint. It doesn't need a conversion ratio and doesn't feed back into story points. The sprint planning guide covers capacity checks in more detail.
Common mistakes
Building a conversion chart. "1 = 2h, 3 = 6h, 5 = 12h." Delete it. Every estimate made with it is an hours estimate.
Asking "how long will this take?" in refinement. Replace it with "Is this bigger or smaller than our 5-point reference?"
Starting from days. "This is about three days, so call it an 8." Now points are anchored on time. Redirect: "Forget days. Compare it to the CSV export story."
Using individual estimates. Points are a team estimate for the whole story, including review, testing, and deployment. A developer's personal coding hours are a different number.
Practice exercise: estimating without time
Run this in your next refinement session if your team keeps sliding back to hours:
- Put one reference story on screen: "Add email validation to signup form = 3 points."
- Present a new story, for example "Add Google sign-in."
- Ask only: "Is it smaller, about the same, or bigger than the reference? If bigger, a bit bigger (5), a lot bigger (8), or much bigger (13)?"
- If anyone mentions hours or days, the facilitator says: "Let's park time. Compare it to the reference."
- Repeat for five stories. Afterward, ask the team whether it was faster or slower than their usual discussion.
After three or four sprints of this, you'll have a velocity, and the date question answers itself.
FAQ
How many hours is a story point?
There's no fixed number. A story point represents relative size, and the time it takes varies with who does the work, what unknowns turn up, and how the team improves. Over a whole sprint you can observe an average, but using that average per story reintroduces the problems points were meant to solve.
Can you convert story points to hours?
You can compute a rough team-level average (available team hours ÷ velocity), but it's not reliable for individual stories, and using it for estimation turns points into hours with extra steps. If you need dates or costs, forecast from velocity with a range instead.
Story points vs hours: which is better for estimation?
Story points are better for planning and forecasting a team's work over several sprints, because they're consistent across people and absorb uncertainty. Hours are useful for short-range task planning inside a sprint and for billing. Many teams use points for stories and hours only for tasks.
What do I tell a manager who wants hours instead of story points?
Give them what they actually need: a date range and a cost range based on velocity, updated every sprint. Something like "five sprints likely, plan for six" answers the real question better than an hours-per-point ratio. If hours are mandatory, derive them from points afterward and label them as derived.