Story points explained

Story points are a unit agile teams use to estimate how big a piece of work is compared to other pieces of work. They are deliberately abstract: a story worth 5 points is not five hours or five days, it is "noticeably bigger than a 3 and smaller than an 8". This guide explains what story points measure, how they compare to hours, and how to estimate story points in a way that actually helps planning.

What story points measure

A story point estimate combines three things into a single number:

• Effort: how much work there is to do.
• Complexity: how hard the work is to get right, how many parts of the system it touches.
• Uncertainty: how much the team does not know yet, such as an unfamiliar API or unclear requirements.

A story can be large because it is long and repetitive, because it is tricky, or because nobody is sure how it will go. Story points let the team express all of that in one relative size without pretending to know the exact duration.

Relative sizing and reference stories

People are much better at comparing things than at measuring them in absolute terms. Most of us cannot say exactly how tall a building is, but we can easily tell which of two buildings is taller. Story points rely on that ability.

To make comparisons possible, a team agrees on one or two reference stories. Pick something recently completed that everyone understands, for example "Let users change their display name", and call it a 2. Then size new work against it:

• "Add a 'remember me' checkbox to the login form" feels smaller than the reference: 1.
• "Add password reset by email" needs a token, an email template, an expiry rule and a new page. It feels about two to three times the reference: 5.
• "Allow login with a third-party identity provider" involves an external integration the team has never built: 13, or a candidate for splitting.

Over time the team builds a small catalogue of reference stories at several sizes (a 1, a 3, an 8), which makes new estimates faster and more consistent.

Story points vs hours

The debate over story points vs hours comes up in almost every team. Here is the practical difference.

Aspect	Story points	Hours
What is estimated	Relative size of the work	Expected duration
Depends on who does it	No, the team estimates together	Yes, a senior and a junior give different numbers
Handles uncertainty	Built in, through larger and wider-spaced values	Usually hidden inside a single precise-looking number
Speed of estimating	Fast, by comparison	Slower, often requires task breakdown
Useful for	Forecasting over several sprints	Detailed day-to-day task planning

Hours are not wrong; some teams break stories into tasks and estimate those in hours during sprint planning. The problem comes from using hours for long-range forecasting, where their false precision tends to hide risk.

How to estimate story points

1. Choose a scale. Most teams use a Fibonacci or modified Fibonacci scale (1, 2, 3, 5, 8, 13, 20...). The gaps between numbers grow as stories get bigger, which reflects growing uncertainty.
2. Agree on reference stories. Keep them visible during every estimation session.
3. Estimate as a team. Use planning poker so everyone votes independently and the reveal is simultaneous.
4. Discuss disagreements. A spread from 2 to 13 means people understand the story differently. Talk it through and vote again.
5. Split large stories. If the estimate lands at the top of your scale, the story is probably too big to deliver in one sprint.

Velocity: turning points into forecasts

Velocity is the number of story points a team completes in a sprint. Only finished work counts. After a few sprints, velocity gives a rough range for how much the team usually delivers, for example 20 to 26 points.

That range is useful for forecasting. If the backlog for a release adds up to 120 points and the team completes 20 to 26 points per sprint, the release will likely take five to six sprints. It is a forecast, not a promise, and it should be updated as the team learns.

Velocity is a planning tool for the team itself. It is not a productivity score.

Common misuse of story points

Converting points to hours

Once someone declares "1 point equals 4 hours", estimates turn back into time estimates and lose the benefits of relative sizing. If you need hours, estimate hours directly.

Comparing teams

Each team calibrates its own scale. A team with a velocity of 40 is not twice as productive as a team with 20. Comparing them encourages point inflation and nothing else.

Using velocity as a target

When velocity becomes a goal, estimates quietly grow. The number goes up while actual output stays the same.

Re-estimating finished work

If a 3 turned out to be much harder, learn from it for the next similar story, but leave the original estimate alone. Changing past estimates distorts velocity.

Estimating everything with points

For a large, early backlog, story points can be more detail than you need. T-shirt sizing is often a better first pass.

Story points in practice

A typical rhythm is to estimate new stories during backlog refinement, check that the top of the backlog is sized before sprint planning, and track velocity at the end of each sprint. With Scrum Poker, the facilitator pastes the stories into the agenda, the team votes on each, and the session summary shows the total points estimated, which you can copy as text or download as CSV for your backlog tool. If you want to compare story points with other approaches, read our overview of agile estimation techniques.