Software Estimation
The process of predicting the effort, time, or cost required to develop software, using various techniques to manage inherent uncertainty.
Also known as: Effort Estimation, Project Estimation, Estimation Techniques
Category: Software Development
Tags: software-engineering, estimation, planning, project-management, agile
Explanation
Software estimation is the practice of predicting how much effort, time, or resources a software project or work item will require. It is one of the most difficult and consequential activities in software development because of the inherent uncertainty involved.
## Why estimation is hard
Software development is fundamentally creative and exploratory work. Unlike manufacturing, where repeating the same process yields predictable results, each piece of software is unique. Key challenges include:
- **Novel work** - Most tasks involve solving problems that haven't been solved exactly this way before
- **Hidden complexity** - Requirements interact in unexpected ways
- **Unknown unknowns** - You can't estimate what you don't know you don't know
- **Human factors** - Skill levels, interruptions, and team dynamics all affect delivery
- **Scope creep** - Requirements evolve during development
## Categories of techniques
**Relative estimation** - Comparing items to each other rather than estimating in absolute terms:
- Story Points using Fibonacci sequences
- T-shirt Sizing (XS, S, M, L, XL)
- Affinity Estimation (grouping by similarity)
**Expert judgment** - Leveraging experience:
- Planning Poker (consensus-based group estimation)
- Wideband Delphi (structured expert consultation)
- SWAG (Scientific Wild-Ass Guess)
**Statistical methods** - Using historical data:
- Reference Class Forecasting (using outcomes from similar past projects)
- Three-Point Estimation (optimistic, likely, pessimistic)
- Monte Carlo simulation
**Decomposition** - Breaking work into smaller, more estimable pieces:
- Work Breakdown Structure
- Bottom-up estimation
## Key principles
1. **Estimates are not commitments** - An estimate is a prediction, not a promise
2. **Precision is not accuracy** - Saying '87.5 hours' sounds precise but is probably no more accurate than 'about 2 weeks'
3. **Ranges beat point estimates** - Express uncertainty with confidence intervals
4. **Relative estimation outperforms absolute** - Humans are better at comparing than measuring
5. **Smaller items are easier to estimate** - Decompose before estimating
6. **Track actuals** - Compare estimates to reality to improve calibration
7. **The Cone of Uncertainty narrows over time** - Early estimates are inherently less accurate
## Common pitfalls
- Confusing estimates with targets or deadlines
- Anchoring on the first number mentioned
- Ignoring historical data in favor of optimism
- Pressure to lower estimates rather than reduce scope
- Not accounting for overhead (meetings, code reviews, testing)
Related Concepts
← Back to all concepts