Glossary
By the Glue Team
Effort estimation is the process of predicting how much work is required to complete a task, feature, or project. It accounts for complexity, uncertainty, team skill, and dependencies. Good estimation enables realistic planning and reliable delivery. Poor estimation leads to missed deadlines, over-commitment, and burnout.
Effort estimation answers: "How long will this take?" It's different from duration (how much time is available). A task might estimate 40 hours but have a duration of 10 days (one week of part-time work due to interruptions).
Effort estimation includes:
Reliable Delivery: Estimate accurately, plan realistically, deliver reliably. This builds credibility with stakeholders. Estimate poorly, miss deadlines, lose trust.
Resource Planning: How many people do you need? How long will this project take? Estimation answers these questions. Without estimation, hiring and schedule decisions are guesses.
Trade-off Decisions: "Should we cut scope or extend timeline?" requires knowing effort. If a feature estimates 5 points but cuts three other features, trade-off is easier to evaluate.
Risk Management: High-uncertainty tasks should be estimated high. This reflects risk in planning. "This task estimates 8 points due to uncertainty about the API we depend on" makes risk visible.
Learning: Historical estimation accuracy shows where you're weak. If architectural decisions consistently estimate low, maybe your architecture is problematic. Estimation accuracy reveals team and project patterns.
Analogous Estimation: "This looks like that other task that took 3 days." Fast and intuitive if you have similar past work. Less accurate for novel work.
Parametric Estimation: "There are 30 screens and we build screens at 4 hours each = 120 hours." Works when you have historical rates.
Three-Point Estimation: Best case, likely case, worst case. Calculate weighted average: (best + 4*likely + worst) / 6. Accounts for uncertainty.
Bottom-Up: Break work into small tasks, estimate each, sum them up. More accurate than top-down but time-consuming. Use for important work.
Top-Down: Estimate large chunks. Faster but less accurate. Use for preliminary planning.
Planning Poker: Team estimates independently, reveals simultaneously, discusses disagreements. This surfaces different perspectives and improves accuracy.
Expert Judgment: Someone who's done similar work estimates. Relies on their experience. Useful but prone to bias (underestimation, overconfidence).
Unknown Unknowns: You don't know what you don't know. A simple task becomes complex when hidden dependencies surface.
Requirements Uncertainty: Estimated work changes as requirements evolve. Estimate based on incomplete information.
Technical Unknowns: Using unfamiliar technology? Uncertain how long it will take.
Pressure: Business wants to hear estimates are small. Pressure to underestimate is real. Teams learn to overestimate to protect themselves.
Human Factors: Interruptions, meetings, other responsibilities reduce actual coding time. A 40-hour estimate becomes 80 hours duration.
Skill Variation: Same task takes different time for different engineers.
Diminishing Returns: Late in projects, estimates become less accurate. Information asymmetry—estimators don't know what's already been tried.
Break Down Work: Small tasks are easier to estimate. Break large estimates into smaller pieces. Five 8-point tasks are more accurate than one 40-point task.
Reduce Uncertainty: Spend time understanding requirements before estimating. Prototype or spike unknown areas. Reduce unknowns.
Track History: What did you estimate vs. what happened? Consistently underestimating? Adjust multiplier. Consistently overestimating? Adjust down.
Pair Estimation: Two estimators catch more nuance than one. Discussion reveals assumptions.
Post-Mortems: After delivery, compare estimate to actual. Learn from misses.
Multiple Estimates: Get three estimates instead of one. Average them. Range shows uncertainty.
Account for Interruptions: If team is 30% interrupted, multiply raw estimate by 1.4.
Account for Rework: If code quality expectations require refactoring, factor that in.
Clear Definition of Done: "Build the feature" is different from "ship in production." Estimate should specify scope.
"Good estimates are precise." False. Good estimates have ranges. A 40-point estimate probably means 30-50 points. The goal is to be accurate on average across many estimates.
"Estimates are commitments." Partly false. Estimates should be best-guess forecasts, not promises. If estimates are treated as commitments, people underestimate to appear good. This backfires.
"Estimation takes time we don't have." False. Estimation prevents much larger waste. 30 minutes estimating prevents weeks of off-track work.
"Experienced developers estimate better." Partly true. Experience helps but introduces overconfidence bias. Structured estimation (three-point, planning poker) beats expert gut-feel.
"We should meet estimates even if it means cutting quality." False. Missing estimates while maintaining quality is better than meeting estimates while destroying quality. You'll pay for quality shortcuts later.
Sprint Estimation: Estimating work for upcoming sprint. Subset of effort estimation.
Velocity: Historical productivity. "We complete 40 points per sprint" informs capacity for future sprints.
Scope Creep: When estimated work expands without adjustment. Estimation helps manage scope creep by making additions visible.
Project Management: Estimation is foundation of project planning.
Q: Should you estimate in hours or points? A: Either works. Hours are absolute but harder to estimate (unknowns inflate hours). Points are relative but enable velocity-based forecasting. Points work better for iterative development. Hours work better for fixed-scope work.
Q: How do you estimate for tasks no one has done before? A: Use three-point estimation with high ranges. Best case: 4 hours. Likely: 8. Worst: 20. Weighted average: 8.67. Do a spike (time-boxed research) if uncertainty is very high.
Q: Should estimates include testing and code review? A: Yes. Estimate should cover everything in definition of done. If code review takes time, include it. If testing is required, include it.
Keep reading
