Story points vs hours: why converting them is the trap

Story points measure relative effort; hours measure duration — different axes. Build a points-to-hours table and you've quietly gone back to estimating time.

If you can convert points to hours, you’re estimating hours.

Story points and hours are not different units of the same thing. Hours measure duration — how long something will take you. Points measure relative effort — how big this is compared with the reference story everyone already shipped. They’re different axes. The moment you write “1 point = 4 hours” on the wiki, you’ve recast every estimation conversation as a duration argument, and you’ve thrown away the relative-effort property the technique exists to give you.

Points and hours as orthogonal axes Duration (hours) Relative effort (points) reference story (the one everyone shipped) story A same size, junior dev story B same size, senior dev "1 point = 4 hours" collapses both axes
Two stories the same size in points can take different amounts of time. The conversion line pretends they can’t.

The reason teams reach for the conversion is real: someone outside the team needs a date, and points don’t have units. The fix isn’t a conversion table; it’s velocity. Velocity already maps points to time at the team level — points-per-sprint × number-of-sprints gives you a date that respects the team’s actual delivery rate, not a fictional one.

Why points exist at all

A team that estimates in hours is really two estimates: the one the senior engineer believes, and the one the junior engineer writes down after rounding up to look responsible. Hidden votes plus relative effort dodge both. Points let the team agree “this is bigger than that one we shipped” without agreeing “this will take me four hours” — and the disagreement that surfaces on reveal is where the hidden scope comes out.

What good looks like

A team using points well doesn’t talk about hours during the session. They talk about the reference story, the comparable work they’ve shipped, and the unknowns. The number that comes out is a relative-effort signal that the team — and only the team — can turn into a date through their own velocity.

”But how long will it take?”

This is the legitimate need hiding under every request to convert points to time, and it deserves a real answer — a date range from velocity. If your team has averaged 30 points per two-week sprint, a 60-point slice of backlog is roughly two sprints, and you communicate it as “about a month, depending on what we hit.” That’s a date with the team’s noise built into it — the meetings they actually have, the on-call rotation, the holidays. A points-to-hours conversion gives you a date with no noise, which is wrong with more confidence.

So track velocity, project from it, and recompute it every few sprints. That’s the honest version of turning points into time, and it needs no conversion table. Cycle time is a separate thing again: a 3-point story can still sit in review for a week, which is a flow problem, not an estimation one.

Do story points include weekends?

No — because points don’t include time at all. A 5 isn’t 40 hours; it’s “this is bigger than the reference story.” Whether the team works weekends, takes Fridays off or runs four-day weeks doesn’t enter the estimate, because the estimate isn’t a measure of calendar time.

Where weekends do matter is in velocity. Velocity is points-per-sprint, and sprint length is calendar time — so a team with a public holiday mid-sprint will post a lower velocity that sprint, because they had fewer working hours to spend the same effort. That’s the right place for weekends to show up: in the calendar layer, not the points layer. Points don’t have weekends. Velocity does.

Retire the conversion table. Project from velocity instead.

Frequently asked questions

How many hours is 3 story points?

There’s no fixed answer, and that’s the point. Story points measure relative effort, not duration — 3 points is “a bit bigger than our reference story,” which takes different teams different amounts of time. Convert at the team level through velocity, never per story.

Is 1 story point equal to 1 day?

No. A story point isn’t a unit of time at all. If your team has settled into “1 point = 1 day,” you’re estimating in days with a Fibonacci coat of paint — and you’ve lost the relative-effort signal points exist to give you.

Why use story points instead of hours?

Because the team can agree “this is bigger than that” without agreeing “this will take me four hours.” Hidden votes plus relative sizing dodge the anchoring and seniority bias hour estimates invite — and velocity still gives you a date when you need one.

Can you convert story points to hours?

Only at the team level, and only after the fact: points completed per sprint (velocity) maps points to calendar time for that specific team. A standing per-story “X points = Y hours” table is the failure mode — retire it.

Do story points include weekends?

No — because points don’t include time at all. A 5 is “bigger than the reference story,” not a number of days. Weekends, holidays and four-day weeks show up in velocity (points per sprint), which is calendar-based, not in the points themselves.