What Are Story Points in Agile?

How story points work

A story point has no fixed size. The team picks a small, well-understood item as a reference, such as adding a field to an existing form, and calls it a 2. Every other item is sized against that: roughly twice the work and uncertainty, roughly twice the points.

Points describe the whole item, not one person’s share. A 5-point story includes the questions, code, review, tests and deploy needed to meet the team’s Definition of Done. After a few sprints, the team learns how many points it typically finishes, called velocity, and uses that to plan.

Story points aren’t part of the Scrum Guide, which leaves estimation technique to the team. They grew out of Extreme Programming practice and were popularized by Mike Cohn’s writing on agile estimating and planning.

Why use story points instead of hours?

Hours feel more precise, but points tend to hold up better for planning:

• Relative sizing is quicker and more consistent. Saying "this is about twice that" is easier than predicting exact hours.
• One estimate works for the whole team, regardless of who picks up the item or how fast they are.
• Uncertainty is part of the number, so a risky item gets a bigger estimate even if the happy path looks short.
• Velocity absorbs overhead. Meetings, reviews and interruptions are already reflected in how many points the team finishes, so you don’t subtract them by hand.
• It avoids false precision and the temptation to treat an estimate as one person’s deadline.

The story point scale, and why Fibonacci

Most teams use a modified Fibonacci sequence, the one printed on most planning poker decks. The gaps widen as the numbers grow, which mirrors how uncertainty grows with size. It’s hard to tell a 7 from an 8, but easy to tell a 5 from an 8, so the scale forces a choice instead of a debate over one point.

• 1: trivial and well understood, such as a copy change or a config flag.
• 2: small, with little risk.
• 3: a routine story that touches a few parts of the code.
• 5: a normal-size story with some unknowns.
• 8: large, with several moving parts or open questions. Check whether it can be split.
• 13: very large. Usually a sign the story should be split before it enters a sprint.
• 20, 40, 100: rough sizes for epics and ideas, not sprint-ready work.
• ?: not enough information to estimate yet.

What does 1 story point mean?

Whatever your team decides, as long as it stays consistent. Usually 1 is the smallest item still worth tracking, and the rest of the scale is calibrated against two or three reference stories the whole team remembers.

Because each team calibrates differently, a point on one team isn’t a point on another. Comparing velocity across teams, or adding up points from different teams, produces numbers that look precise but don’t mean much.

Some new teams anchor 1 point to about half a day to get started. That can help early on, but it quietly turns points back into hours, so drop the anchor once you have reference stories.

Who estimates, and how planning poker works

The people who will do the work estimate it; in Scrum terms, the Developers. The Product Owner explains the item and answers questions but doesn’t set the number, and neither does a manager.

Planning poker, popularized by Mike Cohn, is the most common way to run the session. The discussion is often worth more than the number: a spread from 2 to 13 means people picture different work, and that’s what you want to find before the sprint starts.

• The Product Owner reads a story and its acceptance criteria.
• The team asks questions until the scope is clear enough to estimate.
• Each person privately picks a card from the scale.
• Everyone reveals at once, so the first voice doesn’t anchor the rest.
• The highest and lowest estimators explain their reasoning.
• The team re-votes until estimates converge, then records the number.

How many story points per sprint?

There’s no right number. It depends on team size, sprint length, how the team calibrated its scale and how much of each sprint goes to support or unplanned work. A team that finishes 20 points and one that finishes 60 may be equally productive.

To find yours, run two or three sprints, total the points of items that met the Definition of Done in each, and use the average as a planning guide. Partly done work earns nothing until it’s done. Recheck when people join or leave the team.

Treat velocity as a forecasting tool, not a target. When points become a performance metric, estimates inflate and the number stops being useful for planning.