Story Points Explained: How Agile Teams Estimate Effort

Story points are a unit of measure agile teams use to estimate the overall effort needed to deliver a user story. They combine three things: the amount of work, its complexity, and the uncertainty involved.

Why not estimate in hours?

• People are better at comparing than predicting. "This is about twice as big as that" is easier and more accurate than "this will take 11 hours".
• Hours depend on who does the work. A senior and a junior developer need different amounts of time, but they can agree on relative size.
• Points absorb uncertainty. A risky task gets a bigger number even if the happy path is short.

How to calibrate story points

1. Pick a small, well-understood story the team has finished and call it a 2 or 3.
2. Pick a clearly bigger one and agree it's an 8.
3. Estimate new stories by comparing them to these references, using planning poker.
4. Revisit the references every few months as the team and codebase change.

Story points and velocity

Velocity is the number of story points a team completes per sprint, averaged over the last few sprints. It helps with forecasting ("we usually finish about 30 points, so this release of 120 points is roughly four sprints away").

Two rules keep velocity useful:

• Never compare velocity across teams. Each team's points mean something different.
• Never use velocity as a performance target. Teams will inflate estimates, and the metric stops meaning anything.

Which numbers to use

Most teams use the modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21. Anything above 13 is usually a sign the story should be split. See Fibonacci vs T-shirt sizing for alternatives.

Estimate your next sprint

Planno shows the average, the agreement level and the spread of votes after each reveal, so you can spot disagreements fast. Start a free session.