What are story points? A practical guide

A story point is a unit of relative effort that a team assigns to a piece of work, combining how complex it is, how uncertain it is, and how much of it there is, rather than how many hours it will take. Teams compare each item against others ("this is about twice the work of that one") instead of predicting a clock time. Points are most often chosen with a scale like Fibonacci during a planning poker session. Below, what they really measure, what the evidence says, and how to use them without overpromising.

What is a story point?

A story point answers a comparative question, not an absolute one. Instead of "how many hours will this take", the team asks "how big is this compared to work we already know". A story everyone agrees is small might be a 2, something meatier a 5, something large and fuzzy a 13. The number has no fixed time attached. It is a shared, relative size.

The point of using an abstract unit is to separate the estimate from any single person's speed and from the pressure of committing to a deadline. A junior and a senior developer may take different amounts of time, but they can often agree that one item is roughly twice another.

What a story point is made of

Three things get folded into one number:

• Complexity: how intricate the work is, how many moving parts, how many systems it touches.
• Uncertainty: how much the team does not yet know. Unknowns and risk push the number up.
• Volume: how much repetitive work there is, even when each piece is simple.

This is why two items that would take similar hours can get different points. A simple change spread across forty files and a tricky algorithm in one file are both "big", for different reasons.

Why teams estimate in points instead of hours

Relative estimation is popular for reasons that are mostly about people, not math:

• It decouples the estimate from the individual. Hours depend on who does the work. Relative size is meant to be more stable across people.
• Comparison is quicker than prediction. Judging that one item is bigger than another is faster than forecasting an exact duration, so sessions move faster.
• It resists false precision. "13 points" signals uncertainty honestly. "16.5 hours" pretends to a precision nobody has.
• It drives the conversation. The real output of estimating together is not the number. It is the discussion that surfaces hidden work, as in a planning poker session.

Those are real benefits. But it is worth being honest about the part most guides skip.

What the research actually says

The common claim that story points are more accurate than hour-based estimates is not well supported by controlled studies.

In one set of controlled experiments, professional developers estimated the same tasks two ways: some gave story points, others gave work-hours. The story point estimates came out less accurate than the hour estimates, and they took longer to produce, even for developers with plenty of story point experience. The same work found that the point "size" of a task shifted a lot depending on who estimated it, which is the opposite of the developer-independent property points are supposed to have.

The pattern holds at scale. In a 2022 analysis of 37,440 real user stories across 37 open-source projects, researchers compared each team's story points against how long the work actually took. The points lined up well with real effort in only about 7% of the projects. For the rest the relationship was medium or weak, and the original human estimate was off, too high or too low, for roughly three out of every four stories. Broader reviews of agile estimation reach a milder version of the same point: story points are the most common way teams size work, but there is no solid evidence that they predict effort accurately. (Full references in Sources below.)

The honest takeaway: story points are not a reliable way to predict how long a single item will take. If you adopt them expecting precise forecasts per item, you will be disappointed, and the research explains why.

So what are story points good for?

Quite a lot, as long as you use them for the right job.

• Shared understanding. When votes diverge, the discussion reveals assumptions, missing tasks, and risk. That alignment is the real deliverable, and it is why the technique is worth the time.
• Rough forecasting over many items. Individual estimates are noisy, but across a full backlog the errors partly cancel out. Tracking how many points a team completes per sprint (its velocity) gives a usable, rough forecast, far better than summing guessed hours.
• Flagging the scary items. A 13 or a 21 is a signal: this is too big or too unknown. Split it before it hurts.
• Keeping estimation humane. Relative sizing avoids the deadline pressure and individual blame that hour estimates invite.

Notice that none of these require points to equal effort precisely. They require a team that talks and compares consistently.

How to estimate in story points

1. Pick a scale. Most teams use a Fibonacci deck (0, 1, 2, 3, 5, 8, 13, 21). The growing gaps mirror growing uncertainty, so you are not asked to split hairs between large items.
2. Choose a reference story. Agree on one well-understood item as an anchor ("this is our 3"). Estimate everything else by comparison to it.
3. Estimate together, reveal together. Use planning poker so nobody anchors on the first number spoken. The full method is in our step-by-step guide.
4. Re-estimate when you learn more. Points are a snapshot of current understanding, not a contract. Update them when the picture changes.

Story points vs. hours

Neither is magic. If a stakeholder genuinely needs a date, points alone will not give it. Velocity trends plus a conversation will get you closer than a pile of guessed hours.

Common mistakes and misuses

• Converting points to hours. A "1 point = 4 hours" table throws away the entire reason for using points and reintroduces false precision.
• Comparing velocity between teams. Points are calibrated per team. Team A's 8 is not Team B's 8. Using velocity as a productivity ranking is a well-known anti-pattern.
• Treating points as a performance metric. The moment points become a target, they get inflated and stop meaning anything (Goodhart's law in practice).
• Expecting per-item accuracy. As the research shows, a single item's points are a weak predictor of its actual time. Forecast across many items, not one.
• Never re-estimating. Points set before the work was understood are not sacred. Update them.

Frequently asked questions

Are story points the same as hours?

No. Hours are an absolute duration tied to a specific person. Story points are a relative size that combines complexity, uncertainty and volume, and are meant to be independent of who does the work.

How many hours is one story point?

There is no fixed conversion, and creating one defeats the purpose. Some teams loosely observe that a point tends to take a certain range of time for them, but that is an after-the-fact pattern, not a rule to estimate by.

What scale should we use for story points?

Fibonacci (0, 1, 2, 3, 5, 8, 13, 21) is the most common because the widening gaps reflect rising uncertainty for larger items. T-shirt sizes work for quick, rough sizing.

Are story points actually accurate?

For predicting a single item's effort, the evidence is weak: controlled studies have not shown a clear accuracy advantage over hours, and large-scale analysis found points correlate with real effort only inconsistently. Their value is in shared understanding and rough forecasting over many items, not precise per-item prediction.

Can you compare velocity between teams?

No. Points are calibrated within a team, so one team's velocity is not comparable to another's. Using velocity to rank teams encourages point inflation and is a common anti-pattern.

Who assigns story points?

The people who will do the work, together, usually in a planning poker session. The Product Owner clarifies scope but does not set the number, and the Scrum Master facilitates.

Do story points measure effort or complexity?

Both, plus uncertainty and volume. They roll several factors into one relative number, which is why two items with similar raw effort can get different points.

Sources

1. Usman, M., Mendes, E., Weidt, F. & Britto, R. (2014). Effort estimation in agile software development: a systematic literature review. PROMISE 2014.
2. Jørgensen, M. & Escott, E. Relative estimates of software development effort: are they more accurate or less time-consuming to produce than absolute estimates? (controlled experiments with professional developers).
3. Tawosi, V., Moussa, R. & Sarro, F. (2022). On the Relationship Between Story Points and Development Effort in Agile Open-Source Software. ESEM 2022 (37,440 user stories, 37 projects).
4. Pasuksmit, J., Thongtanunam, P. & Karunasekera, S. (2022). Story points changes in agile iterative development. Empirical Software Engineering.