Story points: measuring complexity and capacity

8 October 2026 · 8 min read

Story points let a team size work without promising dates. On their own they are only numbers. Combined with velocity, they show how much a team can take on in a sprint. This guide covers what goes into a point, how to estimate one, and how to plan a sprint with them.

What a story point measures

A story point is a unit of relative effort. It isn't an hour or a day. It says how big a piece of work is compared with other work the team has already done. Three things feed into that size:

• Volume. How much there is to do. Adding one field to a form is less work than adding thirty, even if each field is simple.
• Complexity. How hard the work is to think through: tricky logic, many moving parts that must fit together, awkward validation rules.
• Uncertainty. What the team doesn't know yet: vague requirements, unfamiliar legacy code, a third-party API nobody has used before.

A story can be large for any of these reasons. A long but routine data migration and a short change to code nobody understands may both deserve an 8.

Why not just estimate in hours?

Hours depend on who does the work. A task that takes a senior developer two hours might take a newcomer a day, so an hours estimate is really a guess about who picks it up. Relative size doesn't change with the person: the task is still "about as big as that login fix we did last month".

People are also much better at comparing than predicting. Ask a team how long a story will take and you get optimistic answers that assume nothing goes wrong. Ask whether it's bigger or smaller than a familiar story and you usually get a sound judgement. Story points make use of that.

How to estimate with story points

Pick a reference story

Choose a small, well-understood story the whole team remembers, such as a simple bug fix, and call it a 2. Every new story is sized against it: is this about the same, twice as big, or much bigger? Keep two or three references at different sizes, for example a 2, a 5 and a 13, so comparisons stay quick.

Use a scale with growing gaps

Most teams use the Fibonacci sequence: 1, 2, 3, 5, 8, 13, 21. The gaps widen as the numbers grow because big work is harder to size precisely. Deciding between 2 and 3 is meaningful; arguing over 20 versus 21 isn't. The scale makes you choose a rough bucket instead of pretending to be exact.

Estimate together, in secret

The person who speaks first anchors everyone else. With planning poker, each person picks a card privately and all cards are revealed at once. When a 3 and a 13 appear side by side, ask the people who chose them to explain. One of them has usually spotted a risk, or a shortcut, that the others missed.

Include everyone who touches the work

A story isn't done when the code compiles. Testing, reviews, documentation and deployment all take effort, and whatever your team's definition of done includes belongs in the estimate. Testers, designers and operations people see costs developers can miss, so they should vote too.

Split anything too big to see clearly

When a story keeps landing on 13 or above, the team usually doesn't understand it well enough yet. Splitting it into smaller stories that can each be delivered on their own makes the unknowns visible, and the smaller pieces are easier to estimate and to finish within a sprint.

From points to capacity: velocity

Velocity is the number of story points a team completes in a sprint. Count only stories that are fully done; a story that is 90% finished counts as zero until it's done. One sprint's velocity tells you little. The average over the last three to five sprints is a useful guide to what the team can take on next.

Velocity is a planning tool, not a performance score. Points mean something slightly different in every team, so comparing teams by velocity is meaningless. Pushing a team to raise its velocity only teaches it to inflate its estimates.

Adjust for who is around

The average assumes a normal sprint. If availability drops, lower the target to match. Say the team's average is 28 points and one of five people is away for half the sprint. That's about 10% less capacity, so plan for roughly 28 × 0.9 ≈ 25 points.

Leave a buffer

Meetings, support requests, code reviews and helping teammates take time that never appears on the board. Many teams commit to around 80% of their average velocity and keep the rest for the unexpected. If everything goes smoothly, they pull in another story.

Plan with a range, not a single number

Velocity varies from sprint to sprint, so a range gives a more honest forecast than one number. One simple method: take your last eight sprints, sort them, and ignore the highest and lowest values. The second-lowest and second-highest give a realistic range.

Say the last eight sprints delivered 24, 31, 27, 29, 22, 33, 28 and 30 points. Sorted, these are 22, 24, 27, 28, 29, 30, 31 and 33, so the range is 24 to 31, and the average is 28. Commit the most important stories up to the low end. Treat the work between 24 and 31 as "likely, but not promised". Across several sprints, the same range turns a backlog into a release forecast that improves as you collect more sprints.

For the planning meeting itself, from the sprint goal to a sample agenda, see our sprint planning guide.

Mistakes to avoid

• Converting points to hours. Once "1 point = 4 hours" becomes a rule, you are back to time estimates with extra steps.
• Averaging the votes. A 3 and a 13 don't make an 8. They mean the team disagrees about the work, so talk it through and vote again.
• Letting one person estimate. The lead's guess hides what testers, designers and newer developers know.
• Re-pointing finished work. Changing an estimate after the fact to match how long it took erases the history you need for forecasting. Learn from the gap instead.
• Treating velocity as a promise. It is a forecast. Teams pushed to hit a number cut corners or inflate estimates, and both make the number useless.

Keep improving your estimates

Estimation improves with feedback. In retrospectives, now and then:

• Compare stories with the same estimate. Did your recent 5s really take a similar amount of effort? If one stood out, find out why: legacy code, a slow external team, unclear acceptance criteria.
• Triangulate new stories. Check a new estimate against two finished stories, one a little smaller and one a little bigger. If it doesn't fit between them, revisit it.
• Refresh your reference stories. As the team and codebase change, yesterday's "simple 2" may no longer be simple. Pick new references that everyone recognises.
• Watch for stories that keep slipping. If large estimates regularly spill into the next sprint, split stories earlier.

Estimate story points with Storyvote

Storyvote is free planning poker built for exactly this:

• Hidden votes until the reveal, so nobody anchors on the first number. You can also make voting fully anonymous.
• Fibonacci, modified Fibonacci, T-shirt sizes and powers of 2 built in, or your own custom cards.
• Per-discipline estimates. Split a story into frontend, backend and QA, for example. Each gets its own vote and the story shows the total.
• A running total. The Stories panel adds up every saved estimate, ready to compare against your velocity.

There's no account and no limit on players. See the FAQ for the details.

← All articles