Strome

The Problem with Estimates in Software Development

“Nine women can’t make a baby in one month.” - Fred Brooks’ famous observation perfectly captures why software estimation remains one of our industry’s greatest challenges. After analyzing over 50,000 software projects, the Standish Group found that 66% either fail completely or face significant time and budget overruns. Yet we keep trying to estimate with precision.

Why estimates are difficult to get right

Software development isn’t like building a house. Each project explores new territory. I’ve been building software for over two decades, and here’s what makes estimation so challenging:

The complexity is hidden. A seemingly simple feature - “just add a login button!” - can trigger a cascade of technical decisions. Authentication protocols. Security considerations. Database changes. UI states. Error handling. Each decision spawns more decisions.

Let me share a recent example: Last quarter, our team estimated a “simple” user authentication feature would take two weeks. Three weeks later, we were still dealing with edge cases around password reset flows, session management, and security requirements. What looked straightforward on paper revealed layers of complexity during implementation.

Our work is largely invisible. Unlike physical construction, we can’t look at a half-finished software project and intuitively gauge its progress. The most critical work often happens in the mind before a single line of code is written.

Knowledge work is unpredictable. Some days the solution comes in minutes. Other days, a seemingly trivial bug consumes hours of debugging. This variance makes estimation feel like predicting the weather months in advance.

Common Estimation Pitfalls

Before we dive into solutions, let’s acknowledge the traps teams often fall into:

  • Pressure to provide “exact” numbers when uncertainty is high
  • Not accounting for non-coding tasks like code review, testing, and documentation
  • Ignoring team capacity variations due to meetings, interruptions, and time off
  • Assuming best-case scenarios without building in buffer for unexpected issues
  • Treating estimates as commitments rather than forecasts

Why stakeholders want estimates

Let’s be real - businesses need planning. Stakeholders require estimates for:

  • Budget planning
  • Resource allocation
  • Release coordination
  • Customer commitments
  • Marketing campaigns

The challenge isn’t the need for estimates. It’s our industry’s obsession with false precision.

Traditional approaches to estimation

Hours

The most common approach is also the most flawed. Hour-based estimates assume:

  • Consistent productivity
  • No unexpected problems
  • Perfect understanding of requirements
  • Zero interruptions

Reality rarely cooperates! A “4-hour task” can easily become 2 days when you discover an edge case or dependency conflict.

Story Points

Story points improve on hour estimates by:

  • Acknowledging uncertainty
  • Focusing on relative size
  • Leveraging team wisdom
  • Tracking velocity over time

Here’s a practical approach to get started: Choose a reference story of “3 points” - something your team has done before, like implementing a basic CRUD feature. Then estimate other work relative to this baseline. For example, if adding user authentication feels twice as complex as your reference story, it might be a 5 or 8-point task.

But they still suffer from fundamental issues. Teams often treat them as hour equivalents in disguise. And velocity varies significantly sprint-to-sprint.

T-Shirt Sizes

Simple size categories (S/M/L/XL) help avoid false precision. They work well for rough project planning. But they provide limited granularity for detailed sprint planning.

Alternative approach: Continuous Forecasting

Instead of seeking perfect estimates upfront, embrace continuous forecasting. We can take a page from the National Hurricane Center’s forecasting approach:

  • Think probabilistically and not deterministically
  • Make short and long term forecasts with the understanding that shorter forecasts will be more accurate than longer ones
  • Reforecast when you get more information

To do so:

  1. Break work into small, measurable increments
  2. Track actual completion times
  3. Use real data to project trends
  4. Adjust forecasts as information changes
  5. Communicate ranges, not fixed dates

Key practices that help:

  • Time-box exploration spikes
  • Set clear scope boundaries
  • Build slack into schedules
  • Maintain a risk register
  • Review estimates weekly

Optimizing Success Measurement in Software Estimation

How do you know if your estimation process is improving? Focus on these metrics:

  1. Estimation Accuracy: Track the ratio of estimated to actual time, but don’t expect perfection
  2. Delivery Predictability: Are you consistently delivering within communicated ranges?
  3. Team Confidence: Does the team feel the estimates are realistic?
  4. Stakeholder Satisfaction: Are stakeholders getting the information they need for planning?

Getting Started

Ready to improve your estimation process? Here’s a practical roadmap:

Next Sprint

  1. Track actual vs estimated time for each task
  2. Document assumptions made during estimation
  3. Hold brief post-sprint estimation reviews
  4. Note which types of tasks were most unpredictable

Next Quarter

  1. Build your reference story library
  2. Establish team estimation baselines
  3. Create an estimation playbook
  4. Review and adjust your process based on data

The goal isn’t perfect prediction. It’s providing stakeholders with the information they need while acknowledging uncertainty.

Remember: estimation is a tool, not a contract. The best estimates come from teams who:

  • Embrace uncertainty
  • Learn from actual data
  • Communicate clearly
  • Focus on delivering value

Great software emerges from collaboration, learning, and adaptation. Let’s stop pretending we can predict the future with precision. Instead, let’s build processes that help us navigate uncertainty together.

Additional Resources

  • Shape Up - An alternative approach to software development
  • When will it be done? - Explains why story points are not a great indicator of forecasting the future.
  • #NoEstimates - Challenging perspective on estimation

What estimation approaches have worked for your team? I’d love to hear your experiences.