Glossary
By Glue Team
Software project estimation is the process of forecasting how long development work will take, measured in time, effort, or story points. Accurate estimation requires understanding task complexity, codebase difficulty, dependencies, and team capacity—not guessing based on hope.
Poor estimates cause cascading failures:
Accurate estimation (within 15-20% error) enables reliable planning and keeps engineering humane—no fake deadlines, no crunch culture.
Task estimation (hours/days): Individual engineers estimate work they'll do soon. Accuracy: 70-80% achievable within 1-2 days.
Sprint estimation (story points): Teams estimate work for upcoming sprint. Accuracy: 60-70%; harder because unknowns are larger.
Project estimation (weeks/months): High-level forecast of large features or initiatives. Accuracy: 40-50% without detailed codebase analysis; 60-70% with it.
Roadmap estimation (quarters): Strategic forecasting of annual plans. Accuracy: 30-40% normal; depends more on strategic assumptions than engineering effort.
Relative sizing (story points): Compare tasks to reference tasks. "This is twice as complex as last week's auth work, so 4 points instead of 2." Better than absolute estimates because humans judge relative size more accurately.
Three-point estimation: Get optimistic (O), most-likely (M), and pessimistic (P) estimates from engineers. Calculate: (O + 4M + P) / 6. This reveals uncertainty; if pessimistic is 4x optimistic, the task is risky.
Codebase-based estimation: Measure the complexity of code being changed (cyclomatic complexity, lines affected, test coverage, dependencies). Teams that estimate based on code metrics are 30-40% more accurate than those that guess.
Historical velocity: Track how much work teams complete per sprint. If a team averages 40 story points per sprint, next sprint's estimate of 40 points is informed, not assumed.
Decomposition: Break large tasks into smaller ones. A 3-month feature might break into: API design (1 week), backend (4 weeks), frontend (3 weeks), integration testing (2 weeks), refinement (1 week) = 11 weeks. Smaller estimates are more accurate.
Optimism bias: Engineers estimate best case (no distractions, no bugs, no learning curve). Reality includes all three.
Anchoring: First estimate becomes a number others anchor to, even if it's wrong. Use ranges, not single numbers.
Sunk cost thinking: "We've already spent 4 weeks, so 2 more should finish it." That's fallacy. Reestimate from current state.
Groupthink: Team settles on an estimate without enough dissent. Encourage "I think this is riskier" to surface assumptions.
Padding in silence: Engineers add secret buffers. Make buffers explicit and honest: "Best case 4 weeks, likely 5, worst case 7 due to integration unknowns."
Q: Should we tie estimates to engineer compensation? A: No. Estimates tied to bonuses create perverse incentives to overestimate, miss dates, or cut quality. Keep estimation and performance separate.
Q: How do we estimate work in unfamiliar code? A: Add a multiplier. "Familiar code: 2 weeks. Unfamiliar code: 2 weeks × 1.5 learning multiplier = 3 weeks." Be honest about unknowns.
Q: What if a task is finished faster than estimated? A: That's good—celebrate it. But don't assume next estimate should be lower without understanding why. Was it simpler than expected, or did the engineer work overtime?
Keep reading
