All estimations are wrong, but none are useful
13 days ago
- #Project Management
- #Scrum
- #Software Estimation
- Story points in Scrum are used for effort estimation but software estimations are inherently inaccurate.
- Estimations are forecasts of an unknown future, yet commitments are often made based on them.
- Plans are useful for iterative work but projects are complex with many dependencies.
- Reasons for failed plans include imprecise requirements, lack of knowledge, and underestimating technical debt.
- Hofstadter’s Law: Tasks take longer than expected, even when accounting for this law.
- Brook’s Law: Adding more people to a late project makes it later due to onboarding and communication overhead.
- Planning Fallacy: Cognitive bias leads to underestimating time and resources needed.
- Bikeshedding: Focus on trivial details over critical aspects skews estimations.
- Parkinson’s Law: Work expands to fill the time allotted, leading to inefficiencies.
- Ninety-Ninety Rule: The last 10% of code takes 90% of the time due to bug fixes and polishing.
- Cone of Uncertainty: Early project stages have high uncertainty, which decreases as more information is gathered.
- George Dinwiddie’s advice: Track progress, accept wrong estimates, use buffers, and measure completion.
- Practical tips: Break tasks into smaller chunks, be conservative, and update estimates regularly.
- Legacy code risks: Assess team knowledge and documentation availability.
- Vasco Duarte’s NoEstimates approach: Focus on throughput and cycle times instead of story points.
- Kaizen philosophy: Small, incremental steps provide significant value.
- Team culture influences preference for estimation methods like Scrum or Kanban.