What are story points?
Story points are a unit of measure used in agile software development to express the overall effort required to fully implement a backlog item. They encode complexity, amount of work, and risk — not time. A story point estimate is a relative value: it tells you how big a story is compared to other stories, not how many hours it will take.
Why agile teams use story points instead of hours
Hour-based estimation seems precise but consistently fails in practice. It anchors the team to individual productivity, ignores uncertainty, and creates false accountability for predictions that are, at best, educated guesses.
Story points reframe the question from "how long will this take you?" to "how complex is this compared to something we've already done?" That shift produces more honest, more stable estimates — and it separates effort from calendar time, which is particularly valuable for teams with varying individual productivity levels.
The key difference
- Hours estimate duration based on one person's speed. They are affected by meetings, interruptions, illness, and individual skill level.
- Story points estimate effort as a team-level property. A story is an 8 regardless of which team member works on it. The team's sprint capacity translates points into time.
- This abstraction feels counterintuitive at first. After 3–4 sprints, most teams find their sprint-to-sprint velocity more predictable than their hour-based estimates ever were.
What story points actually measure
A well-calibrated story point estimate captures three dimensions of work:
- Complexity: how many moving parts does the solution have? Does it touch multiple systems, require careful state management, or involve non-trivial algorithms?
- Volume: how much work is there? A story that requires changes to eight files is larger than one that changes two, even if neither is technically difficult.
- Uncertainty: how well does the team understand the solution? A story with clear requirements and a known approach gets a lower point value than a similarly complex story with multiple unknowns.
Common story point scales
The Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) is the most widely adopted scale. The non-linear progression forces teams to choose meaningful size brackets rather than arguing about the difference between 6 and 7.
Some teams use a modified Fibonacci (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100) to accommodate both tiny tasks and large epics. Others use powers of 2 or t-shirt sizes for early-stage estimation when granularity isn't yet possible.
- 1, 2, 3, 5, 8, 13, 21 — standard Fibonacci. Best for teams doing sprint-level estimation.
- 1, 2, 4, 8, 16, 32 — powers of two. Preferred by engineering-heavy teams for its mathematical clarity.
- XS, S, M, L, XL — t-shirt sizes. Best for early discovery and roadmap planning before stories are refined.
How to start estimating in story points
Starting with story points is easier than most teams expect. The key is to establish anchor stories — well-understood completed stories that serve as calibration references for new estimates.
Step 1: Choose a reference story
Find a recently completed story that the team agrees was a clear, well-understood, medium-effort piece of work. Assign it 3 or 5 points depending on whether it felt smallish or medium. This becomes your baseline.
Step 2: Estimate relative to the reference
For each new story, the team asks: "Is this larger or smaller than our 3-point reference? By how much?" Vote simultaneously using planning poker to prevent anchoring, then discuss diverging votes.
Step 3: Track velocity over 3–4 sprints
After a few sprints, calculate your rolling average velocity (total points completed per sprint). Use this as your capacity input for sprint planning.
Try story point estimation with your team using free online planning poker — no signup required.
Story points FAQ
Are story points the same as ideal days?
No. Ideal days are an estimate of how long a story would take if a developer worked on it uninterrupted. Story points are team-level relative measures that include uncertainty and complexity, not just duration.
Do story points need to add up to anything?
Within a sprint, the total points should not exceed your team's capacity (expressed in points through velocity). Across sprints, total points are tracked as velocity and used for forecasting.
Why does our velocity keep changing?
Velocity changes when team composition changes, when the types of stories change, or when the team's definition of what constitutes a point drifts. Check for scale drift if velocity changes without an obvious cause.
Can different teams compare their story points?
No. Story points are meaningful within a team, not between teams. A team of 6 completing 50 points per sprint is not necessarily more productive than a team of 4 completing 30 — their scales are independent calibrations.
Should estimates include testing and code review?
Yes. A story point should represent the full effort to bring a story to Done, including development, testing, code review, and any other work your Definition of Done requires.