Guide · 6 min read · Updated 2026-09-14
Story points vs hours
Every team eventually asks a manager's version of this question: if we need dates anyway, why not estimate in days? The honest answer is that both units are useful — for different questions — and mixing them up is what makes estimates untrustworthy.
What each unit actually measures
| Story points | Hours / days | |
|---|---|---|
| Measures | Relative size: complexity, uncertainty, volume | Elapsed working time for one person |
| Owned by | The whole team | Whoever will do the work |
| Good at | Fast comparison, forecasting a sprint or quarter | Sequencing a specific person's next two days |
| Bad at | Answering "which Tuesday?" on its own | Surviving who picks the task up, or any surprise |
| Fails when | Treated as a fixed number of hours | Treated as a commitment rather than a forecast |
Why points beat hours for backlog work
People are unreliable at absolute duration and surprisingly consistent at comparison. Ask how many hours a task takes and you get an answer shaped by optimism, by who is asking, and by what happened last week. Ask whether it is bigger than a task the team finished recently, and a group of engineers will converge quickly and stay converged.
Points also survive the assignment question. An hour estimate silently assumes a specific person; the same story is two days for the developer who wrote that module and a week for a new joiner. A size estimate holds either way, and the team's velocity absorbs the difference over a sprint.
Finally, points are cheap. A refinement session can size fifteen stories in an hour; producing defensible hour estimates for fifteen stories takes a morning.
Where hours are genuinely the right unit
- Sprint task breakdown. Once a story is in the sprint and split into tasks, hours help the person doing them sequence their day.
- Fixed-scope, fixed-price contracts. When the commercial agreement is expressed in time, you owe a time estimate — with an explicit contingency.
- Well-known repeatable work. A release, a data migration you have run four times, a certification audit. Uncertainty is low, so duration is knowable.
- Coordinating with people outside the team. Booking a security review or a translator needs a date, not a size.
Answering "when will it be done?" without converting
You do not need a points-to-hours conversion to give a date. You need a velocity range and a little honesty about probability:
- Total the points of the remaining scope — call it 120.
- Take the team's last five or six sprints of completed points, not the average: say the range was 18 to 30.
- Divide both ends: 120 ÷ 30 = 4 sprints in the good case, 120 ÷ 18 ≈ 7 in the bad one.
- Report the range with its assumptions: "four to seven sprints if scope holds and the team stays the same."
A range is not evasion; it is the accurate answer, and it is far more useful to a stakeholder than a single date that will be wrong. If someone insists on one number, give the pessimistic end.
The conversion trap
The moment a team publishes "1 point = 4 hours", points become hours with a worse interface. Estimates start being negotiated ("can you make it a 3?"), the scale stops reflecting uncertainty, and velocity becomes a capacity calculation that always says the same thing.
If your organisation needs the relationship for capacity planning, derive it downwards instead: measure how many points the team actually completed in the last few sprints, and use that as the input. Never push a rate upwards into the estimates.
Migrating from hours to points
- Pick two or three recently finished stories everyone remembers.
- Declare the middle one a 3 (or an M) — that is your anchor.
- Estimate only against the anchor for the first few sessions. Ban the word "hours" in the room; it takes about three sessions to break the habit.
- Do not convert historical hour estimates. Start the new series from this sprint.
- Expect velocity to be noisy for three or four sprints, and say so in advance so nobody reads the noise as a slowdown.
Estimating both in one session
Some teams want a size for planning and a rough duration for the sprint board. Planner Poker supports both in the same room: the card deck sizes the story on a Fibonacci or T-shirt scale, and a separate time-estimation round lets participants signal expected duration on a simple 1–5 scale. The session summary records the agreed value for each task alongside every participant's vote, so the two conversations stay visibly separate.