Need experienced engineers for your project? Learn about our Staff Augmentation services.
Read also: Technical Debt Remediation: Cost-Benefit Analysis Framework
Every software project begins with the same question: how long will this take and how much will it cost? And every experienced engineer knows the honest answer is “it depends.” Yet organizations need estimates to make investment decisions, set expectations, and coordinate across teams. This guide provides practical estimation techniques that reduce uncertainty without creating false precision.
Why Estimation Matters
Poor estimates cause cascading problems:
- Underestimates lead to missed deadlines, crunch time, quality shortcuts, and eroded stakeholder trust
- Overestimates lead to bloated budgets, lost deals, and a reputation for being slow
- No estimates lead to projects that drift without accountability or course correction
The goal is not perfect accuracy — it is useful accuracy. An estimate that is consistently within 20% of actuals is more valuable than one that is occasionally exact but often off by 100%.
Estimation Techniques
1. Planning poker (team consensus)
Planning poker uses the collective judgment of the team to estimate relative effort.
How it works:
- The product owner presents a user story
- Each team member selects a card from a modified Fibonacci sequence (1, 2, 3, 5, 8, 13, 21)
- All cards are revealed simultaneously — no anchoring bias
- If estimates diverge significantly (e.g., 3 and 13), the highest and lowest estimators explain their reasoning
- The team discusses and votes again
- Convergence typically happens within 2-3 rounds
When to use: Sprint planning for teams of 3-8 developers. Planning poker works because it surfaces hidden assumptions — the developer who estimates 13 often knows about a technical constraint the others missed.
Pitfalls to avoid:
- Do not average the votes — discuss until consensus
- Do not let the most senior person vote first
- If a story gets estimated at 13+, it needs to be broken into smaller stories
2. Three-point estimation (PERT)
Three-point estimation captures uncertainty explicitly by asking for three values per task.
The formula:
Expected = (Optimistic + 4 × Most Likely + Pessimistic) / 6
Standard Deviation = (Pessimistic - Optimistic) / 6Practical application:
| Task | Optimistic | Most Likely | Pessimistic | Expected | Std Dev |
|---|---|---|---|---|---|
| API endpoint | 2 days | 4 days | 8 days | 4.3 days | 1.0 day |
| Database migration | 1 day | 3 days | 10 days | 3.8 days | 1.5 days |
| Frontend component | 3 days | 5 days | 7 days | 5.0 days | 0.7 days |
| Integration testing | 2 days | 4 days | 12 days | 5.0 days | 1.7 days |
| Total | 18.1 days | 2.6 days |
Confidence intervals:
- 68% confidence: 18.1 ± 2.6 = 15.5-20.7 days
- 95% confidence: 18.1 ± 5.2 = 12.9-23.3 days
Present the range to stakeholders: “We estimate 18 working days, with 95% confidence it will take between 13 and 23 days.”
3. Reference class forecasting
Instead of estimating from internal analysis, compare with similar past projects.
Steps:
- Identify 5-10 similar completed projects (same type, similar scope, comparable team)
- Collect actual duration and effort data for each
- Use the median as your base estimate (not the average — outliers skew averages)
- Adjust for known differences (larger scope, less experienced team, new technology)
Example: Your last 7 API integration projects took: 3, 4, 4, 5, 5, 6, 11 weeks.
- Median: 5 weeks
- Average: 5.4 weeks (skewed by the 11-week outlier)
- Use 5 weeks as the base, then adjust: “This integration is more complex than average, so we estimate 6-7 weeks.”
Why it works: Reference class forecasting corrects for optimism bias by using objective historical data rather than subjective internal estimates.
4. T-shirt sizing (rough order of magnitude)
For early-stage estimation when details are sparse.
| Size | Effort range | Example |
|---|---|---|
| XS | 1-2 days | Bug fix, config change |
| S | 3-5 days | Simple feature, minor UI change |
| M | 1-3 weeks | Standard feature, API integration |
| L | 1-3 months | Major feature, new module |
| XL | 3-6 months | New system, platform migration |
When to use: Product roadmap planning, initial scope assessment, portfolio prioritization. Convert to detailed estimates once the work enters sprint planning.
Story Points vs Hours
| Aspect | Story points | Hours |
|---|---|---|
| What they measure | Relative complexity and effort | Absolute time |
| Accuracy | High for throughput prediction | Low for individual tasks |
| Team dependency | Calibrated per team | Varies by individual |
| Scope creep visibility | Points remain stable, velocity absorbs change | Hours change, requiring re-estimation |
| Client communication | Requires velocity translation | Directly understandable |
| Best for | Sprint planning, internal tracking | Contracts, budgets, client proposals |
Establishing velocity
Velocity is the bridge between story points and time:
- Sprint 1-3: Track points completed per sprint (expect high variance)
- Sprint 4-6: Velocity stabilizes — calculate the rolling average
- Sprint 7+: Use the average velocity for sprint forecasting
Example: A team completes 32, 38, 35, 40, 37 points across five sprints. Average velocity = 36.4 points per sprint. For a 100-point backlog, estimate 3 sprints (6 weeks for 2-week sprints).
Velocity anti-patterns:
- Do not compare velocity across teams — each team’s point scale is unique
- Do not use velocity as a performance metric — it incentivizes point inflation
- Do not include incomplete stories in velocity — only done-done work counts
Improving Estimation Accuracy
Track estimation accuracy
After each sprint, compare estimates to actuals:
Accuracy Ratio = Actual Effort / Estimated Effort- Ratio of 1.0 = perfect estimate
- Ratio > 1.0 = underestimate (took longer than expected)
- Ratio < 1.0 = overestimate (took less than expected)
Track the ratio over time. Most teams discover they consistently underestimate by 25-40%. Apply this as a correction factor to future estimates.
Break down large items
Estimation accuracy is inversely proportional to task size:
| Task size | Typical accuracy |
|---|---|
| < 1 day | ±20% |
| 1-3 days | ±30% |
| 1-2 weeks | ±50% |
| 1-3 months | ±100% |
| 6+ months | ±200% |
Rule: No estimation item should exceed 5 days of effort. If it does, decompose it into smaller tasks before estimating.
Account for non-coding work
Developers tend to estimate coding time only. A complete estimate includes:
- Requirements clarification and design (10-15% of total)
- Implementation (40-50% of total)
- Unit and integration testing (15-20% of total)
- Code review and revisions (5-10% of total)
- Documentation (5% of total)
- Deployment and verification (5% of total)
- Buffer for unknowns (10-15% of total)
Use estimation retrospectives
After each project or major milestone:
- Compare estimated vs actual effort per major component
- Identify which areas were most off and why
- Document estimation patterns (“we always underestimate database work by 40%”)
- Update your team’s estimation correction factors
Common Estimation Mistakes
Anchoring to the first number
The first estimate mentioned becomes the anchor. In planning poker, simultaneous reveal prevents this. In other contexts, ask each person to write their estimate before any discussion.
Confusing effort with duration
A task that takes 20 hours of effort does not take 2.5 working days. Account for context switching, meetings, code reviews, and other non-project work. Most developers have 5-6 productive hours per day for focused project work.
Ignoring integration complexity
Individual components estimated at 3 weeks each do not integrate in zero time. Add 15-25% for integration, end-to-end testing, and resolving interface mismatches.
Planning for the best case
When a developer says “this will take 3 days,” they usually mean “3 days if nothing goes wrong.” Ask: “What if something does go wrong?” and use that answer as your planning estimate.
Estimation for Contracts and Proposals
When estimates become contractual commitments:
- Use three-point estimation for every major component
- Add a management reserve of 15-20% for unknown unknowns
- Define scope boundaries explicitly — what is included, what is not, what triggers a change request
- Use phased delivery — fixed price for Phase 1 (well-defined), time-and-materials for Phase 2 (less defined)
- Include re-estimation points — after Phase 1 delivery, re-estimate remaining phases with better information
How ARDURA Consulting Supports Project Delivery
Estimation accuracy depends on having the right team — experienced engineers who have seen similar problems before and can estimate with confidence. ARDURA Consulting helps organizations build teams that deliver predictably:
- 500+ senior specialists who bring estimation experience from enterprise projects — available within 2 weeks to augment your team’s capacity and reduce the unknown-unknowns that cause estimation failures
- 40% cost savings compared to traditional hiring, allowing you to staff projects at the right level without permanent headcount commitments
- 99% client retention — specialists who stay through the full project lifecycle, improving estimation accuracy as they learn your domain
- 211+ completed projects providing reference class data that improves forecasting from day one
Whether you need senior architects to estimate a complex migration or a full development team to deliver on an approved budget, ARDURA Consulting provides the talent to turn estimates into delivered software.