Glossary
Sprint estimation predicts effort required for development tasks using techniques like story points and planning poker. Product teams must distinguish estimation (predicting) from commitment (promising), and improve accuracy by providing estimators with codebase context before planning sessions.
I've shipped hundreds of estimates across three companies. My accuracy improved dramatically when I stopped relying on gut feel and started using historical data from our actual codebase.
Sprint estimation is the process of predicting how much work a team can complete in a sprint and assigning work to a sprint based on that prediction. It involves: estimating individual work items, forecasting team velocity, and committing to a scope.
Example: Team has velocity of 30 story points per 2-week sprint. In the next sprint planning, the team selects 28 points of work, leaving a small buffer.
Sprint estimation differs from project estimation (how long will the whole project take) and feature estimation (how long will this feature take). Sprint estimation is: how much work fits in the next 2 weeks?
Sprint estimation enables visibility and predictability:
Visibility: "How much are we committed to this sprint?" Knowing the answer helps everyone (team members know what's expected, PMs know what's shipping, leadership knows progress).
Predictability: Measuring velocity over time makes future sprints predictable. "We do 30 points per sprint. We have 100 points of work. That's 3.3 sprints = 6.6 weeks." You can forecast.
Focus: By committing to specific work, the team has clear priorities. "These 28 points are our sprint goal. New work that comes up is out of scope." This prevents context-switching and scope creep.
1. Estimate individual items. In backlog refinement, the team estimates stories. "This feature is 3 points. That bug is 1 point."
2. Measure velocity. Track how many points the team completed in recent sprints. Average them. That's velocity. "Last 3 sprints: 32, 28, 30 points. Average = 30 points per sprint."
3. Plan the sprint. Select work items that fit within expected velocity. "We expect 30 points of capacity. Let's commit 28 points, leaving 2 points buffer for surprises."
4. Execute. The team works through the sprint.
5. Reflect. At the end: "Did we commit to 28? Did we complete 28? What affected velocity?" Use this to adjust next sprint's planning.
Velocity rarely stays constant. It fluctuates due to:
Team changes: Adding/removing people changes velocity.
External factors: Holidays, conferences, or production incidents reduce available capacity.
Learning: As a team gets better at estimation, their estimates might improve (velocity becomes more predictable).
Technical debt: If you don't pay down technical debt, velocity tends to decline over time.
Better to track velocity trends than to assume constant velocity.
Example: Last 6 sprints: 28, 30, 32, 34, 35, 36 points. Velocity is trending up (team is becoming more efficient or taking on less debt). Next sprint, you might expect 36-38 points of capacity.
During the sprint:
Committed: Work you agreed to complete. 28 points.
In-progress: Work started but not finished. 8 points committed, 4 completed, 4 in-progress.
Completed: Work finished. 24 points.
Actual velocity: Points actually completed. 24 points (or 28, if the in-progress work finishes before sprint ends).
Tracking the difference between committed and actual helps you understand:
Velocity isn't fixed. You have:
Expected capacity: 30 points based on velocity.
Committed: 28 points of work.
Buffer: 2 points, for surprises.
Buffer is important. Without buffer, any surprise (production issue, dependency that takes longer) causes you to miss sprint goals.
Rule of thumb: Commit to 80-90% of expected velocity. Use the 10-20% as buffer for uncertainties.
"We'll commit 100% of capacity and just work harder if needed." That's a path to burnout. Commit conservatively. Use buffer for surprises.
"We estimated 5 points, actual took 8. The estimates are broken." Estimates are learning. If they're consistently wrong by a factor, adjust. But some variation is normal.
"New work came up, but we already planned the sprint, so it waits." Good discipline. Unplanned work should wait for the next sprint. Exceptions: production issues or critical bugs. Everything else can wait.
"We measure velocity but it doesn't help plan better." Velocity is useful for forecasting total project duration, not for improving current sprint predictability. If you want to improve sprint planning, focus on: clearer requirements, smaller stories, and honest estimation.
High external disruption: If the team is constantly pulled away (meetings, support, interrupts), actual velocity is hard to predict. Either reduce disruption or stop planning as if you have predictable capacity.
Unclear work items: If stories aren't clear, estimation is guessing. Spend more time on story clarity before sprint planning.
High estimation variation: If one engineer estimates 3 points and another estimates 8, discuss. One of you has important information the other doesn't.
No follow-through on sprint commitments: If the team regularly doesn't complete what they committed to, either: commitments are too aggressive, or there are external blockers. Either way, address it.
"If velocity is 30, we should be able to commit to 30 every sprint." Velocity varies. Some sprints have holidays. Some have production issues. Average velocity over 6-8 sprints, then use that for planning. Don't expect perfect consistency.
"Velocity is a measure of team productivity." It's a measure of throughput for a specific team with specific definitions. It's not comparable across teams and shouldn't be used to judge individual performance. Team A's 30 points ≠ Team B's 30 points.
"We should make sprint goals aggressive to push the team." Aggressive goals lead to: overcommitment, missed goals, reduced morale, and cutting corners. Realistic goals are more motivating because they're achievable.
Q: What if a task takes longer than estimated?
A: Mid-sprint, if a 3-point task is taking longer than expected, reassess. "This task is now looking like 5 points. We've completed 20 of 28 committed. If we finish this, we're at 25/28. Do we have capacity?" If not, you might deprioritize something else or accept that you won't hit your sprint goal.
Q: How do we handle interrupted work (production issues, urgent requests)?
A: Reserve capacity for it. If you expect one production incident per sprint (averaging 4 points), commit to 26 points, leave 4 for incidents. If there are no incidents, you complete more. If there are, you hit your commitment.
Q: Should we estimate bug fixes the same way as features?
A: Yes. A bug is work. It should be estimated and counted toward velocity. Don't confuse "completed points" (features + bugs) with "feature points" (features only). Both matter for capacity planning.
Q: What if velocity is declining?
A: Investigate. Possible causes: taking on more technical debt, team turnover, growing complexity. Address the root cause. Don't just accept declining velocity as inevitable.
Keep reading
Related resources
