Glossary
By Glue Team
Project duration estimation is the process of forecasting how long a large initiative will take, from kickoff to launch, incorporating team capacity, dependencies, and uncertainty. Unlike task-level estimation, project estimation must account for team dynamics, hiring, and the compounding effect of unknowns.
Projects are estimated by summing task estimates: "Task A = 2 weeks, Task B = 4 weeks, Task C = 3 weeks, total = 9 weeks." In reality, it takes 14-16 weeks. Why?
Project duration estimation that accounts for these factors is 40-50% more accurate than simple task summation.
Critical path analysis: Map task dependencies, identify the longest path from start to finish. That path determines duration; other tasks have slack.
Example: Task A (2 weeks) → Task B (4 weeks) → Task D (1 week) = 7 weeks critical path. Task C (3 weeks) can happen in parallel and has 1 week of slack, so it doesn't extend the timeline.
Velocity-based planning: If a team's velocity is 40 story points per sprint and a project is 200 story points, it takes 5 sprints = 5 × 2 weeks = 10 weeks (assuming no interruptions).
Three-point estimation at project level: Get optimistic duration (O), most-likely (M), pessimistic (P). Calculate: (O + 4M + P) / 6.
Example:
This reveals uncertainty. If M and P are 50% apart, risk is real; communicate it.
Buffer time: Add 20-30% contingency for unknowns. If best estimate is 10 weeks, add 2-3 weeks buffer. Why? Unknowns are unknown. If nothing goes wrong, you ship early. If issues emerge, you absorb them without missing deadline.
| Item | Estimate | Notes |
|---|---|---|
| Discovery & design | 2 weeks | Requirements clear |
| Core development | 6 weeks | Parallelized frontend & backend |
| Integration & testing | 2 weeks | Depends on both teams completing |
| Refinement & fixes | 1 week | Expected post-testing issues |
| Base total | 11 weeks | No buffer |
| Contingency (25%) | 3 weeks | For unknowns |
| Total with buffer | 14 weeks | Realistic forecast |
Real project estimation accounts for:
Team size: A 5-person team doesn't do 5x the work of a 1-person team. Communication overhead and coordination costs scale. A 10-person team might do 7x the work, not 10x.
Team experience: A team new to a domain estimates 1.5-2x higher than a team familiar with it. Onboarding cost is real.
Codebase health: New, well-structured codebase speeds development. Legacy codebase slows it 1.5-2x. Factor in codebase complexity from the start.
Process maturity: Teams with clear processes, CI/CD, and code review can move faster. Teams with manual testing and slow deployment slower down.
Q: How much buffer is too much? A: 20-30% is standard and defensible. Over 50% and you're padding because you don't trust the estimate. Under 10% and you're setting up for crunch.
Q: What if our estimate is wrong after 4 weeks? A: Reestimate immediately. You have real data now. If you estimated 10 weeks total and 4 weeks in you're behind, revise. Don't pretend the estimate is still valid.
Q: Should we commit to a deadline before estimation is done? A: No. Deadlines should follow estimation, not precede it. If external deadlines exist, let estimation inform whether the deadline is achievable or requires scope cuts.
Keep reading
