Story points explained: what they measure, and what they don’t

A story point is a unit of relative size. It says how much effort a backlog item will take compared with other items your team already understands, folding the amount of work, its complexity and its uncertainty into one number. A 5 is bigger than a 3 and smaller than an 8. It is not five hours, and it is not five days.

Points have one job: helping a team judge how much work it can take on, based on its own track record. They are not a productivity score, a way to rank teams or a timesheet in disguise. Many complaints about story points come from asking them to do one of those other jobs, so it pays to be clear about what they measure, and what they don’t.

What is a story point?

A story point is a number a team gives a backlog item to show its size relative to other items. Mike Cohn’s Mountain Goat Software defines points as a unit of measure for the overall effort needed to fully implement a product backlog item. The key word is relative. On its own, “8 points” means nothing. Next to the team’s familiar 3s and 5s, it means “noticeably bigger than that invoice download we built last month”.

Here is how one team might size four items from the same backlog:

Those numbers belong to one imaginary team. Your team’s 5 will be different, and that is fine: points only need to be consistent within a team, not across teams.

Where story points came from

Story points grew out of Extreme Programming in the late 1990s. Early XP teams estimated in “ideal days”, roughly how long a pair would take if nobody interrupted them, then multiplied by a load factor to get calendar time. Ron Jeffries, who was there, recalls that the team started calling its ideal days simply “points”. He has since written:

“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)

The unit has gone by other names. The Agile Alliance glossary records “gummi bears” catching on just before 2000, and Joshua Kerievsky’s “Nebulous Units of Time” in 2003. Story points are not part of Scrum either: the Scrum Guide says only that the Developers who will be doing the work are responsible for the sizing, and leaves the unit to the team.

What goes into a story point: effort, complexity and uncertainty

Teams often describe points as a blend of effort, complexity and uncertainty. Mountain Goat Software puts it more precisely: points estimate effort, and the amount of work, its complexity and its risk all feed into that effort. A useful way to hold this in your head is to ask three questions of every item.

The first two examples could easily get the same number. The template update is dull but long; the VAT fix is short but delicate. If one person votes 2 for the VAT fix because “it’s only a few lines” and another votes 8 because “rounding bugs always hide edge cases”, that disagreement is the most useful thing the estimate has produced.

Uncertainty deserves special care. If there is a real chance the work will grow, for example because nobody knows whether the provider supports partial refunds, the estimate should rise, or the team should run a short, time-boxed spike first and estimate afterwards. And whatever the size, the estimate covers everything needed to finish: code, review, testing, documentation and release. In Mountain Goat Software’s words, “A story point estimate must include everything involved in getting a product backlog item all the way to done.”

Why estimate in points instead of hours?

The strongest reason is that people work at different speeds. A senior developer and someone in their first month can usually agree that an item is “about twice the size of that one”, even though they would never agree on hours. Relative sizes give the whole team a shared language without forcing anyone to pretend to be average.

Points also keep size separate from schedule. The size of “download invoices as PDFs” does not change because two people are on holiday next sprint. The team’s capacity changes, and velocity (the points a team actually finishes per sprint) absorbs it. That separation stops estimates being quietly rewritten every time the calendar changes.

Finally, a coarse relative scale is quick. Choosing between 3, 5 and 8 takes seconds; arguing whether something is 11 or 14 hours does not, and the extra precision is mostly imaginary.

Note Points are not a shortcut to accuracy. In experiments reported in 2022, Magne Jørgensen and Eban Escott found that relative estimates were less accurate and slower to produce than estimates in work-hours, and that the relative effort of the same tasks varied a lot between developers. The case for points rests on the conversation and the planning model around them, not on better numbers. A team that estimates well in hours, with nobody misusing those hours, has no urgent reason to switch.

How relative sizing works in practice

Relative sizing replaces “how long will this take?” with two easier questions: “which finished item is this most like?” and “is it bigger or smaller, and by roughly how much?” The answers land on a deliberately coarse scale, usually Fibonacci-style numbers such as 1, 2, 3, 5, 8 and 13, so nobody wastes time debating 6 against 7. Our guide to why teams estimate with the Fibonacci sequence explains the reasoning behind the gaps.

Two habits make the numbers more reliable:

• Triangulate. Check a proposed estimate against at least two known items, ideally one smaller and one larger. Does this 5 really feel bigger than the reference 3 and smaller than the reference 8?
• Treat each value as a bucket. A 13 means “bigger than an 8, and no bigger than a 13”. If an item feels like a 10, it goes in the 13 bucket rather than being squeezed into the 8.

A worked example

A team’s references include “Add ‘Remember me’ to the login page” at 3 and “Download invoices as PDFs” at 5. The next item is “Email customers a receipt when a refund is processed”. The product owner explains the goal and the acceptance criteria, then everyone votes at the same moment in a round of planning poker: 3, 3, 5, 5 and 8.

The 3s point out that the email templates already exist. The 8 explains that the payment service doesn’t yet publish a “refund completed” event, so someone will have to add one. After two minutes the team agrees the item is bigger than the login change but similar to the PDF work, settles on 5 and notes the dependency on the ticket. The number matters less than what the conversation uncovered.

How teams calibrate story points

Calibration means agreeing what each number looks like in your team’s real work. Without it, “a 5” drifts from sprint to sprint and velocity stops meaning anything. The usual approach is a small set of reference stories: finished items everyone remembers, with agreed sizes.

• Start in the middle, not at the bottom. Mike Cohn suggests identifying both a 2 and a 5 rather than starting from a 1. Research by Magne Jørgensen found that using a small story as the reference tends to make larger stories come out too small.
• Write the references down. A short table with each item, its size and one line on why is enough. New joiners can learn the scale from it in minutes.
• Review after a few sprints. If some 3s consistently turned out bigger than the 5s, ask what the team keeps missing. It is usually testing effort or hidden uncertainty.
• Keep the scale stable. Swap in fresher examples of the same size, but don’t redefine what a 3 means, or your past velocity stops being comparable.

Our step-by-step guide to setting a story point baseline with reference stories covers choosing, recording and refreshing them in more detail.

Story points and time: how they connect

Points connect to time at the level of the team and the sprint, never the individual story. The bridge is velocity: the total points of the items the team finished, meeting its Definition of Done, in a sprint. If a team usually finishes around 24 points in two weeks, a 120-point release is roughly five sprints of work.

For any single story the link is loose. One 3 takes a day, another takes four, because the relationship between points and hours is a distribution rather than a fixed rate. Over a sprint’s worth of items some run long and some run short, which is why a team can plan sensibly with numbers that are individually rough.

Martin Fowler describes the simplest version of this as “yesterday’s weather”: plan to do about as much this iteration as you did last iteration. A team that finished 21, 26, 18, 24, 25 and 22 points over its last six sprints can reasonably plan for 21 to 25 points, and treat 26 as a good sprint rather than the new normal. Our guide to velocity and forecasting goes further.

Common misuses of story points

When a team says it “hates story points”, one of these four habits is often to blame. Each one breaks the thing that makes points useful.

Comparing teams

Every team calibrates its own scale, so one team’s 5 is not another team’s 5. A team with a velocity of 60 is not doing twice the work of a team with 30; it may simply use bigger numbers for the same work. Ron Jeffries is blunt about it: “I think comparing teams on quality of estimates or velocity is harmful.” If you need one forecast across several teams, forecast each team in its own points and combine the dates, or build a shared baseline deliberately and say clearly that it is not for comparison.

Treating points as productivity

When velocity becomes a target, it stops being a useful measure. Estimates creep upwards, last quarter’s 3s become this quarter’s 5s, velocity rises and nothing extra ships. The anthropologist Marilyn Strathern put the general rule neatly in 1997: “When a measure becomes a target, it ceases to be a good measure.” If you want to know whether a team is improving, look at outcomes instead: working software in users’ hands, lead time, defects and customer results.

Converting points to days

Rules such as “one point equals one day” look tidy, but they turn points back into time estimates, and people who work at different speeds can no longer agree. Mountain Goat Software gives the example of a two-person team in which one developer is four times as productive as the other: a point is 2 hours for one, 8 hours for the other and 3.2 hours for the team as a whole. If someone needs a date, forecast a range of sprints from velocity instead of converting story by story.

Averaging the votes

If three people vote 3 and two vote 13, the average of 7 isn’t even on your scale, and it hides the fact that two people expect trouble. The gap is the information. Ask the 13s what they know, then vote again. A story point is an agreement the team can stand behind, not an arithmetic mean.

On planningpoker.org After the reveal, SprintPoker shows the average, median, most common vote and range, but a moderator picks the final estimate before pressing Save & Next, so the saved number can be the one the team agreed rather than an automatic average.

Using story points in sprint planning and forecasting

In sprint planning, velocity is a guide, not a quota. Start from your recent range, adjust for capacity (holidays, on-call duty, a new joiner who needs pairing), agree a sprint goal and pull in the items that serve it. If those items add up to well over your usual range, change the plan rather than hoping for a record sprint.

For longer forecasts, divide the remaining work by a velocity range rather than a single number. Suppose a release has 180 points left and the team finishes 24 to 30 points a sprint:

• At 30 points a sprint: 180 ÷ 30 = 6 sprints.
• At 24 points a sprint: 180 ÷ 24 = 7.5, so 8 sprints.
• Add an allowance for work you haven’t discovered yet. With 20% more scope (216 points), the forecast becomes 8 to 9 sprints.

Share the range, not the optimistic end, and update it every sprint as the backlog and velocity change. Anything estimated above 13 is usually too uncertain to plan with, so split it into smaller stories before it goes anywhere near a sprint.

When story points are not worth it

Points are a tool, not a requirement. They earn their keep when a team needs to plan sprints and forecast releases from its own history. In some situations something simpler does the job:

• Early roadmaps. When you are sizing ideas months ahead, T-shirt sizes give enough signal with far less debate.
• Small, similar items. Teams that consistently slice work small sometimes stop pointing altogether and forecast by counting finished items, an approach associated with the #NoEstimates movement.
• Flow-based teams. Kanban teams often prefer cycle time and throughput, which come straight from their board.
• Organisations that misuse them. If points are going to be converted to hours or used to rank teams, fix that first. Otherwise you get all the overhead of points and none of the benefits.

Whichever route you take, the habits behind good story points still apply: compare new work with finished work, talk about the differences, and keep items small enough to understand.