Story points
STOR-ee poynts
A unit of measure for estimating the relative effort required to complete a work item in agile development.
Story points are an agile way to estimate how hard a task is without guessing how many hours it will take. Instead of saying "this will take 8 hours," a team says "this is a 5-point story." The number does not represent hours or days. It represents relative effort: a 5-point story is roughly twice as hard as a 3-point story and half as hard as an 8-point story.
Teams typically use the Fibonacci sequence for story points: 1, 2, 3, 5, 8, 13, 21. The gaps get bigger as numbers increase because estimation accuracy decreases with complexity. You can tell the difference between a 2-point and a 3-point story. You cannot meaningfully distinguish between a 17-point and a 19-point story. The Fibonacci scale forces teams to make coarse distinctions at the high end, which is more honest.
Story points are controversial. Critics say they are a layer of abstraction that obscures reality. "Just estimate in hours," they argue. Proponents say hours are misleading because they vary by developer, by interruptions, and by unknown unknowns. Story points work best as a tool for sprint planning and predicting velocity (how much can we commit to this sprint?) rather than for external reporting (when will feature X be done?).
Examples
A team estimates stories during sprint planning.
The product manager describes a feature: add a filter to the search results page. The team discusses: the backend already supports filtering, the API is ready, the UI component library has a filter component. The team estimates 3 points. The next story is building a new reporting dashboard from scratch: new API endpoints, new database queries, new UI components, and a data export feature. The team estimates 13 points. No hours discussed. Just relative effort.
A team uses story points to plan sprint capacity.
Over the last four sprints, the team consistently completes 35-42 story points. Their average velocity is 38 points. For the next sprint, the team selects stories totaling 36 points: close to average velocity with a small buffer. This is more reliable than estimating hours because it accounts for meetings, interruptions, code review time, and the natural friction of development.
A manager misuses story points to measure productivity.
The engineering manager starts comparing teams: 'Team A does 50 points per sprint, Team B does 30.' Team A inflates their estimates to look more productive. Story points become meaningless. The root problem: story points measure relative complexity within a single team. They are not comparable across teams because each team calibrates differently. The manager switches to tracking outcomes (features shipped, bugs fixed) instead.
In practice
Read more on the blog
Frequently asked questions
How many hours is a story point?
There is no conversion. That is the point. A 3-point story might take a senior developer 2 hours and a junior developer 6 hours. But the complexity is the same. Story points measure the work, not the time. If your team insists on converting to hours, you have missed the purpose. The value of story points is that they help teams plan how much work to take on without pretending to know exactly how long each task will take.
Are story points worth using?
Depends on the team. They work well for teams that need to plan sprint capacity and have learned to estimate consistently. They fail when used to compare teams, measure productivity, or set deadlines. Some high-performing teams skip formal estimation entirely and just break work into similarly sized tasks (all roughly 1-2 days). If story points are causing arguments and not helping you plan, try something simpler.
Related terms
A fixed time period (usually 1-2 weeks) in which a team commits to completing specific work.
The amount of work a team completes per sprint, measured in story points or similar units.
The prioritized list of all planned work that a team has not yet started.
The gradual, uncontrolled expansion of a project's requirements beyond the original plan.
A brief daily team meeting where each member shares progress, plans, and blockers.
Want the complete playbook?
Picks and Shovels is the definitive guide to developer marketing. Amazon #1 bestseller with practical strategies from 30 years of marketing to developers.