Glossary
Story points measure relative effort in agile development. Learn when to use them, how to calibrate, and common estimation pitfalls.
At Salesken, I watched an engineer game our story point system for an entire quarter. His 'velocity' was double anyone else's. His actual output? About average.
Story point estimation is a method of measuring the relative effort or complexity of user stories and tasks in software development. Instead of estimating in hours or days, teams assign story points to work items.
Story points are abstract units. "Feature A is 5 points. Feature B is 3 points." Meaning: Feature A is bigger/more complex than Feature B. The "5" doesn't directly mean hours or days. Teams then measure velocity (how many points they complete per sprint) and use velocity to estimate when work will be done.
Example: Team completes 30 points per sprint. Feature is estimated at 15 points. Estimate: 0.5 sprints = 1 week (assuming 2-week sprints).
Story points provide a middle ground between detailed hour-based estimates and vague guesses. They're useful for:
Planning: How much can we fit in the next sprint? If velocity is 30 points and we want to plan 35 points of work, that's overcommitting. Points give visibility.
Prioritization: If Feature A (5 points) and Feature B (8 points) are both important but we can only do one, knowing the effort difference helps decide.
Tracking progress: Done 12 of 30 planned points? You're 40% through the sprint. This is visible information.
Identifying bottlenecks: If planned points are consistently higher than completed points, something's blocking velocity.
Establish a baseline. Pick a simple story. Call it 1 point. "A simple bug fix." Or "a UI change that's straightforward."
Estimate relative to baseline. For each new story: "Is this simpler than the baseline (0.5 points)? About the same (1 point)? Twice as hard (2 points)? Three times as hard (3 points)?" Use Fibonacci numbers for consistency: 1, 2, 3, 5, 8, 13, 21.
Use consensus. In planning, discuss estimates. If one engineer says 3 points and another says 8, discuss. "Why do you think it's 8?" "I'm worried about the third-party API integration." Now everyone knows the risk. Either the estimate is updated, or it stays at the higher number.
Don't confuse points with hours. Points are relative complexity, not absolute time. "5 points" doesn't mean 5 hours or 5 days. It means "this is bigger than 3 points, smaller than 8 points." The mapping to time comes through velocity.
Story points:
Hours:
Which should you use? Depends on context. Startups often use hours ("we have limited runway, we need precise time estimates"). Mature teams often use points ("we have predictable velocity, we don't need to know exact hours"). For external communication ("when will this ship?"), convert points to time using velocity.
Velocity = Average points completed per sprint.
Example: Last 4 sprints completed: 28, 32, 25, 31 points. Average = 29 points per sprint. Velocity = 29 points/sprint.
You can then use velocity to forecast:
Velocity trends matter more than absolute velocity. If velocity is trending down (was 35, now 30, was 25), something's wrong. Increasing technical debt? Team members leaving? Blocking dependencies?
"Points should map directly to hours." They shouldn't. Points are relative. If 5 points always takes 20 hours, what's the value of adding them? Just estimate hours directly.
"Higher points = more work hours." Not necessarily. A 5-point story might be complex but not time-consuming. A 2-point story might be simple but time-consuming due to third-party API delays.
"Teams should compare velocity." Bad idea. Team A's 5 points ≠ Team B's 5 points. Team A might have different definitions, different complexity baseline, different team composition. Velocity only matters within a team.
"Points are arbitrary, so why use them?" Points are relative, but they're not arbitrary. If your baseline is consistent, points are reproducible. "5 points" might not mean anything universally, but within your team, it's meaningful.
"We should estimate everything." No. Small tasks don't need points. "Update the README" doesn't need a point estimate. Only estimate work items large enough to matter for planning.
Story points work best when:
When these conditions aren't met, story points can be problematic.
High team turnover: New members estimate differently. Velocity becomes unpredictable.
Highly uncertain work: "Research whether we should use technology X." Hard to point. Better to time-box ("spend 1 week researching").
Regulatory or compliance work: Requirements are fixed, complexity is high. Points might overestimate time because you have to do it all anyway.
Interrupted work: If the team gets pulled away frequently, committed velocity is hard to predict.
In these cases, time-based estimates or time-boxing might work better.
"We estimate, but velocity is all over the place." Possible causes: inconsistent story definition, points vary by who's doing the work, external blockers affect completion. Fix: clarify definition, discuss estimation differences, remove blocking dependencies.
"Points inflate over time." This happens when you try to game velocity. "That's 2 points" becomes "that's 3 points because of risk." Points lose meaning. Reset the baseline periodically to recalibrate.
"People get defensive about their estimates." Points become personal. If you estimate 5 and someone criticizes it, it feels like criticism. Fix: frame points as team estimates, not individual estimates. Discuss openly.
Q: How do we estimate a story we don't fully understand?
A: Tentatively. "We don't fully understand this, so estimate has high uncertainty. We're going to assign 5-8 points, and refine once we learn more." After exploration, refine the estimate.
Q: Should we include testing in story points?
A: Yes. A 5-point story includes development, testing, review, and any rework. If testing is usually 30% of the effort, factor that in.
Q: What do we do when velocity is unpredictable?
A: Investigate why. Are stories consistently larger than estimated? Are you getting interrupted? Is the team learning and getting faster? Understanding the variance helps you improve planning.
Q: Can we use story points for sprint reporting to management?
A: Be careful. Managers often interpret 30 points per sprint as "capacity" and expect it to remain constant. It won't. Better to report: "We completed 30 points this sprint. We're on track for X features by Y date."
Keep reading
Related resources
