What are story points?
A story point is a relative unit of measure that captures the overall effort needed to implement a user story. Rather than estimating how many hours a task will take, your team compares it to other stories and assigns a number that reflects complexity, uncertainty, and volume of work combined.
Relative sizing works because humans are better at comparing two things than predicting absolute duration. Your team might struggle to say whether a feature takes 14 or 18 hours, but they can quickly agree that it feels about twice as complex as a story they finished last sprint.
Over time, story points become remarkably consistent. Your team builds a shared vocabulary around what a 3, 5, or 8 means, and sprint velocity turns those abstract numbers into reliable forecasts. The key is consistency within the team, not comparison across teams.
Why estimate user stories?
Good estimates drive better planning and more predictable delivery.
Sprint planning
Know how much work fits in a sprint by comparing story point totals to your team's historical velocity.
Velocity tracking
Measure team throughput over time and use it to forecast future sprints with increasing accuracy.
Stakeholder communication
Set realistic expectations with product owners and stakeholders by grounding conversations in data.
Risk identification
Large estimates signal uncertainty and complexity, prompting the team to break work down or investigate further.
The estimation process step by step
A repeatable workflow that turns ambiguous backlog items into shared estimates.
Write clear user stories
Start with well-defined acceptance criteria so the team knows exactly what done looks like before estimating.
Establish a reference story
Pick a well-understood story that the whole team agrees on and assign it a baseline value, such as a 3.
Discuss as a team
Share assumptions, clarify technical approach, and surface unknowns before anyone commits to a number.
Vote simultaneously
Use planning poker to reveal all estimates at once, preventing any single voice from anchoring the group.
Converge on estimate
When votes differ, the highest and lowest voters explain their reasoning. Re-vote until the team aligns.
Common estimation scales
Choose the scale that best fits your team's workflow and comfort level.
Fibonacci
0, 1, 2, 3, 5, 8, 13, 21
The classic sequence where growing gaps between numbers reflect increasing uncertainty on larger items.
Modified Fibonacci
0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100
Includes half-point granularity for small items and larger values for epics and broad estimation.
T-Shirt Sizes
XS, S, M, L, XL
A non-numeric scale ideal for quick, high-level estimates or teams new to relative sizing.
Learn more in our planning poker vs T-shirt sizing comparison.
Common estimation mistakes to avoid
Recognizing these pitfalls helps your team estimate more accurately over time.
Estimating in hours disguised as points
Story points measure relative complexity, not time. If your team converts points to hours, you lose the benefits of relative sizing.
Letting senior members anchor the discussion
When a lead shares their estimate first, others gravitate toward it. Simultaneous reveal in planning poker eliminates this bias.
Not re-estimating when scope changes
If acceptance criteria shift after estimation, the original estimate is no longer valid. Update it to keep sprint plans accurate.
Ignoring uncertainty on large items
A 13-point story carries far more risk than a 3. Break large stories down or spike them before committing to a sprint.
Skipping the discussion after revealing votes
The conversation is the most valuable part of planning poker. Without it, you miss the shared understanding that makes estimates useful.
Frequently asked questions
A story point is a unit of measure for expressing the overall effort required to implement a user story. It combines complexity, uncertainty, and volume of work into a single relative number rather than an absolute time estimate.
Hours focus on duration which varies by person, while story points measure relative complexity which is more consistent across a team. Story points also account for uncertainty and are less likely to be treated as commitments.
Pick a well-understood user story that the whole team agrees on and assign it a reference value, such as a 3. Then estimate other stories relative to that baseline. Is it roughly twice as complex? Then it is a 5 or 8.
Estimates are meant to be directional, not precise. The goal is to distinguish small items from large ones and to plan sprints with reasonable confidence. Over time, team velocity makes estimates more predictable.
When estimates diverge, the highest and lowest voters explain their reasoning. Often this reveals different assumptions about scope or technical approach. After discussion, the team re-votes and usually converges within 2 to 3 rounds.
Continue reading
More guides on agile estimation and team practices.
What is planning poker?
Learn what planning poker is, how the estimation technique works, and why agile teams use it for sprint planning.
Read guidePlanning poker vs T-shirt sizing
Compare planning poker and T-shirt sizing estimation methods. Learn the pros, cons, and when to use each technique.
Read guideStory points vs hours
Should your team estimate in story points or hours? Compare both approaches and learn when each method works best.
Read guide