If you're new to agile development, story points can seem confusing. Why not just estimate in hours? What does Fibonacci have to do with software development? And how can different teams have wildly different point scales yet both claim to be "doing it right"?
This beginner's guide will answer all these questions and more, giving you a solid foundation for understanding and using story points effectively from day one.
What Are Story Points?
Story points are a unit of measure for expressing the overall effort required to fully implement a user story or other work item. Unlike hours, which attempt to measure time, story points represent the combination of:
- Complexity: How difficult is this work? Does it involve intricate logic, edge cases, or unfamiliar technology?
- Uncertainty: How well do we understand the requirements? Are there unknowns that might surface during development?
- Effort: How much work is involved? Does this require changes across multiple systems, extensive testing, or significant documentation?
Together, these three dimensions—Complexity, Uncertainty, and Effort (CUE)—determine a story's point value. A story might score high points because it's technically complex, or because requirements are unclear, or simply because it involves a lot of work, even if straightforward.
Why Use Story Points Instead of Hours?
This is the most common question from teams new to agile. If the goal is understanding how long something takes, why not just estimate in hours?
Hours Create False Precision
When you estimate "8 hours" for a task, stakeholders treat it as a commitment. If it actually takes 12 hours, you're "behind schedule." But software estimation is inherently uncertain—there are always unknown factors that emerge during implementation.
Story points acknowledge this uncertainty. A 5-point story might take different developers different amounts of time, and that's okay. What matters is that the team, collectively, has a shared understanding of the story's relative size.
Points Are Relative, Not Absolute
Story points work on relative comparison. You pick a baseline story (often a medium-sized one) and assign it a reference number—let's say 5 points. Then you estimate other stories relative to that baseline:
- Is this story about the same complexity? It's also a 5.
- Is it roughly twice as complex? Call it a 13 (more on Fibonacci later).
- Is it simpler? Maybe a 2 or 3.
This relative approach is faster and more accurate than absolute time estimation because human brains are better at comparing things than estimating absolute values.
Points Abstract Away Individual Differences
A senior developer might complete a task in 2 hours while a junior developer takes 6 hours. With hour-based estimation, this creates problems—do you estimate based on who's doing the work?
Story points sidestep this issue. The story is still a 5 regardless of who implements it. Your team velocity (points completed per sprint) naturally accounts for team composition without needing individual tracking.
Understanding the Fibonacci Sequence
Most agile teams use a modified Fibonacci sequence for story points: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, and sometimes 100. Each number is approximately the sum of the previous two numbers (1+2=3, 2+3=5, 3+5=8, etc.).
Why Fibonacci Instead of Linear Numbers?
You might wonder: why not just use 1, 2, 3, 4, 5, 6, 7, 8, 9, 10? The Fibonacci sequence's expanding gaps reflect a crucial truth about estimation uncertainty.
When work is small and well-understood (1, 2, 3 points), we can estimate with reasonable precision. The difference between a 2-point and 3-point story is meaningful and fairly easy to identify.
But as stories get larger and more complex, uncertainty increases exponentially, not linearly. Once you're in the 13-21 point range, trying to distinguish between "14 points" and "15 points" is meaningless—the uncertainty is too high for that level of precision.
The Fibonacci gaps force you to acknowledge this reality. You can't agonize over whether something is a "14" or "15"—those options don't exist. It's either a 13 or a 21. And if there's that much uncertainty, maybe the story is too large and needs splitting.
The Magic 60% Jump
Research shows that each Fibonacci number represents approximately a 60% increase over the previous number. Even as the numbers grow huge, our brains can still perceive a 60% difference consistently. This makes Fibonacci a sustainable scale even for large backlogs.
Modified Fibonacci for Practicality
Purists note that true Fibonacci includes 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89... But agile teams typically modify it to: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100.
The modifications:
- 0 points: For truly trivial work (fixing a typo, updating a config value)
- 0.5 points: For very small but not quite zero tasks
- 20 instead of 21: Easier to work with in calculations
- 40 and 100: Round numbers for "way too large" stories that need splitting
How to Estimate Your First Stories
Starting with story points from scratch can feel overwhelming. Here's a step-by-step approach for teams new to this practice:
Step 1: Select Your Baseline Story
Look through 10-15 recently completed or well-understood tasks. Pick one that feels medium complexity—not the simplest, not the hardest. This becomes your reference point.
Assign this baseline story 5 points. (Some teams use 3 or 8, but 5 is most common because it sits nicely in the middle of your scale.)
Example baseline: "As a user, I want to reset my password via email so I can regain account access if I forget my credentials."
Step 2: Estimate Relative to Your Baseline
Now take another story and ask: "Compared to our 5-point password reset story, how complex is this?"
- Much simpler? Maybe a 1 or 2
- Somewhat simpler? Probably a 3
- About the same? Also a 5
- More complex? Likely an 8 or 13
- Way more complex? Could be 21 or higher (consider splitting)
The conversation during this comparison is more valuable than the number itself. Different team members bring different perspectives, and discussing why they see something as more or less complex builds shared understanding.
Step 3: Use Planning Poker
Planning poker (also called Scrum poker) is the most popular technique for collaborative estimation. Each team member gets cards with Fibonacci numbers. When estimating a story:
- Product owner reads the story and acceptance criteria
- Team asks clarifying questions
- Each person privately selects a card representing their estimate
- Everyone reveals simultaneously
- If estimates differ significantly, high and low estimators explain their reasoning
- Team discusses and re-votes until reaching consensus
You can run planning poker sessions using free online tools, especially useful for remote teams.
Step 4: Calibrate Over Time
Don't expect perfect estimates from day one. As you complete stories and track velocity, your understanding of what constitutes a "5" or an "8" will naturally calibrate. After 3-4 sprints, your estimates will be significantly more accurate.
Common Beginner Mistakes (And How to Avoid Them)
Mistake 1: Converting Points Back to Hours
New teams often want to establish a conversion: "1 point = 4 hours." Don't do this. The moment you convert back to hours, you lose all the benefits of story points. Stakeholders will treat the hours as commitments, and you're back to the problems that story points were meant to solve.
Use points for planning, track velocity in points, and forecast in points. Let go of hours entirely.
Mistake 2: Assigning Points Based on Who's Doing the Work
"This is a 3 if Sarah does it but an 8 if Bob does it." No. Story points reflect the work itself, not the person implementing it. Estimate based on team average capability.
If there's truly a skill gap where only one person can do certain work, that's a team composition problem to address, not an estimation problem.
Mistake 3: Splitting Effort Across Multiple People
"If this is 8 points for one person, it's 4 points if two people pair on it." Story points measure work, not duration. Whether one person spends 2 days or two people spend 1 day each, it's still the same amount of work—same complexity, same uncertainty, same effort.
Points don't change based on how you allocate people. Your velocity accounts for team capacity naturally.
Mistake 4: Over-Estimating to "Be Safe"
Padding estimates destroys velocity as a planning tool. If you estimate a 3-point story as 5 "just in case," and then complete it in the time a 3-point story should take, your velocity inflates artificially. Future planning based on this inflated velocity will be inaccurate.
Estimate honestly. If you consistently miss estimates, that data is valuable—it might indicate technical debt, unclear requirements, or unrealistic sprint goals. Hiding that signal with padding prevents you from addressing root causes.
Mistake 5: Forgetting to Include Testing, Review, and Deployment
Story points should reflect all work needed to meet your Definition of Done, including:
- Writing automated tests
- Code review
- Manual QA testing
- Documentation updates
- Deployment and smoke testing
A story isn't "done" when coding finishes—it's done when it's production-ready. Your estimates should reflect this full scope.
Mistake 6: Estimating Tasks Instead of Stories
Some teams try to estimate individual technical tasks in story points. This is backwards. You estimate user stories (the complete feature or capability), not the implementation tasks.
During sprint planning, after estimating the story in points, you might break it into tasks. But those tasks typically don't have point estimates—you might estimate tasks in hours if you need that detail, or not estimate them at all.
Story Point Ranges: What They Mean
Understanding typical ranges helps contextualize your estimates:
- 0-1 points: Trivial work. Config changes, typo fixes, simple copy updates. Takes minutes to an hour.
- 2-3 points: Small stories. Straightforward features with clear requirements and minimal uncertainty. Usually completed in less than a day.
- 5-8 points: Medium stories. Typical sprint work with moderate complexity. Some uncertainty but manageable. Takes 1-3 days.
- 13 points: Large story. Significant complexity or uncertainty. Ideal candidate for splitting but can be completed within a sprint by a focused developer.
- 21+ points: Too large. These should almost always be split into smaller stories. If you can't split it, it might need a research spike first to reduce uncertainty.
When to Split Large Stories
If a story is 13 points or larger, seriously consider splitting it. Large stories have several problems:
- Higher risk of incomplete work at sprint end
- Delayed feedback (nothing to demo until the entire story completes)
- Less accurate estimates (uncertainty compounds with size)
- Harder to parallelize work across team members
Common splitting techniques include:
- Workflow steps: Registration → Verification → Profile Setup
- CRUD operations: Create → Read → Update → Delete as separate stories
- Business rule variations: Simple case → Complex case with edge handling
- Interface types: Web interface → Mobile interface → API
Story Points vs. Other Estimation Methods
T-Shirt Sizing
Some teams use T-shirt sizes (XS, S, M, L, XL) instead of Fibonacci numbers. This works similarly but with less granularity. T-shirt sizing is great for high-level roadmap planning but less useful for sprint-level sprint planning.
Many teams use both: T-shirt sizes for initial backlog grooming, then convert to Fibonacci points for stories entering upcoming sprints. Learn more about when to use each method.
Ideal Days
"Ideal days" estimate how many days of uninterrupted, focused work a task would take. This is better than actual hours but still ties estimation too closely to time. Most modern teams prefer pure story points.
No Estimates (#NoEstimates)
Some teams practicing continuous delivery skip estimation entirely, focusing on keeping work small and maintaining consistent throughput. This can work for mature teams with truly consistent story sizes, but most teams benefit from the planning visibility that story point estimation provides.
Tracking and Using Story Points
Once you start estimating in story points, you'll use them for:
Velocity Tracking
Sum the points for all completed stories each sprint. This is your velocity. Track it over 3-5 sprints to establish an average. Use that average for planning future sprints.
Sprint Planning
If your average velocity is 23 points, aim to commit to roughly 23 points worth of stories in the next sprint. Don't overcommit to 35 points hoping to go faster—respect your historical data.
Release Forecasting
If you have 200 points of work in your backlog and average velocity of 25 points per sprint, you can forecast approximately 8 sprints to completion (200 ÷ 25 = 8). Add some buffer for uncertainty, and you have a realistic timeline.
Getting Started: Your First Sprint
Ready to start using story points? Here's a 2-week action plan:
Week 1: Setup
- Day 1: Read this guide as a team. Discuss any questions or concerns.
- Day 2: Select your baseline story and assign it 5 points.
- Day 3: Practice estimating 10 past stories relative to your baseline. Compare estimates and discuss differences.
- Day 4: Choose your planning poker tool if working remotely.
- Day 5: Hold your first real estimation session for upcoming sprint work.
Week 2: First Sprint
- Complete your sprint normally, tracking which stories finish.
- At sprint end, sum points for completed stories. This is your first velocity data point.
- In retrospective, discuss what worked and what didn't with story point estimation.
- Adjust your approach based on learnings and plan the next sprint.
Don't expect perfection immediately. Estimation is a skill that improves with practice. After 3-4 sprints, you'll have reliable velocity data and much better estimation accuracy.
Conclusion: Points Are a Tool, Not a Goal
Story points exist to help teams plan more effectively and deliver value more predictably. They're a tool for the team, not a metric for management to measure productivity.
Remember the core principles:
- Points measure complexity, uncertainty, and effort—not time
- Estimate relatively, not absolutely
- Use Fibonacci to acknowledge increasing uncertainty at larger sizes
- Focus on team consensus, not individual estimates
- Let velocity stabilize over several sprints before trusting forecasts
- Never compare points across teams
Start simple, stay consistent, and adjust based on what you learn. Story points will become a natural part of your team's rhythm, enabling more realistic planning and better delivery predictability.
Want to improve your agile practices? Check out our guides on running effective remote estimation sessions and explore more resources on the Journaleus network.