Story points vs hours for capacity planning: which should you use?

This debate gets weirdly heated for what it is. Story points versus hours — people will defend their side like it’s a moral position. It isn’t. They’re two different tools, and the honest answer is that the better one depends entirely on your team and who’s reading the plan.

Let me give you the short version up front, then the reasoning.

The quick answer

Story points win when your team is stable, you’ve got velocity history, and you want estimation to be fast and relatively painless. They capture complexity and risk, not just raw time, and they sidestep the trap of arguing whether something is “a 4-hour task” or “a 6-hour task.”

Hours win when you need concrete capacity math, when you’ve got part-timers or contractors whose availability varies, or when you answer to stakeholders who think in calendars and deadlines. Hours map directly onto available time, so the capacity arithmetic is unambiguous.

And the move a lot of mature teams land on: estimate in points, but sanity-check capacity in hours. More on that below.

Whatever you pick — and this is the one hard rule — don’t mix units inside a single sprint. Half the team estimating in points while the other half logs hours is how capacity math turns to mush.

Why story points exist at all

Points feel strange to newcomers. “Why not just say how long it’ll take?” Because humans are genuinely terrible at estimating duration, and weirdly decent at estimating relative size. You might not know whether a task takes five hours or nine, but you can confidently say it’s bigger than that other one and smaller than this one.

That’s the bet story points make. They’re a relative measure — usually on a Fibonacci-ish scale (1, 2, 3, 5, 8, 13) — that rolls complexity, effort, and uncertainty into one number. The gaps in the scale are deliberate: they stop you from pretending you can tell a 6 from a 7.

The payoff:

• Faster estimation. No debating exact hours. Is it a 3 or a 5? Pick and move on.
• Less anchoring to a person. A senior dev’s “two hours” is a junior’s “two days.” Points abstract away from whose hours.
• Uncertainty is baked in. A scary, unknown task gets a bigger number partly because it’s scary. Hours hide that.

The cost: points mean nothing until your team has history. A 5 on one team isn’t a 5 on another, and it isn’t even a 5 on your team until you’ve completed enough of them to know what a 5 feels like.

Why hours still have a place

Points have a blind spot, and it’s the exact thing this whole topic is about: capacity.

A points estimate tells you a story’s size. It does not, by itself, tell you whether Ben — who’s out two days and on-call the rest — can finish it this sprint. To get there with points, you need velocity: how many points your team reliably completes per sprint. That works great once it’s stable and falls apart when your team composition keeps shifting.

Hours don’t have that dependency. An hour is an hour. If a person has 32 available hours this sprint (after subtracting PTO, holidays, and overhead) and you’ve assigned them 30 hours of estimated work, the fit is obvious. No velocity history required. That directness is why hours tend to win for:

• New teams with no velocity data yet
• Teams with part-timers or contractors whose available hours genuinely differ week to week
• Stakeholder reporting, where “we have 234 hours and 187 committed” lands better than “we’re taking 40 points”

Side by side

	Story points	Hours
Speed to estimate	Fast	Slower
Precision	Deliberately fuzzy	High
Needs velocity history	Yes	No
Captures complexity / risk	Yes	Not really
Good for new teams	No	Yes
Good for part-time / contractors	Awkward	Yes
Stakeholder-friendly	Sometimes	Usually
Capacity math	Via velocity	Direct

The hybrid most good teams settle on

Here’s what tends to happen as a team matures. They estimate stories in points, because it’s fast and they’ve got the velocity to make it meaningful. But when they’re checking whether the sprint actually fits — especially when someone’s half-out or the calendar’s chopped up by holidays — they reason in hours, or at least in available-days-per-person.

It’s not cheating. It’s using each tool for what it’s good at: points for sizing the work, time for checking it against real availability. The trouble is that doing both by hand means maintaining two mental models and usually a spreadsheet to bridge them.

This is, frankly, why we built Ekko to handle either. You choose your unit — hours or points — once, during onboarding, and the entire capacity pipeline follows it: per-person availability, PTO, overhead, and the available-versus-assigned summary all speak the same language. If you plan in points, capacity is expressed in points; if you plan in hours, it’s in hours. No mid-sprint unit collisions, no spreadsheet doing currency conversion in the background. The details are in the capacity docs.

So which should you use?

Run through this honestly:

• Brand-new team, no history? Start with hours. Graduate to points later if you want.
• Stable team, steady velocity, internal work? Points. They’ll make planning quicker.
• Lots of part-timers, contractors, or wildly varying availability? Hours. The precision earns its keep.
• Reporting up to time-and-deadline stakeholders? Lean hours, or be ready to translate.
• Somewhere in between? Estimate in points, check capacity in hours, and don’t overthink it.

The unit matters less than the discipline. A team that estimates consistently in points beats a team that estimates sloppily in hours, and vice versa. Pick the one that fits where you are right now, commit to it for the whole sprint, and revisit in a quarter if it stops fitting.

Just please — don’t turn it into a holy war. They’re rulers. Use whichever one measures the thing you’re trying to measure.