The mysterious unit of measurement in agile. Not an hour, not a day, not a kilogram… and yet everyone talks about it.
What is a story point?
A story point is a relative unit that agile teams use to estimate the effort needed to deliver a user story. It combines three factors: complexity (how hard the work is), volume (how much work there is) and uncertainty (how much is still unknown). Story points are not hours: a 2-point story should take roughly twice the effort of a 1-point story, but nobody commits to a duration. Teams usually pick values from a modified Fibonacci scale (1, 2, 3, 5, 8, 13, 21) because the growing gaps reflect growing uncertainty. Each team calibrates its own scale against a reference story, so 5 points in one team does not equal 5 points in another. Story points emerged in Extreme Programming teams and were popularized by Mike Cohn's book Agile Estimating and Planning (2005). Summed over a sprint, they give the team's velocity, which drives release planning.
Story points are the unit behind most of the methods in our guide to agile estimation techniques for sprint planning.
Where do story points come from?
Story points were born in Extreme Programming (XP) teams. In his article Story Points Revisited (2019), Ron Jeffries explains that XP teams first estimated stories in "ideal days", then multiplied them by a load factor (often around three) to get calendar time. Stakeholders kept confusing ideal days with real days, so the team started calling them "points". Jeffries sums it up with a wink: "I may have invented story points, and if I did, I'm sorry now."
Mike Cohn then turned the idea into a mainstream practice with his book Agile Estimating and Planning (Prentice Hall, 2005), which pairs story points with Planning Poker and velocity.
Note that Scrum itself does not require story points. The Scrum Guide never mentions them: it only states that the Developers who will do the work are responsible for sizing it. Story points are one popular way to do that sizing, not an official Scrum artifact.
What does a story point actually measure?
Mike Cohn defines story points as the effort required to develop a backlog item, and lists what goes into that effort:
- Volume: how much work there is. Updating 200 translation keys is simple but long.
- Complexity: how technically difficult it is. A new pricing rule touching five services is hard even if the code change is small.
- Uncertainty: how much is still unknown. Integrating a payment provider the team has never used carries risk, whatever the size of the code.
The three factors are combined into a single number. The keyword is "relative": you don't measure a duration, you compare sizes. If story A is worth 2 points and story B is worth 4, B should take roughly twice the effort of A.
Most teams express points on a Fibonacci scale, where the widening gaps reflect the growing uncertainty of bigger stories.
How many hours is a story point?
There is no fixed answer, and that is the point. In Don't Equate Story Points to Hours, Mike Cohn shows that the relationship between points and hours is a distribution, not a conversion rate. In his example, one point takes about 2 hours for an experienced developer, 8 hours for a junior one, and 3.2 hours on average for the team.
Fixing "1 point = 4 hours" would destroy what makes story points useful: two people with different speeds could no longer agree on an estimate. Our comparison of story points vs person-days goes deeper into the trade-offs.
| Criterion | Story points | Hours or person-days |
|---|---|---|
| What is measured | Relative effort (volume, complexity, uncertainty) | Duration |
| Depends on who does the work | No | Yes |
| Comparable between teams | No, each team has its own scale | In theory, rarely in practice |
| Typical values | 1, 2, 3, 5, 8, 13, 21 | Any number |
| Main use | Velocity and release forecasting | Task-level capacity, billing |
How do you estimate in story points?
- Pick reference stories. Cohn recommends starting from two stories the team knows well, ideally a 2 and a 5, rather than a single 1-point story: a 1 leaves no room for smaller items, and he cites research by Magne Jørgensen suggesting that a small reference tends to make estimates too small (source).
- Compare, don't calculate. For each new story, ask: is it bigger or smaller than the 2? Closer to the 5 or to an 8?
- Vote at the same time. Planning Poker has everyone pick a card privately and reveal together, which keeps the most senior voice from anchoring the others.
- Discuss the gaps. A 2 and a 13 on the same story mean the team does not share the same understanding. That conversation is worth more than the number.
Our step-by-step guide on how to estimate an agile ticket covers the preparation side.
What is velocity, and how do story points feed it?
Velocity is the number of story points a team completes per sprint. Only stories that are fully done count: no partial credit for a story at 90%. Averaged over several sprints, velocity tells you how much the team can realistically pull into the next one, and how many sprints a backlog will take. With an average of 20 points per sprint, a 100-point release is about five sprints away. Our guide to sprint velocity details the calculation and how to forecast with a range.
Velocity is a planning tool, not a performance score. See Atlassian's guide to agile metrics for more on tracking it.
Ron Jeffries is blunt on this: comparing teams on their velocity is harmful. Because each team calibrates its own scale, a team at 40 points is not "twice as productive" as a team at 20.
What are the most common story point mistakes?
- Converting points to days. "It's a 5 because it'll take 5 days" turns points back into hours, with all the problems above.
- Comparing teams. Points only make sense inside the team that produced them.
- Turning velocity into a target. If velocity must go up, estimates inflate and the metric stops meaning anything.
- Estimating alone. A single expert's estimate hides the blind spots that a group vote surfaces.
- Keeping giant stories. A 21 is usually a signal to split before the sprint planning.
Frequently asked questions
Is one story point equal to one day of work? No. A story point has no fixed duration. Mike Cohn shows that the hours behind one point vary from person to person and form a distribution. Teams that equate one point with one day are estimating in disguised days and lose the main benefit of story points: estimates that do not depend on who does the work.
Can story points be compared between teams? No. Each team calibrates story points against its own reference stories, so a 5 in one team can be a 3 or an 8 in another. Comparing velocities between teams is therefore meaningless, and Ron Jeffries calls it harmful. Compare a team only with its own past sprints.
Who estimates story points in Scrum? The developers who will build the story estimate it in story points. The Scrum Guide states that the Developers doing the work are responsible for sizing. The Product Owner explains the need and answers questions but usually does not vote, so that their view does not anchor the team's estimate.
What is the maximum story point value for a story? There is no official maximum, but a common rule of thumb treats 13 as the upper limit for a story entering a sprint. A story estimated at 21 points or more usually hides too much uncertainty and should be split into smaller stories before the team commits to it.
Sources
- Mike Cohn, What Are Story Points?, Mountain Goat Software
- Mike Cohn, Don't Equate Story Points to Hours, Mountain Goat Software
- Mike Cohn, The Best Way to Establish a Baseline When Playing Planning Poker, Mountain Goat Software
- Mike Cohn, Agile Estimating and Planning, Prentice Hall, 2005
- Ron Jeffries, Story Points Revisited, 2019
- Ken Schwaber and Jeff Sutherland, The Scrum Guide, 2020
Put story points into practice
Ready to size your next stories? Create a free Planning Poker session, share the link and let your team vote in story points at the same time. No sign-up required. See all the features, from the Fibonacci scale to CSV and PDF export.
