Story Points Explained

A story point is a unit of relative size. When a team says a story is “5 points,” they are not predicting five hours or five days — they are saying it is about the same size as other 5-point work they have done, and noticeably bigger than a 3. That comparison is the entire idea, and it is why story points survive when hour estimates constantly miss.

What a story point actually captures

Three things fold into a single number:

• Effort — how much work there is to do.
• Complexity — how intricate or interconnected the work is.
• Uncertainty / risk — how many unknowns could surprise you.

A large-but-boring task (lots of repetitive work, no unknowns) and a small-but-treacherous task (a few lines touching a fragile subsystem) can both be a 5 for different reasons. That is a feature, not a bug: the number is a compression of “how much of our capacity will this consume.”

Why relative beats absolute

Humans are unreliable at absolute estimates (“this will take 6.5 hours”) but remarkably good at relative comparison (“this is about twice as big as that”). Story points lean on the skill we are good at. They also travel better across people: two engineers rarely agree on hours because they work at different speeds, but they can agree that one story is bigger than another.

Set a baseline story first

Points mean nothing until they are anchored. Before your first planning poker session, pick a small, well-understood, recently completed story and declare it your reference — often a 2 or 3. Every future estimate is then a comparison to that anchor. When you onboard a new team member, showing them the reference stories calibrates them faster than any definition.

Here is how a team might calibrate three references:

From points to a forecast

Individually, points are just relative sizes. Their power appears when they add up into velocity — the points a team completes per sprint. A team averaging 24 points can look at a 120-point backlog and forecast roughly five sprints of work, with a range rather than a false promise. See sprint planning estimation for how this turns into a commitment.

How to start pointing as a new team

1. Agree on a deck (a modified Fibonacci scale is the default).
2. Choose one or two reference stories everyone knows.
3. Estimate a handful of items relative to those references.
4. Do not chase accuracy in the first few sprints — chase consistency.
5. After 3–4 sprints, your velocity stabilizes and forecasts get useful.

Common misuses of story points

• Comparing velocity between teams. Points are calibrated locally; a 5 on one team is not a 5 on another. Cross-team comparison is meaningless and corrosive.
• Turning velocity into a target. Reward higher numbers and you will get inflated numbers, not more output.
• Pointing individual tasks instead of stories. Points size user-facing outcomes, not each developer's to-do list.
• Assigning points to a single person. The estimate is the team's, because anyone might pick the work up.

Frequently asked questions

How many hours is a story point?

There is no fixed conversion — that is the point. If you need a time view, derive it from velocity across many stories, not from a per-point rate.

Should bugs get story points?

Teams differ. Many point bugs so the effort shows up in velocity; others leave them unpointed and simply track capacity spent. Pick one approach and stay consistent.

What if the team cannot agree on a number?

A persistent split usually means the story is unclear or too big. Refine it or split it rather than averaging the votes.

Point your backlog with the team

PlanITPoker gives you a free room to point stories together in real time, with Fibonacci and T-shirt decks and instant vote analytics. No signup, no setup — just share the link and start.