Story Points Explained

"How many hours is a point?" is the most common question new Scrum teams ask, and the answer, "it isn't", is the least satisfying. This guide explains what story points actually measure, why teams use them instead of hours, and how to make your team's points mean something consistent.

What is a story point?

A story point is a relative measure of the effort needed to finish a piece of work. It combines three things:

• Amount of work: how much there is to build, test and ship.
• Complexity: how hard that work is to get right.
• Uncertainty: how much we don't know yet.

The key word is relative. A story point doesn't mean anything on its own. A 2 only means "about twice the effort of a 1" and "a bit less than a 3". The number is useful because the whole team agrees on what it's being compared with.

Why not just estimate in hours?

People are poor at absolute estimates and much better at comparisons. Most of us can't say how many hours a feature will take, but we can say "it's about twice the size of the login change".

Hours have other problems:

• They depend on who does the work. A senior developer's 4 hours is a junior developer's 12. Points describe the work, not the person.
• They invite false precision. "13.5 hours" sounds exact and almost never is.
• They turn estimates into commitments. When a 4-hour task takes 6, it feels like failure. When a 3-point story is a bit harder than expected, it's just a 3.

Calibrating your team's scale

Points only work if the team shares a baseline. Here's a simple way to set one up:

1. Pick 3–5 finished stories the whole team remembers.
2. Order them from smallest to largest together, without numbers.
3. Give the smallest one a 1 or 2, then size the rest relative to it using your deck (usually Fibonacci; see our deck comparison).
4. Write them down. These are your reference stories. Bring them up when an estimate feels off.

Re-check your references every few months. As the codebase and team change, what felt like a 3 may now be a 2.

Points and velocity

Velocity is the number of story points a team completes in a sprint. After three or four sprints, the average gives you a realistic idea of how much to plan into the next one.

A few rules keep velocity useful:

• Only count stories that are fully done. Half-finished work doesn't count.
• Use it for planning, not performance. Comparing velocity across teams is meaningless, because each team has its own scale.
• Expect it to wobble. Holidays, incidents and new joiners all move it. Look at the trend, not one sprint.

Common story point mistakes

How planning poker fits in

Planning poker is the most common way to assign story points together. Everyone picks a card in private, all cards are revealed at once, and the team discusses any big differences before settling on a number. It works because it combines everyone's knowledge without letting one voice anchor the rest.

If you're new to it, start with 10 planning poker best practices. You can run a session for free in Votenir: pick a deck, share a link or QR code, and your team joins without signing up.

Frequently asked questions