The first time I asked a team to estimate in story points, someone leaned back and said: "Just tell me how many hours you want me to write down." It's a fair reaction. Hours feel concrete. Points feel like a consultant invented them to sound clever. But after a few sprints that same person was the one defending points to a new hire — because they'd felt, first-hand, what hour-based estimates do to a team.
The problem with estimating in hours
Imagine you're driving to a city 200 km away. How long will it take? You can give a decent guess — maybe two hours. Now: can you guarantee you'll be there by a specific minute? Cover exactly half the distance by the halfway time? Suddenly the confident number dissolves. Roadworks, an accident, a detour, a slow truck on a single lane — none of it was in your estimate, and all of it is normal.
Software work behaves the same way, only worse, because the "road" is often one nobody has driven before. When you estimate an unfamiliar task in hours, you're not estimating effort — you're estimating your own optimism. And optimism is remarkably consistent: it's almost always wrong in the same direction.
The core insight
Humans are bad at absolute estimates ("this will take 6 hours") but surprisingly good at relative ones ("this is about twice as big as that"). Relative estimation plays to the strength instead of the weakness.
What a story point actually is
A story point is a unit of relative effort. It bundles three things that all make work harder: complexity (how intricate the solution is), uncertainty (how much you still have to figure out), and volume (how much sheer work there is, even if it's simple). A point isn't an hour and isn't trying to be. A 5 is roughly five times the effort of a 1 — for your team, on your codebase, with your definition of done.
- Complexity — a payment flow with edge cases is more complex than a text change.
- Uncertainty — integrating a third-party API you've never touched carries unknowns.
- Volume — updating 40 templates by hand is a lot of work even if each edit is trivial.
Because points are relative, they travel well across people. Two developers with very different speeds can still agree that Task B is about twice the size of Task A, even if they'd write down different hour figures. That shared sizing is the thing you're really after.
A concrete example from planning
Here's a refinement session I ran, lightly simplified. We started by picking an anchor: a small, well-understood story everyone agreed was a 2 — "add a required field to the signup form." Then we sized everything else against it.
- "Add a required field to signup" — our anchor, a 2.
- "Add inline validation to that field" — a bit more than the anchor, but not double. Call it a 3.
- "Add password-strength meter with API check" — clearly bigger, new integration, unknowns. An 8.
- "Migrate the auth provider" — nobody could compare it cleanly to the anchor. That's the signal: it's too big to estimate, so we split it before sizing.
Notice what happened with the last item. Hour-based estimation would have produced a confident-sounding "three days" that was really a shrug. Relative estimation surfaced the truth: this isn't one story, it's an epic, and it needed breaking down. That's not a failure of the estimate — it's the estimate doing its job.
Why we don't convert points back to hours
The fastest way to destroy the value of points is to publish a table that says "1 point = 4 hours." The moment you do, everyone mentally estimates in hours and multiplies — and you've reintroduced every problem you were trying to escape, plus a layer of ceremony. Resist it. Let velocity, not a conversion factor, connect points to calendar time.
Velocity: how points become predictable
After two or three sprints, you'll know roughly how many points your team completes per sprint. That number — your velocity — is the honest bridge to planning. If you reliably finish about 30 points a sprint and the next chunk of backlog is 60 points, that's about two sprints of work. No one had to lie about hours to get there, and the forecast improves on its own as the team's sizing stabilises.
Try this in your next refinement
Pick one story everyone understands and label it your anchor. Size the next five items only by comparing them to the anchor — never say a number of hours out loud. Notice how much faster the discussion goes, and how the disagreements point straight at hidden assumptions.
Common objections — and honest answers
Every team that switches to points goes through the same round of objections. They deserve real answers, not slogans, so here are the ones I hear most often and what has actually held up in practice.
- "Management wants dates, not points." — Management gets better dates from points. Velocity turns sizes into a forecast with a track record behind it; a stack of hour guesses has no feedback loop at all. Show stakeholders a burnup chart based on three sprints of real velocity and the conversation usually ends.
- "Points are just hours with extra steps." — Only if you convert them. Kept relative, a point encodes uncertainty and complexity that an hour figure silently drops. The 'extra step' is the whole feature.
- "Our contracts bill by the hour." — Billing and estimating are different jobs. Track actual hours for invoicing all you like; just don't feed those numbers back into sizing, or you'll anchor every future estimate.
- "New joiners don't know what a 5 means." — Correct, and that's fine. They learn it in one or two refinements by watching comparisons against the anchor. That ramp-up is faster than learning a teammate's personal hour-optimism.
When hours are actually fine
Honesty requires saying this too: points are not a religion, and hours are not always wrong. For genuinely repetitive, well-understood work — a support rotation, routine dependency updates, the fourth nearly identical report page — hour estimates can be perfectly accurate, because the uncertainty that points exist to capture just isn't there. Some mature Kanban teams skip estimation entirely and forecast from cycle-time data, which is another honest option.
The rule of thumb I give teams: the more novel the work, the more relative sizing pays off. Sprint work in a product context is usually novel enough that points win. If your backlog is 90% routine tickets, don't force poker on it — measure flow instead.
Where Planning Poker fits
Relative sizing works best when everyone commits privately and reveals at once — otherwise the first number spoken anchors the room. That's exactly what Planning Poker is for. If you want to try relative estimation with your team right now, you can start a free session — no account needed — or read the deeper agile estimation guide first.
Give it a few sprints. The skeptic on your team will come around faster than you'd expect — mine did.