Skip to content

story points

Story points are a unit of measure an agile team uses to estimate the relative effort of a backlog item, rather than the time it will take in hours. A single number folds three things together: the amount of work, the technical complexity, and the risk or uncertainty in the task.

Only the ratios between estimates carry meaning, so a 5-point story should represent about five times the effort of a 1-point story, whatever a point works out to in calendar time. Teams estimate this way because people compare sizes far more reliably than they predict durations.

A developer who cannot say whether a feature will take three days or six can still judge that it is bigger than one story and smaller than another, and relative sizing turns that judgment into a number the whole team shares.

How It Shows Up in Practice

A Python developer first meets story points during sprint planning or backlog refinement, where the team sizes upcoming work one item at a time. The agreed number goes into an estimate field on a tracking tool such as Jira, Linear, or Azure Boards, and a point total only means anything once the team agrees what counts as done, so estimation usually rides alongside a shared definition of done.

The most common way to land on a number is planning poker, a technique James Grenning introduced in 2002. Each estimator privately picks a card from a deck of values on a modified Fibonacci scale of 1, 2, 3, 5, 8, 13, 20, 40, and 100. Everyone reveals at once, and the high and low voters explain themselves before the group re-votes toward consensus:

Flowchart loop. Teal "Pick a card privately" box leads to "Reveal all", then a "Estimates agree?" diamond. Yes goes to a yellow "Record the estimate"; no goes to "Voters explain" and loops back.
Disagreement sends the team back for another private vote, the loop that drives consensus.
Language: Text 
Story: "Add CSV export to the reports page"
  reveal 1   ->  Ana 5    Ben 3    Cat 8
  discuss    ->  Cat flags an untested legacy serializer
  reveal 2   ->  Ana 5    Ben 5    Cat 5
  estimate   ->  5 points

The points a team finishes each sprint sum to its velocity, the figure used to forecast how much of the backlog fits into future sprints. A team averaging around 21 points a sprint can expect a 130-point backlog to take roughly six more sprints to clear.

Common Pitfalls

The recurring mistake is pinning a point to a fixed amount of time. The moment a team decides that 1 point equals half a day, the estimate inherits every weakness of an hours-based guess and loses the speed that made relative sizing worthwhile.

Velocity invites a second mistake, which is reading it as a productivity score. The figure is calibrated to one team’s scale, so comparing the velocities of two teams measures nothing, and rewarding a bigger number mostly teaches people to inflate their estimates.

A third trap is forgetting that risk lives inside the figure. A small change to brittle code carrying heavy technical debt can earn more points than a large change to clean code, because the unknowns, not the line count, drive the effort. High estimates on familiar work are the cue to revisit what the team counts as done, not evidence that someone padded the number.

Getting Started With Testing in Python

Course

Test-Driven Development With pytest

In this hands-on course, you’ll see how to create Python unit tests, execute them, and find the bugs before your users do. You’ll learn about the tools available to write and execute tests, check your application’s performance, and even look for security issues.

intermediate testing

For additional information on related topics, take a look at the following resources:

By Martin Breuss • Updated June 22, 2026
Software Engineering Glossary Share Feedback