Story Points Estimation in Agile
Story points estimation is a core concept in Agile and Scrum. Instead of estimating work in hours, teams use story points to measure the relative effort, complexity and uncertainty of a user story.
What are story points?
Story points are a unit of measurement used to estimate how difficult a task is compared to others. They are not tied to time, but to relative size. A task estimated at 8 points is roughly twice as complex as one estimated at 4 points.
Example
A task estimated at 8 points is roughly twice as complex as a task estimated at 4 points — regardless of who works on it or when.
Why not estimate in hours?
Time estimates are often inaccurate because different developers work at different speeds, and uncertainty is hard to quantify in hours. Story points focus on comparison rather than precision, which makes them more reliable over time.
- Time estimates vary by person and context.
- Hours create false precision on uncertain work.
- Story points scale with your team's own velocity.
The Fibonacci scale
Most Agile teams use a Fibonacci sequence for story point estimation. The gaps increase as numbers grow, which reflects higher uncertainty for larger tasks.
Fibonacci sequence used in Planning Poker
0 · 1 · 2 · 3 · 5 · 8 · 13 · 21 · 34 · 55 · 89 · ?
When a story gets a high estimate (13 or above), it is usually a signal to split it into smaller, clearer pieces before bringing it into a sprint.
How to estimate with Planning Poker
Planning Poker is the most common technique for assigning story points as a team. It works by having everyone vote at the same time to avoid anchoring — where one person's estimate influences all the others.
- The Product Owner presents the user story.
- The team asks clarifying questions.
- Each member silently selects a card from the Fibonacci deck.
- All cards are revealed simultaneously.
- The team discusses differences, especially between high and low votes.
- A second round is held if needed until consensus is reached.
Want to see this in action? Read the step-by-step Planning Poker example →
How velocity works
Velocity is the number of story points your team completes in a single sprint. It is not a performance target — it is a planning tool. Once your team has run a few sprints, its velocity becomes predictable enough to forecast future work.
Velocity example
A team consistently completes 40 story points per two-week sprint. The product backlog contains 160 points of prioritised work. The team can forecast roughly 4 sprints (8 weeks) to complete this scope — without counting hours for a single task.
Velocity fluctuates in the early sprints while the team calibrates its scale. After 3 to 5 sprints, the average stabilises and becomes a reliable input for release planning.
Best practices for story points estimation
- Compare stories, don't overthink numbers. Ask "Is this bigger or smaller than that story?" rather than "How many hours is this?"
- Split large stories. Any story estimated above 13 is usually a candidate for splitting before it enters a sprint.
- Use team consensus. The estimate reflects the whole team's understanding — developers, testers and designers — not just one expert.
- Track velocity over time. Use the average of the last three to five sprints rather than a single sprint outlier.
- Re-estimate when scope changes. If a story is significantly clarified or changed mid-sprint, update its estimate so your velocity data stays accurate.
Story points estimation — common questions
What is the difference between story points and hours?
Story points measure relative complexity and effort regardless of who does the work. Hours measure time, which varies by developer and context. Story points allow the whole team to estimate together and improve prediction accuracy through velocity tracking.
What is a good number of story points per sprint?
There is no universal answer. Teams completing 20 to 60 story points per sprint is typical, but it depends on team size, sprint length and how the scale is calibrated. What matters is that the number stays consistent over time so velocity becomes a reliable planning tool.
How do you decide what 1 story point means?
Most teams choose a simple "reference story" — a task everyone considers small and well-understood — and call it 1 or 2 points. All other stories are estimated relative to that baseline. The calibration evolves naturally over the first few sprints.
Can story points be converted to hours?
Technically yes, once you know your team's velocity. However, this defeats the purpose of story points. Use velocity for sprint planning and release forecasting. Converting points to hours reintroduces the false precision that story points are designed to avoid.