Scrum guide · Artifacts and practices
Story Points in Scrum: What They Are and How to Estimate
Story points in Scrum are relative units that Developers use to size Product Backlog items by the amount of work, complexity and uncertainty involved, rather than by hours. The Scrum Guide does not require them, but they are one of the most popular ways to size work and plan Sprints. This guide explains what story points measure, how to start estimating with them, how they feed velocity and forecasts, and the mistakes to avoid.
Key takeaways
- Story points are relative: an item is sized by comparing it with other items, not by counting hours.
- They combine the amount of work, complexity and uncertainty into one number.
- The Scrum Guide makes the Developers responsible for sizing but does not prescribe story points or any other technique.
- Start with one or two reference stories, a Fibonacci-like scale and a quick estimation session such as planning poker.
- Points completed per Sprint give your velocity, which guides Sprint Planning and release forecasts.
- Never convert points to hours, compare them between teams or use them as a performance target.
What are story points?
Story points are a unit of relative estimation used by Agile and Scrum teams to express how big a Product Backlog item is compared with other items. A story point estimate combines the amount of work, the complexity and the risk or uncertainty involved, so a 5-point item is roughly two and a half times the size of a 2-point item.
The key word is relative. People are poor at saying how many hours something will take, but quite good at saying "this is about twice as big as that". Story points use this strength. The numbers have no meaning on their own; they only mean something compared with other items the same team has estimated.
A story point estimate usually reflects three things:
- Amount of work. How much there is to do: screens, records, tests, documents, pages.
- Complexity. How hard the work is to think through: tricky logic, many integrations, unfamiliar technology.
- Uncertainty and risk. How much the team does not yet know: unclear requirements, dependencies on others, untested assumptions.
Story points do not measure business value (that is the Product Owner's job when ordering the backlog), and they are not a disguised unit of time. Think of them like sizing furniture for a removal van: you do not need to know exact dimensions to know a wardrobe is about three times the size of a chair.
The name comes from user stories, the short "As a..., I want..., so that..." format many teams use for backlog items, but you can point any Product Backlog item, whether or not it is written as a story.
Are story points part of Scrum?
No. The Scrum Guide (2020 edition, still the current official version) says that the Developers who will be doing the work are responsible for sizing Product Backlog items, and that the Product Owner may help them understand the trade-offs. It does not say how to size them. Story points, like user stories, are a complementary practice that many Scrum teams choose to add.
Story points grew out of Extreme Programming (XP) in the late 1990s and early 2000s. Ron Jeffries, one of XP's founders, has explained that teams first estimated in "ideal days" (how long a pair would take with no interruptions) and then multiplied by a load factor to get calendar time. Because stakeholders found ideal days confusing, the team started calling them "points". In a 2019 article Jeffries wrote that he may have suggested the name and is "sorry now" about how points are often misused, while also saying teams that find them valuable should carry on.
That history explains both the strengths and the criticisms of story points, which we cover below. For how Scrum fits together as a whole, see what is Scrum.
Why Scrum teams use story points
Used well, story points help a team in several ways:
- Faster estimates. Comparing items is quicker than building up hour-by-hour task lists for work months away.
- Shared understanding. Different estimates expose different assumptions. The conversation that follows is often more useful than the number.
- Uncertainty is built in. A bigger number for a riskier item signals that it needs splitting or a spike before it is ready.
- Skill-neutral. A senior and a junior developer may take very different times, but they can agree that one item is about twice the size of another.
- Better forecasts. Points completed per Sprint give a velocity that makes Sprint Planning and release forecasting more realistic.
- Earlier backlog decisions. Rough sizes help the Product Owner weigh cost against value when ordering the Product Backlog.
Story points work best for teams that are stable, work on similar kinds of items, and plan in Sprints. They add less value for a team that already splits work into small, similar items, which can simply be counted.
Story points vs hours
| Story points | Hours | |
|---|---|---|
| What they measure | Relative size: work, complexity and uncertainty | Expected elapsed or effort time |
| Who it depends on | The team, not an individual | Usually the person doing the work |
| Precision | Deliberately coarse | Looks precise, but often isn't |
| Effect of uncertainty | Raises the estimate | Often ignored or padded |
| Best used for | Sizing backlog items, velocity, release forecasts | Short tasks within a Sprint, time-and-materials billing |
| Risk if misused | Inflation when treated as a target | Becomes a deadline people are judged against |
Can you convert points to hours? Not reliably. Mike Cohn of Mountain Goat Software, who has written widely on Agile estimation, argues that each point value corresponds to a range of hours rather than a fixed number, and that the range differs between people. A 3-point item might take a senior developer half a day and a newcomer two days; both can still agree it is a 3. Fixing "1 point = 4 hours" just turns points back into hours with an extra step.
That does not make time useless. Many teams size backlog items in points and then, during Sprint Planning, break selected items into tasks of a few hours to plan the work. If your organisation needs effort figures for budgets, our guide to effort estimation covers hour-based techniques.
Story point scales
Most teams use a scale with growing gaps between the numbers. The gaps reflect the fact that bigger items carry more uncertainty, and they stop the team arguing over the difference between a 6 and a 7.
| Scale | Values | When to use it |
|---|---|---|
| Fibonacci | 1, 2, 3, 5, 8, 13, 21 | The classic choice for story points |
| Modified Fibonacci | 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100 | Common on planning poker decks; large values flag items that must be split |
| Powers of two | 1, 2, 4, 8, 16, 32 | Simple doubling; some teams find it easier to reason with |
| T-shirt sizes | XS, S, M, L, XL | Rough early sizing of epics or roadmap items; can be mapped to points later |
Planning poker decks often add special cards: 0 for trivial work, ? for "I can't estimate this yet" and a coffee cup for "let's take a break". A ? usually means the item needs refinement or a spike before anyone estimates it.
Example reference table
Each team's scale is its own, but writing down what the numbers mean to you helps new members and keeps estimates consistent. Here is an example for a web product team:
| Points | What it typically means for this team | Example |
|---|---|---|
| 1 | Tiny, well understood, almost no risk | Change a label or fix a typo in an email template |
| 2 | Small, familiar, few unknowns | Add a field to an existing form with validation |
| 3 | Our reference story: moderate, familiar work | Add a filter to an existing list page |
| 5 | Bigger or touches several parts of the system | New settings page that saves user preferences |
| 8 | Large or with real unknowns; consider splitting | Integrate a new payment option using a documented API |
| 13+ | Too big or too uncertain for one Sprint; split or spike first | Rebuild checkout for a new market |
How to estimate story points, step by step
Here is a practical way to introduce story points to a Scrum team. Steps 1–3 are one-off set-up; steps 4–8 become routine.
- Choose a reference story. Pick a recently completed item that everyone remembers, that was neither tiny nor huge, and that went roughly as expected. Give it a value, often 2 or 3.
- Add one or two more anchors. A clearly smaller item (1) and a clearly larger one (5 or 8) make comparison easier. Together these form your baseline.
- Agree the scale and the rules. Choose a Fibonacci-like scale, decide your largest acceptable size for a Sprint, and agree how you will handle bugs and spikes.
- Refine before you estimate. In backlog refinement, the Product Owner explains each item and the team clarifies acceptance criteria. Estimating unclear items wastes time.
- Estimate together. Each Developer forms a view by comparing the item with the reference stories, then everyone reveals at once, for example with planning poker.
- Discuss differences, not averages. If estimates range from 2 to 8, the highest and lowest explain their reasoning. Often one person knows something the others don't. Re-vote; settle quickly once you are close.
- Split anything too big. If an item lands above your agreed maximum, split it into smaller, still valuable pieces before it enters a Sprint. Our guide to epics, stories and tasks shows how.
- Record and review. Put the estimate on the item. Every few Sprints, look back in a retrospective: do items you called 5 really feel alike? Adjust your reference examples, not past estimates.
Planning poker in Scrum
Planning poker is the most common way to agree story points. It is quick, gives everyone a voice and avoids anchoring on the first number spoken.
- The Product Owner reads the item and answers questions.
- Each Developer privately picks a card from the scale.
- Everyone reveals at the same time.
- If the cards are close, take the most common value or agree a number and move on.
- If they differ widely, the highest and lowest estimators explain their thinking, then the team votes again.
In Scrum, the Developers vote. The Product Owner explains the item and the Scrum Master facilitates, but neither casts a card unless they are also doing the work. Remote teams can use a simple online planning poker tool or the estimation feature in their project management software.
For other techniques such as affinity estimation, bucket systems and T-shirt sizing, see our guide to Agile estimation and the Fibonacci scale.
Worked example: estimating a backlog
A team building an online booking system uses "Customer can cancel a booking from the confirmation email" = 3 points as its reference story. In refinement it estimates the next items like this:
| Backlog item | Compared with the reference | Estimate |
|---|---|---|
| Show booking reference on the confirmation page | Much smaller; one known change | 1 |
| Customer can change the time of an existing booking | Similar logic to cancelling, plus availability check | 5 |
| Send an SMS reminder 24 hours before a booking | New external SMS service; unknown rate limits | 8 |
| Add booking notes field for staff | Slightly smaller than the reference | 2 |
| Customer can pay a deposit when booking | Payments, refunds, security review: too big and uncertain | 13 (split first) |
| Export the day's bookings to CSV | About the same as the reference | 3 |
The 13-point deposit item is too large to finish safely in one Sprint, so the team splits it into "Pay deposit by card (happy path)", "Refund deposit on cancellation" and a short spike on the payment provider's test environment. The SMS item gets an 8 mainly because of uncertainty; once the team has used the SMS service once, similar items will probably shrink.
Notice that the team never mentions hours. Each number is a comparison with the 3-point reference.
Who estimates story points and when
| Role | Part in estimation |
|---|---|
| Developers | Estimate the items, because they will do the work. Everyone who contributes to the Increment, including testers and designers, takes part |
| Product Owner | Explains items, answers questions and uses estimates to make ordering decisions; does not set or negotiate the numbers |
| Scrum Master | Facilitates, keeps sessions short and protects the team from pressure to change estimates |
| Stakeholders | May ask for forecasts, but do not estimate |
Most estimation happens during backlog refinement, so that items near the top of the backlog are already sized when Sprint Planning starts. The team may re-estimate in planning if its understanding has changed significantly. Once a Sprint has started, most teams leave the estimate alone and learn from any difference in the retrospective.
Only estimate a few Sprints ahead. Items far down the backlog are likely to change, so give them rough T-shirt sizes and point them properly when they come closer.
From story points to Sprint Planning and forecasts
Story points become useful when you add them up. The total points of items fully Done in a Sprint is the team's velocity. Items that are not Done score nothing, however close they are; this is what keeps velocity honest.
Using velocity in Sprint Planning
Suppose a team's last three Sprints delivered 28, 33 and 30 points. Its average velocity is about 30 points. Next Sprint, one of six Developers is on leave for the whole two weeks, so the team expects roughly five-sixths of its usual capacity: about 25 points. In Sprint Planning it pulls items from the top of the backlog until it reaches around 25 points that fit a coherent Sprint Goal, and stops there.
This is a guide, not a quota. The Developers still decide how much they can take on, and the Sprint Goal matters more than hitting a total. Our guide to Agile capacity planning explains how to account for holidays and other commitments.
Forecasting a release
If 150 points of estimated work remain before a release and velocity has ranged from 25 to 33, the release is likely to take 5 to 6 Sprints (150 ÷ 33 ≈ 4.5 and 150 ÷ 25 = 6). Always give a range, and update it every Sprint as velocity and the backlog change. A velocity chart makes the trend easy to show.
Bugs, spikes and unfinished work
Teams handle these differently. What matters is choosing a rule and applying it consistently, so velocity stays comparable from Sprint to Sprint.
- Bugs found in work from the current Sprint are part of finishing that item. Don't point them separately; the item isn't Done until they are fixed.
- Bugs from earlier work or production are new Product Backlog items. Many teams point them like any other item so the effort shows in velocity; others keep a small, unpointed allowance for them. Either works if you are consistent.
- Spikes (time-boxed research to reduce uncertainty) are usually time-boxed rather than pointed, or given a small fixed value. Their output is knowledge that lets the team estimate the real item.
- Technical debt work can be pointed like features so it competes fairly for space in the backlog. See technical debt in Scrum.
- Unfinished items return to the Product Backlog. Don't split the points between Sprints; re-estimate the remaining work if it has changed, and count it when it is Done.
Common story point mistakes
| Mistake | What happens | Better approach |
|---|---|---|
| Converting points to hours | Points become a slower way of estimating time, and individual speed creeps back in | Use velocity to answer time questions |
| Comparing teams by velocity | Each team's scale differs, so comparisons are meaningless and encourage inflation | Compare each team only with its own past |
| Using points as a performance target | Estimates inflate and velocity rises while output doesn't | Treat velocity as a planning aid owned by the team |
| The Product Owner or a manager sets estimates | Developers lose ownership and estimates lose accuracy | Let the people doing the work estimate |
| Spending too long estimating | Refinement drags and the team avoids it | Time-box each item; park anything that needs more refinement |
| Estimating huge items | Large estimates hide uncertainty and spill over | Split before the item enters a Sprint |
| Giving partial credit | Velocity overstates progress | Count only items that meet the Definition of Done |
| Re-estimating finished work | Velocity history becomes unreliable | Leave past estimates alone; adjust reference stories instead |
Velocity is one of several useful measures.
Criticisms and alternatives to story points
Story points have critics, including some of the people who popularised them. Common concerns are that teams spend too long debating numbers, that managers treat velocity as a productivity score, and that points give a false sense of precision. These are mostly problems of misuse, but they are real.
If story points are not helping your team, consider these alternatives:
- Counting items. If the team splits work into small items of broadly similar size, simply counting items finished per Sprint often forecasts as well as points, with no estimation meetings.
- Throughput and probabilistic forecasting. Use historical throughput and a Monte Carlo simulation to produce forecasts with confidence levels, such as "85% likely by 14 March".
- T-shirt sizing. Coarse S/M/L sizes are enough for roadmap and epic-level decisions.
- #NoEstimates. A movement that questions detailed estimation altogether and focuses on slicing work small and forecasting from flow. See Kanban planning for how flow-based teams plan.
Whichever method you use, the Scrum Guide's requirement stays the same: the Developers size the work in a way that helps them plan Sprints and helps the Product Owner make decisions.
Story point templates and tools
- Sprint planning template: Sprint Goal, capacity, selected items with story points, owners and tasks.
- User story template: story, acceptance criteria, epic and estimate in one place.
- Product backlog template: an ordered backlog with value and estimate columns.
Most Scrum tools include an estimate field and velocity reports. Jira has story point estimation built into its Scrum boards and reports, which is why it is popular with software teams.
Free templates for this topic
Frequently asked questions
What is a story point in Scrum?
A story point is a relative unit Developers use to estimate the size of a Product Backlog item, combining the amount of work, complexity and uncertainty. It is compared with other items the team has estimated and is not a measure of hours.
Are story points required in Scrum?
No. The Scrum Guide makes the Developers responsible for sizing Product Backlog items but does not prescribe a technique. Story points are a popular, optional practice that came from Extreme Programming.
Who estimates story points?
The Developers who will do the work, including everyone who contributes to the Increment such as testers and designers. The Product Owner explains items and the Scrum Master facilitates, but neither sets the estimates.
How do you calculate story points?
You don't calculate them from a formula. Pick a reference item, give it a value such as 3, then compare each new item with it and choose the closest number on your scale, usually as a team using planning poker.
How many hours is one story point?
There is no fixed conversion. A point represents a range of effort that differs between people and items. If you need a time view, use velocity: the number of points the team usually completes in a Sprint.
Why are story points based on the Fibonacci sequence?
The widening gaps between numbers such as 5, 8 and 13 reflect the greater uncertainty of larger items and stop teams debating false precision, such as whether an item is a 6 or a 7.
What is a good story point size for an item?
Small enough to finish comfortably within one Sprint, ideally in a few days. Many teams agree a maximum, often 8, and split anything larger before it enters a Sprint.
How many story points should a team complete per Sprint?
There is no correct number. It depends on the team's own scale, size and Sprint length. Use your recent average velocity, adjusted for capacity, as a guide for Sprint Planning.
Can story points be compared between teams?
No. Each team calibrates points against its own reference items, so a 5 in one team is not a 5 in another. Comparing teams by points or velocity encourages inflation.
Should bugs be given story points?
Bugs in work from the current Sprint are part of finishing that item and are not pointed separately. Bugs from earlier work can be pointed like any other backlog item; the key is to be consistent.
What does a 0 or a question mark card mean in planning poker?
A 0 means the work is trivial. A question mark means the estimator does not understand the item well enough to size it, which usually means it needs more refinement or a spike.
What is the difference between story points and T-shirt sizes?
T-shirt sizes (XS to XL) are a coarser relative scale used for early or roadmap-level sizing. Story points give finer numbers that can be added up for velocity and Sprint Planning.
Can you change story points after Sprint Planning?
Most teams leave estimates unchanged once the Sprint starts, so velocity reflects the original plan. If an item turns out much bigger, the team talks to the Product Owner and may split it or return part to the backlog.
Is #NoEstimates an alternative to story points?
Yes. #NoEstimates is a movement that questions detailed estimation and instead slices work into small items and forecasts from throughput. It works best when items are consistently small.