Story Points
Story points are a unit of relative estimation that agile teams use to express the overall effort needed to complete a backlog item. Instead of hours or days, a point value reflects the amount of work, its complexity and its risk or uncertainty, compared with items the team has already sized. A 2-point story should take roughly twice the effort of a 1-point story.
How Story Points Work
Mike Cohn, author of Agile Estimating and Planning, defines story points as an estimate of the overall effort required to fully implement a backlog item. He names three factors that feed into that single number:
- Amount of work. More screens, more fields or more cases mean more effort.
- Complexity. Intricate logic or difficult integrations take more effort.
- Risk and uncertainty. Unclear requirements or fragile legacy code without tests should raise the estimate.
Cohn stresses that points estimate effort, not complexity alone. A simple but very repetitive task can deserve as many points as a short but difficult one.
The numbers are relative. A team picks a few reference stories it understands well and sizes new work by comparison: is this bigger or smaller than the 3-point story we did last month? Most teams use a limited scale with growing gaps, often a modified Fibonacci sequence (1, 2, 3, 5, 8, 13) or doubling (1, 2, 4, 8, 16). The gaps reflect that larger items carry more uncertainty, so fine distinctions between them are not meaningful.
Estimates come from the people doing the work. The Scrum Guide does not require story points, but it does say the Developers are responsible for sizing. Many teams estimate together with techniques such as planning poker, where differing estimates start a conversation about what each person assumed. An estimate should cover everything needed to meet the Definition of Done, including testing.
Over several sprints, the total points a team completes becomes its velocity, which it can use to forecast how much backlog it can take on.
Why Story Points Matter
Relative sizing is usually faster and more consistent than estimating hours, because people are better at comparing two tasks than predicting the exact duration of one. The discussion is often more valuable than the number. When one developer says 2 and another says 8, the team discovers a hidden requirement or a technical risk before work starts.
Story points are also easy to misuse. Cohn warns against converting points into hours, and points are not comparable between teams, because each team calibrates against its own reference stories. Using points as a productivity target encourages inflation and makes forecasts less reliable.
Story Points Example
A team's reference story, "add a field to the user profile", is worth 2 points. A new backlog item asks for exporting a filtered report to CSV. The team agrees the export logic is similar to past work but notices that large reports may time out, a risk nobody has solved before. Most estimates land on 5, one developer says 8 because of the timeout risk, and the team settles on 5 after agreeing to split out a small spike to test large exports first.
Story Points vs. Time Estimates
A time estimate predicts duration for a specific person, such as "two days". A story point estimate compares effort across items, regardless of who does the work. Time estimates are useful for short, well-understood tasks. Story points are designed for planning a backlog where uncertainty is high and precision would be false.