What Are Story Points? Origin, Fibonacci Scale, Velocity and Criticism

Story points are a unitless measure of how large a piece of work is relative to other work the same team has done. A team sizes backlog items in points, measures how many points it finishes per iteration (its velocity), and uses that average to forecast. Points are not hours, and they mean nothing outside the team that assigned them.

Where did story points come from?

Story points came from Extreme Programming (XP), not Scrum. Ron Jeffries describes early XP teams estimating stories in "ideal days", the time a pair would need if left alone, then multiplying by a load factor of about three. The teams renamed ideal days to points because stakeholders could not see why a day's work kept taking three days.

Jeffries recounted this in his 2019 article Story Points Revisited: a three-point story meant about nine real days, and points were mainly used to decide how much work fit into an iteration. Scrum teams adopted stories and points later. The 2020 Scrum Guide does not mention story points or velocity; it says only that Product Backlog items carry a size and that the Developers who will do the work are responsible for sizing.

How does relative sizing with story points work?

Relative sizing works by comparing each new item with a reference item the team already understands. If a familiar story is a 3, a new story that looks clearly bigger becomes a 5 or an 8. The premise is that people judge "bigger or smaller than that one" more consistently than they predict how many hours something will take.

A point usually blends three things: the amount of work, its complexity, and the uncertainty around it. Two stories with the same amount of typing can earn different points if one of them touches code nobody on the team understands.

• Pick a reference. Choose a small, well-understood item and agree on its value.
• Compare, do not convert. Size each new item against the reference, not against the clock.
• Discuss the spread. When estimates differ widely, the people at each end explain why.
• Split what you cannot size. An item too large to compare with confidence is two or more items.

Why do story points use the Fibonacci sequence?

Story points use a Fibonacci-like scale, typically 1, 2, 3, 5, 8, 13, 20, 40 and 100, because the gaps grow with size, matching how precision drops for bigger work. Mike Cohn links this to Weber's Law: people notice differences as a percentage, and each Fibonacci step after 2 is roughly 60% larger than the one before.

Cohn's illustration is weight. You can tell 1 kg from 2 kg, a 100% difference, but not 20 kg from 21 kg, a 5% difference. A linear scale such as 1 to 10 puts neighboring values too close together to tell apart at the top end. Forcing a choice between 5 and 8 is more honest than allowing a 6 or a 7.

The scale is usually applied through planning poker, which James Grenning first described in 2002 and Mike Cohn popularized in his 2005 book Agile Estimating and Planning. Each estimator picks a card face down, everyone reveals at once, and the people with the highest and lowest estimates explain their reasoning before the team estimates again.

What is velocity, and how does it turn points into a forecast?

Velocity is the number of story points a team completes per iteration, often averaged over the last three iterations. In Martin Fowler's example, a team that completes 22, 30 and 27 points has a velocity of about 26, so a 330-point release forecasts at 13 two-week iterations, roughly 26 weeks. Velocity calibrates a forecast; it does not measure productivity.

Tools build this in. Jira's velocity chart shows committed and completed work per sprint and can chart story points, original time estimates or work item count. Atlassian notes that the forecast becomes more accurate as more sprints are included and as the team's estimates improve.

Fowler also calls velocity a team measure, not an individual one, and says comparing teams by velocity is meaningless because each team uses its own baseline. There is no standard story point.

What are the main criticisms of story points?

The main criticisms are that story points get converted back into hours, turned into productivity targets, and used to compare teams. Each misuse destroys the information points were meant to carry. Once velocity becomes a goal, estimates inflate, and velocity rises without any more working software being delivered.

• Points become hours. Once someone decides a point equals half a day, the team is estimating time with an extra conversion step.
• Velocity becomes a target. Rewarding higher velocity rewards larger estimates, so the number climbs while output stays flat.
• Teams get compared. Points are calibrated inside one team, so cross-team comparisons measure estimating habits, not delivery.
• Debate replaces slicing. Time spent arguing a 5 against an 8 could go into splitting the story until the argument no longer matters.

What does Ron Jeffries think of story points now?

Ron Jeffries, who worked on the early Extreme Programming teams where points began, has turned against them. In his 2019 article Story Points Revisited he wrote that he may have invented story points and is sorry. He deplores their misuse, calls predicting "when we'll be done" from them at best a weak idea, and calls comparing teams on velocity harmful.

“I like to say that I may have invented story points, and if I did, I'm sorry now.”

— Ron Jeffries, Story Points Revisited (2019)

He also considers tracking estimates against actuals "at best wasteful". His alternative is to estimate less and slice more: split larger stories into small ones, ideally less than a day of work, using a trick he credits to Neil Killick of slicing until each story needs only a single acceptance test. Then pick the next few valuable things and do them promptly.

When stories are consistently that small, counting finished stories gives a forecast without points at all. Jira's velocity chart can already chart work item count instead of points.

When are hours better than story points?

Hours are better than story points when the estimate is for someone outside the team: a client quote, a fixed-price bid, a budget approval or a billing forecast. Clients buy time and money, and points convert to either only through a velocity history that a new engagement does not have. Hours also suit one-off tasks and teams whose membership keeps changing.

For client work the usual method is hours per role, priced with a rate card and given as a range. How to estimate a software project without guessing walks through it step by step.

For agencies and consultants who estimate that way, Keisan, the AI Project Estimation tool from Jishu Labs, works in hours and rates rather than points: "Turn a plain-English project brief into a defensible, itemized cost and timeline estimate, built from your own rate cards in minutes." It is at keisan.jishulabs.com.