Glossary
By the Glue Team
Sprint estimation is the process of forecasting how much work a team can complete during a sprint (typically 1-2 weeks). Accurate sprint estimation enables realistic planning, sustainable pace, and reliable delivery. Poor estimation leads to over-commitment, missed deadlines, and team burnout.
Sprint estimation involves:
Estimation is not about predicting the future with certainty—that's impossible. It's about making informed guesses to plan realistically.
Estimation quality affects project success:
Realistic Planning: If you estimate accurately, you commit to achievable goals. Team delivers. Morale improves. Stakeholders trust you. If you over-commit, you miss goals, damage credibility, and burn out team.
Velocity Tracking: Estimation enables tracking velocity (work completed per sprint). Velocity is the primary metric for forecasting when projects will finish. Without estimation, you can't calculate velocity.
Sustainable Pace: Over-committed teams work unsustainable hours. This causes burnout, mistakes, and quality issues. Accurate estimation supports realistic pace that's maintainable long-term.
Stakeholder Management: Stakeholders want to know when features ship. Sprint estimation enables forecasting. "At current velocity, this epic ships in 4 sprints" is more credible than guessing.
Bottleneck Identification: Estimation surfaces dependencies. "Why is task X so big?" might reveal an architecture issue that's also blocking other work. Fixing the architecture helps multiple tasks.
Risk Visibility: If most tasks are estimated high, that's a risk signal. Complexity, uncertainty, or unknowns are high. That might mean more testing is needed, or the approach should be reconsidered.
Story Points: Popular in Agile. Tasks are sized relative to each other using Fibonacci numbers (1, 2, 3, 5, 8, 13, 21). A 5-point task is roughly twice as hard as a 3-point task. No absolute meaning—points vary per team.
Ideal Hours: Estimate how many hours of focused engineering work a task requires. Add 20-30% for interruptions and unknowns to get elapsed time.
T-Shirt Sizes: XS, S, M, L, XL. Useful for high-level estimation when details aren't known. Less precise than points but faster.
Planning Poker: Team members estimate independently, reveal simultaneously, discuss disagreements. This surfaces different assumptions and improves accuracy.
Three-Point Estimation: Estimate best case, likely case, and worst case. Useful for high-uncertainty tasks. Weighted average: (best + 4*likely + worst) / 6.
Analogous Estimation: "This looks like that other task that was 5 points." Fast and intuitive if you have similar past work.
Unknown Unknowns: You don't know what you don't know. A task looks simple but hits unexpected complexity (undocumented dependencies, environmental issues, performance problems).
Different Perspectives: Engineers estimate differently. What takes one person 3 days takes another 5. Estimation is subjective; it reflects your experience.
Pressure to Underestimate: Business wants features fast. Pressure exists to estimate low. Teams learn to overestimate to protect themselves, which creates inaccuracy in the opposite direction.
Changing Requirements: Requirements evolve. A task estimated at 5 points becomes 13 when new requirements arrive. Estimation based on incomplete requirements is guessing.
Skill Variation: A task that's 5 points for a senior engineer is 13 points for a junior. Estimation needs to account for who's doing the work.
Learning Curve: Estimating work you've never done before is hard. Building features in a new language, framework, or domain is unpredictable.
Historical Data: Track what you estimated vs. what you completed. If estimates are consistently high, adjust. If consistently low, adjust. Learn from history.
Breaking Down Tasks: Small tasks are easier to estimate than large ones. A 21-point task has more uncertainty than five 3-point tasks. Break down large work.
Reducing Unknowns: If a task has high uncertainty, spend time reducing uncertainty before estimating. Spike work to research questions. Once unknowns are resolved, estimate more accurately.
Pair Estimation: Two estimators are better than one. Discussion reveals assumptions. Shared estimates are more credible to both engineers.
Post-Sprint Review: How accurate were estimates? Why? What did you learn? Use this feedback to adjust future estimates.
Clear Definition of Done: If estimating "feature complete" vs. "shipped in production" gives different estimates, be explicit. Estimates should specify what "done" means.
Accounting for Interruptions: Don't estimate in ideal hours only. If team is 20% interrupted (meetings, support, distractions), add 25% buffer to raw estimates.
"Perfect estimation is possible." False. Estimation is probability distribution, not precision. 3-point task might be 1-6 points. The goal is accuracy on average, not precision on each task.
"Estimation is about individual speed." Partly false. Yes, individual capability matters. But estimation is about the task and how well-defined it is. Well-defined tasks are easier to estimate regardless of estimator.
"Teams should commit to velocity targets." Partly false. Teams should track velocity, but it shouldn't be a rigid target. If velocity is 30 points but you commit to 50 to look good, you'll miss. Velocity should inform planning, not drive heroics.
"Estimation waste; we should just ship." False. Time spent on estimation (20 minutes per sprint) prevents much larger waste (missing sprint goals, over-committing, context switching). Small investment, large payoff.
Velocity: The number of story points completed per sprint. Used to forecast project completion.
Sprint Planning: The meeting where estimation happens. Estimation is input to planning, not the meeting itself.
Effort Estimation: Broader than sprint estimation. Effort estimation includes long-term forecasting ("How long will this epic take?"), not just sprint-level.
Burndown Chart: Visual showing work remaining in a sprint. Based on story point estimates.
Q: What story point scale should we use? A: Fibonacci (1, 2, 3, 5, 8, 13, 21) is standard. Some teams use powers of 2 (1, 2, 4, 8, 16). The key is consistent relative sizing. Pick one and stick with it for velocity tracking consistency.
Q: Should we estimate bugs? A: Yes. Bugs are work. They should be estimated and counted toward velocity. This ensures planning accounts for bug fixes, not just features.
Q: What's a good velocity? A: There's no universal answer. Velocity is team-specific. A velocity of 40 points per sprint for one team is high; for another it's low. The goal is consistency. A stable velocity enables reliable forecasting.
Keep reading
