What Are Story Points, and How Do You Estimate Them? A 2026 Guide

Story points are a relative measure of the effort a piece of work takes: how much there is to do, how hard it is and how much is still unknown. A team gives a small, finished story a low number and sizes everything else against it. Then it counts how many points it completes per sprint and uses that average, its velocity, to forecast. Points don’t convert to hours, and they only mean something inside the team that set them.

This guide covers agile story points estimation from the ground up: what the points include, three ways to estimate them, how they compare with hours, how velocity works in Jira, what AI changes in 2026, and what to do when someone needs a budget in dollars.

The story points concept

Story points replace “this will take 12 hours” with “this is about twice as big as that”. Comparing two pieces of work is easier than predicting time, and the comparison stays true whoever on the team picks up the task.

A user story describes one piece of functionality from the user’s side: “As a clinic manager, I want to see today’s bookings so I can plan staff.” Velocity is the average number of points a team completes per sprint.

The math is simple. Say the backlog for a release adds up to 360 points and the team completes 36 points per sprint on average. The release needs about 10 sprints. The average has to come from finished sprints, not from hope.

The Scrum Guide doesn’t mention story points at all. It only says that the developers who will do the work are responsible for sizing it. Points are a practice many teams choose, not a rule.

What do story points include?

Three things, judged together:

• Amount of work: how much there is to build and test.
• Complexity: how hard the work is to get right.
• Risk and uncertainty: unclear requirements, a technology nobody on the team has used, an outside service with poor documentation.

A short story with a big unknown can get a higher number than a long but routine one. That’s on purpose: the unknown is where the time goes.

Elements of story point estimation

To estimate in story points you need three things.

1. A reference story: a finished story everyone remembers, given a fixed number such as 3. Every new story is compared with it.
2. A scale: most teams use a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13, 20, 40, 100. Mike Cohn explains why with Weber’s law: people notice differences as a percentage. You can feel the difference between 1 kg and 2 kg, but not between 20 kg and 21 kg. After 2, each Fibonacci number is about 60% larger than the one before it, so each step is a difference people can feel (Cohn on the Fibonacci scale).
3. A technique: the three most common ones are below.

Think of holding an apple in one hand and a grapefruit in the other. Without looking, you can tell which is heavier. Two apples of different varieties are much harder. The Fibonacci gaps keep the team on the apple-and-grapefruit kind of choice.

Three ways to do agile story point estimation

Planning poker

Every developer gets a deck with the numbers on the scale. The product owner reads a story, the team discusses it, and everyone picks a card in secret. All cards turn over at once. The highest and lowest voters explain their reasons, and the team votes again. One to three rounds usually settle it (Mountain Goat Software). Read our full guide to planning poker as an agile estimation technique.

Swimlanes (affinity estimation)

This one is faster for a long list of stories.

1. Draw columns on a board, one for each number on the scale, and write each story on a sticky note.
2. The team picks the simplest story, judged on work, complexity and risk, and puts it in the 2 column.
3. The team picks a story two to three times bigger and puts it in the 5 column.
4. Everyone places the remaining stories without talking. Anyone can move a note, but has to explain the move afterwards.
5. The team walks through each column and discusses the notes that kept moving.

Full agreement isn’t required. Agree beforehand that when two estimates remain, the larger one counts.

T-shirt sizes

Here the team uses XS, S, M, L and XL. Take a simple finished story and call it XS. Then each size is roughly double the one before: S is two XS, M is two S, and so on. An XXL means the story must be split. T-shirt sizes suit a roadmap or a first look at a big backlog. Convert them to points later, when the work gets close.

Technique	Best for	Speed	Precision
Planning poker	Stories for the next two or three sprints	Slower: a few minutes per story	Highest; the discussion finds hidden work
Swimlanes	A long backlog that needs sizes this week	Fast: a whole board in one session	Medium
T-shirt sizes	A roadmap or a first look at a new product	Fastest	Low; good enough to set order

Story points vs hours

The same story can take a senior engineer a few hours and a junior engineer a few days. The points stay the same; the hours don’t. That’s the main reason teams plan sprints in points.

	Story points	Hours
What it measures	Size compared with other stories	Time one person expects to spend
Depends on who does the work	No	Yes
Comparable across teams	No	Yes, roughly
Good for	Sprint plans, release forecasts from velocity	Budgets, contracts, staffing
Breaks when	Someone converts points to hours with a fixed rule	Requirements change or the person changes

Hours still have a job. When someone has to sign a budget or a contract, they need hours and money, not points. Keep the two separate: points inside the team, hours for the people who pay.

Story points in Jira

Many teams keep their points in Jira. In the 2025 Stack Overflow Developer Survey, 46.4% of respondents named Jira among the collaboration tools they use (Stack Overflow, 2025).

Jira’s velocity chart shows two bars for each sprint (Atlassian):

• Commitment: the estimate total when the sprint started.
• Completed: the estimate total of the work finished by the end of the sprint.

Velocity is the average of the completed totals over recent sprints. In Atlassian’s own example it comes to 24.75 points, so the team can expect to complete about that much next sprint. You can count story points, original time estimates, work items or any number field. The forecast gets better as finished sprints pile up.

Story points and AI estimates in 2026

Language models can now suggest story points. A 2026 study tested four models on 16 software projects. With no training data, the models predicted story points better than deep learning models trained on 80% of each project’s data, and a few examples from the project improved them further (Shetty et al., 2026).

Use that as a first guess, not a verdict. The Scrum Guide Expanded, updated in January 2026, still leaves sizing to the people building the product, and it treats forecasting tools such as Monte Carlo simulations as helpers that don’t replace learning from what the team actually delivers.

Story point benefits and drawbacks

Benefits of story point estimation

• Estimates are fast, because the team compares stories instead of planning every hour.
• Points include risk and uncertainty, which hour estimates tend to leave out.
• Velocity comes from real, finished work, so forecasts improve every sprint.
• The discussion behind an estimate finds unclear requirements before the sprint starts.

Weaknesses of story point estimation

• Points mix work, complexity and risk into one number, so you can’t see which of them drives it.
• Converting points to hours with a fixed rule gives numbers that look precise and aren’t.
• Points from different teams can’t be compared or added up.
• Velocity changes when people join or leave, so recheck it after any change to the team.
• Points don’t answer the question a buyer asks first: what will this cost?

When an estimate turns out wrong, talk about it in the retrospective. The goal is better estimates next sprint, not blame.

When you need hours: how we turn stories into a budget

Points work once a team is running. Before that, a founder needs a number in dollars and weeks. Our project estimate uses the same raw material, user stories, and turns them into hours:

1. You describe the product in a few sentences.
2. The estimate turns your brief into user stories, and you confirm what’s in scope.
3. The stories you keep become work items with hours. We check the hours the model suggests against what our team actually books on finished projects.
4. The budget is the hours range multiplied by our published rate of $39-55 an hour. Every hour traces back to a story you kept, so unchecking a story takes its hours off.

Here is an example run of our estimate’s math with sample inputs: a local services marketplace with a client app, a provider dashboard and online payments. The work items are assumptions. Only the arithmetic is ours.

Phase	Hours
Discovery and UX: user flows for clients and providers, wireframes	22
Design: UI kit and key screens	22
Frontend: client app (search, profiles, booking) and provider dashboard	74
Backend: listings, availability, booking, payments, payouts, reviews	76
Integrations: payment provider, maps, email	19
QA: test plan and regression	24
App store and production release	8
Total	245 hours, a budget of $8,100-16,700, about 4 weeks

It’s a planning range, not a fixed quote. If you want this breakdown for your own product, see what your idea costs to build. Once the build starts, the team goes back to points and velocity for its sprints.

What we would do

1. Pick a finished story everyone remembers and make it your reference 3.
2. Size the next two or three sprints with planning poker, and the rest of the backlog with swimlanes or T-shirt sizes.
3. Run three sprints before you trust velocity. Plan on the average, not on the best sprint.
4. Never convert points to hours with a fixed rule. Estimate hours separately when you need a budget.
5. Recheck velocity whenever someone joins or leaves the team.
6. Review wrong estimates in the retrospective and update your reference stories.

In our dedicated development teams a Scrum Master runs estimation and you see velocity at every sprint review. If your estimates keep missing, read about the agile project estimation challenges behind that.

FAQ

What is a story point in agile?

A unit of relative size. It combines the amount of work, its complexity and its risk, compared with a reference story the team already finished. It doesn’t stand for a fixed number of hours.

How many hours is one story point?

There is no fixed number. A point means something only inside one team, and the same story takes different people different time. For time forecasts, use velocity: the points a team completes per sprint, averaged over recent sprints.

How do you calculate velocity?

Add up the points of the stories finished in each sprint and average the last few sprints. If a release has 360 points and the team averages 36 per sprint, plan for about 10 sprints.

Who estimates story points?

The developers who will build and test the work. The product owner explains each story and answers questions but doesn’t set the number.

Are story points part of Scrum?

No. The Scrum Guide says the developers who will do the work are responsible for sizing it, but it doesn’t name story points or any other technique. Points are a common choice, not a requirement.