What Are Story Points? The Unit That Isn't Time

Story points are the weird little numbers teams assign to work instead of saying "that'll take three days." If you're new to this, they seem suspiciously vague — and they kind of are. But the vagueness is the point. Let me explain why we don't just use hours.

What a story point actually measures

A story point is a unit of relative size. It bundles three things together:

• Effort — how much work it is.
• Complexity — how hard it is to wrap your head around.
• Uncertainty/risk — how much we don't know yet.

All three get smooshed into one number. That sounds sloppy, but it's actually deliberate: separating them out makes estimation an argument. Bundling them keeps the conversation about "how big is this, roughly?"

It's relative, not absolute

The key rule: a story point has no fixed meaning. A 5 isn't "5 units of anything." It only means "about twice as big as a 2, and a bit smaller than an 8." The team calibrates the scale together over time, until "a 3" starts meaning "the usual medium thing" to everyone.

Think t-shirt sizes. An "M" on one team is a completely different shirt than an "M" on another. But within one team, everyone knows an M is bigger than an S and smaller than an L. Same idea — story points are t-shirt sizes with numbers.

Why not just estimate hours?

Because humans are genuinely terrible at estimating hours, and it gets worse with pressure. Here's what happens with hour estimates:

• We anchor on "how long should this reasonably take" and then pad it.
• We conflate effort with calendar time — a 6-hour task that waits 3 days for a review feels like it "took 3 days."
• We compare estimates to how long things actually took, which turns estimation into a guilt machine.

Points sidestep all of that. Nobody is "late" against a story point. The number is a size, not a deadline. It's so much healthier.

The scale

Most teams use Fibonacci: 1, 2, 3, 5, 8, 13. As things get bigger, the gaps widen — because our ability to tell big things apart gets worse. A 13 should feel like a red flag that says "this is too big, split it."

Then comes velocity

Here's where points earn their keep. Over a few sprints, the team totals up the points it actually completed. That number — velocity — becomes the planning guide. If our average is 30 points per two-week sprint, then next planning session we pull about 30 points of work. No guessing, no heroics, just "this is what we do in a sprint."

Velocity is a team's own pace. Comparing one team's velocity to another's is meaningless — a 30 for us isn't a 30 for them. It's our rhythm, and it's what makes sprint planning feel calm instead of stressful.

A real example

We once had a ticket that "should just be a quick UI tweak" — the kind of thing people say before it eats a week. It got a 2. Then we discovered the page was built with an old component library, the API didn't return the field we needed, and the design spec was for a screen that didn't exist yet. Same ticket, re-estimated: an 8. The points forced us to admit what we knew all along — it wasn't small. Good estimation is really just honesty with numbers.

Quick answers

Are story points the same as hours? No. Never. That's the whole idea. A 5 is "twice a 2," not "5 hours."

Who decides the points? The people doing the work, as a team — usually through Scrum Poker.

How many points should we do in a sprint? Whatever your velocity says. Don't compare to other teams. Start rough, refine over 3-4 sprints.

Tip: Estimation is a team conversation — and if your team is remote, make sure it happens when everyone's actually awake. A ClockHive glance at your team's cities before booking the session is the polite thing to do.