Somewhere right now, a team is thirty minutes into an argument about whether a login refactor is a 5 or an 8, while a manager two doors down quietly converts last sprint's points into hours on a spreadsheet. Both of these are symptoms of the same confusion: nobody agreed on what the estimate was for.
That's the real question. Not which unit is better, but what job the estimate has to do. Hours and points answer different questions, and most of the pain teams feel comes from using one to answer the other's question. So let's be fair to both, because both camps are right about something.
When hours are the right tool
Hours get a lot of undeserved scorn in agile circles. If the work is small, well understood, and done by one person, an hour estimate is often the honest answer. "This config change is about two hours" is a perfectly good sentence. You've done it ten times before. You don't need an abstraction layer for that.
Hours also self-correct when the feedback loop is short. Estimate Tuesday's task at four hours, watch it take nine, and you find out Wednesday. That sting recalibrates you fast, and after a few rounds your small-task estimates get genuinely decent. The historical problem with hour estimates was never small tasks. It was projects, where the feedback arrives three months too late to teach anyone anything.
And sometimes you genuinely need dates. A contract with penalty clauses. A compliance deadline a regulator picked, not you. A launch coordinated across four teams and an ad budget. In those situations someone has to say "this ships by November 14th," and pretending otherwise isn't agility, it's avoidance. Hours, and the calendar math they enable, are how you have that conversation with a straight face.
Where hours fall apart is everything else: uncertain work, shared work, long horizons. An estimate in hours looks precise, so people treat it as precise. "Roughly 300 hours" quietly becomes "300 hours," which becomes "why are we at 340." The unit itself invites the misreading. Nobody has ever mistaken 13 points for a promise, because nobody knows what a point is. That vagueness is annoying. It's also protective.
When points earn their keep
Story points fix a specific set of problems, and it's worth naming them precisely, because points get sold as magic and then blamed when the magic doesn't happen.
First, the "whose hour" problem. A senior who's lived in the payment code for three years and a junior who joined in March won't take the same time on the same story, and during planning you often don't know who'll pick it up. An hour estimate forces you to guess the person along with the work. Relative size doesn't. The story is as big as it is, whoever ends up doing it.
Second, false precision. Points are deliberately coarse. The jump from 5 to 8 says "this is meaningfully bigger, and we're not sure by how much." That's more truthful than 22.5 hours, and truthful estimates are the only kind worth collecting.
Third, and this is the part people miss, points let you plan by throughput instead of by summing guesses. You don't forecast a release by adding up individual estimates and hoping. You measure how much your team actually finishes per sprint, over several sprints, and project from that. Velocity is an observation, not a target. The error on any single story washes out in the aggregate, as long as the team is consistently wrong in the same direction. I've written before about what story points actually measure, and the short version is: they work because they're relative and team-owned, not because Fibonacci numbers have powers.
One condition, though. Points assume a team estimating together. That's not decoration. The moment a designer throws a 3 and a backend developer throws a 13 on the same story is the entire value of planning poker; the number matters far less than the argument it flushes out. It's why we built the reveal step in ScrumMastr the way we did. If one person estimates alone, points lose most of their value, and you might as well use hours and skip the theater.
So: solo, small, known, or date-bound work leans hours. Team-based, uncertain, throughput-planned work leans points. It genuinely depends, and anyone selling you one unit for every situation is selling.
The conversion table that ruins both
Now the hybrid mistake, which I'd call the single most reliable way to wreck an estimation system: somebody publishes a conversion table. One point equals four hours. It usually starts innocently. Finance needs to capitalize development costs, or a PM wants to sanity-check a roadmap, and the table appears on a wiki page. It never leaves.
Watch what happens across the next few sprints, because the decay has a predictable shape.
Sprint one, the table is just a reference. Sprint two, someone notices a 2-point story took a full day and asks the developer to explain the gap, since the table says 2 points is eight hours. That question sounds harmless. It isn't. The developer has just learned that points are audited against the clock.
Sprint three, the estimates start changing. Not the work, the estimates. Anything that might run long gets bumped a size to leave breathing room, because nobody wants to explain another gap. Velocity creeps upward while actual output stays flat. The relative-sizing conversation in planning goes quiet, because the real question in everyone's head is no longer "how big is this compared to the search story" but "how many hours will I be held to."
By sprint six you have the worst of both worlds. You have hours, with extra steps and a fig leaf. Your velocity no longer forecasts anything, because the old numbers and the new numbers mean different things, so the one genuinely useful output of the whole system is gone. And you've kept all the ceremony of points while destroying the property that made them work: that they were never a time commitment, so nobody had a reason to game them.
If you truly need hours somewhere, for billing or capitalization, track actual hours as a separate dataset and never route them through points. The two can coexist peacefully. The conversion table cannot coexist with either.
The question stakeholders are actually asking
Here's the honest part that estimation debates usually skip: your stakeholders don't want points, and they don't want hours. They want a date and a confidence level. "When will it ship, and how sure are you?" Every request for a conversion table is that question wearing a disguise, and the right response is to answer the real question instead of converting units.
Velocity gives you a clean way to do it. Say the release backlog sits at 120 points, and over the last six sprints your velocity has ranged from 18 to 26. Divide both ways: 120 over 26 is about five sprints on a good run, 120 over 18 is about seven on a rough one. With two-week sprints, that's a window of ten to fourteen weeks. So the answer is: "Mid September if things break our way, mid October if they don't, and the range narrows every sprint as we burn real data."
Notice what that sentence contains. A date. A confidence range. A promise of updates. Nobody in the room asked what a point was, because nobody cares. Stakeholders who push back on ranges usually aren't rejecting the math; they're telling you a hard constraint exists on their side. That's useful information. Scope down to hit the early edge of the window, or negotiate the date, but don't respond by faking precision you don't have.
This is also where preparation pays off. A forecast is only as good as the backlog behind it, and a backlog full of unestimated epics forecasts nothing. Keeping the next couple of months sized and sliced is most of what makes sprint planning fast, and it's what makes the velocity math above something you can defend in front of a director.
What about not estimating at all
The #NoEstimates crowd deserves a fair hearing, because the strongest version of their argument is not "estimates are evil." It's that when a team slices stories to a consistent size, simply counting them forecasts about as well as pointing them, for a lot less effort. And they're right more often than point loyalists like to admit. Story count and story points converge as slicing discipline improves, which quietly suggests the slicing was doing the heavy lifting all along. If your team already breaks everything into one-to-three-day chunks, try forecasting on throughput of counted stories for a quarter and see if the answers differ. The catch is that consistent slicing is a skill most teams build by estimating, arguing, and being wrong together first. Skipping estimation before you have that muscle isn't a shortcut, it's skipping the workout.
Pick the unit for the job, then hold the line
Decide what question your estimate answers before you pick its unit. Solo task next week: hours, and don't apologize for it. Team forecasting a quarter of uncertain work: points and measured velocity. External date carved in stone: plan backward from it in real time, and manage scope as the variable.
Then defend the boundary, because the boundary is the system. The day a conversion table shows up in a wiki, delete it and go answer the question that prompted it with a date range instead. That one habit protects everything else. Teams don't usually abandon estimation because the numbers were wrong. They abandon it because the numbers stopped meaning anything, and that's a preventable death.