How Developers Estimate Effort

Estimation is where developers consistently get blamed for being wrong. The truth is more nuanced: estimation is hard because software development involves solving novel problems with unknowns. A good estimation process acknowledges this uncertainty instead of pretending it doesn't exist.

Why Estimation Is Hard

You're solving novel problems. You haven't built this exact thing before. You have an idea how long it will take, but there are unknowns. You might hit a library that doesn't work as expected. You might discover the design assumption was wrong. You might find out the integration is more complex than assumed.

Scope ambiguity. If requirements aren't clear, developers estimate the most likely interpretation. When the actual requirements are different, the estimate is wrong.

Integration uncertainty. You think an API will work one way, but it works differently. You assume you can integrate with service X in 2 days, but the documentation is poor and it takes a week.

Yak-shaving and discovery. To build feature X, you need to do task Y first. To do task Y, you need to understand how task Z works. Tasks compound. What looked like a 3-day estimate becomes a 7-day journey.

The planning fallacy. Humans systematically underestimate how long tasks take. This is a documented cognitive bias. Developers are not immune.

Professional estimators account for these uncertainties. Amateur estimators pretend they don't exist.

Estimation Approaches

T-shirt sizing (S/M/L/XL): Use this for very rough initial estimates. "Is this feature small, medium, or large?" It's useful for ordering the backlog, not for contracts. You might estimate Small as 1-5 days, Medium as 5-15 days, Large as 15-30 days. The range is wide because you don't know much yet.

Story points: A team estimates relative to past work. "Story A is a 5, and story B is twice as big, so story B is a 10." Story points are useful for planning within a team (once a team knows its velocity, you can predict capacity) but not for promising delivery dates to stakeholders. Story points are subjective between teams.

Time-based estimates (hours/days): "This will take 40 hours." This is what clients usually want—a specific number. It's also what developers are usually wrong about. Time-based estimates are useful for planning but should include buffers and confidence levels. Don't say "40 hours"—say "40 hours, could be 50 if we hit unexpected issues."

Three-point estimation: Estimate optimistic, most likely, and pessimistic. "If everything goes right, 3 days. Most likely, 5 days. If we hit problems, 10 days." Calculate a weighted average: (optimistic + 4*likely + pessimistic) / 6. This method acknowledges uncertainty while producing a single number.

For a project with 20 stories, if each has a range and you add the most-likely numbers, the actual number is usually in the pessimistic range. This is not pessimism—it's math. Variability compounds.

The Cone of Uncertainty

Early in a project, estimates are inherently uncertain. As you progress, they get more accurate. This is the "cone of uncertainty."

Before requirements are defined: Estimates are accurate within a factor of 4x. You estimate 100 days; the actual could be 25 days or 400 days. This is not an estimate—it's a wild guess.

After requirements are defined, before architecture: Estimates are accurate within 2-3x.

After architecture and technical discovery: Estimates are accurate within 1.5x.

During development, when implementation is clear: Estimates are pretty accurate (within 1.2x).

What this means: if someone gives you a quote for a custom application before requirements are defined, that quote is a guess, not a commitment. Smart companies quote a range (you can see the cone: "$150k to $600k") and narrow it down as the project progresses.

How to Use Estimates (and How Not To)

For planning and roadmapping: Estimates are useful for prioritization and scheduling. If story A is 5 story points and story B is 20, and you have 100 points of capacity per sprint, you can plan your roadmap.

Not for promises. An estimate is not a promise. It's a guess based on incomplete information. If you tell a client "this will cost $300k and be done in 6 months" and it takes $450k and 9 months, you've failed. But if you say "our estimate is $300k with a range of $250k-$400k, timeline 6 months with realistic range 5-8 months," that's a different conversation.

With buffers. If your estimate is 12 weeks, plan to communicate 15 weeks to stakeholders. If you deliver in 12, you're a hero. If you deliver in 14, you're on time.

Not as gospel. Estimates change as you learn. Week 2 of the project, you discover something you didn't know. Re-estimate. Estimates at the start are best guesses; they get better as you learn.

Fixed-Price Contracts and Estimation Risk

A fixed-price contract says: "You pay $X for this scope, no matter what." For the client, this is great—no budget surprises. For the developer, this is risky. If the estimate is wrong, the developer eats the cost.

Because of this risk, developers quote high for fixed-price work. They add safety margin: if they think 3 months, they quote 4 months. This makes fixed-price projects more expensive for the client.

Fixed-price works well when scope is very clear and the team has done similar projects before. It breaks down when scope is ambiguous or novel.

Time-and-materials (you pay for actual hours at an agreed rate) distributes risk differently. The client carries the schedule risk (it might take longer) but the developer carries less financial risk.

Many successful projects use a hybrid: fixed price for well-defined MVP scope, then time-and-materials for V2+ features.

What Affects Estimates

Several factors make estimates much harder or easier:

Team experience with the domain: A team that's built 5 similar projects estimates very accurately. A team building something entirely new estimates poorly. Choose experienced teams for important projects.

Team experience with the tech stack: A team fluent in their chosen tech estimates 30-40% more accurately than a team learning the tech on the job.

Code quality of the existing codebase: If you're adding to a clean, well-structured codebase, development is fast. If you're adding to a mess, development is slow.

Requirements clarity: Clear requirements = accurate estimates. Vague requirements = inaccurate estimates.

Dependency on external systems: If you depend on APIs, payment processors, or other systems you don't control, that introduces uncertainty.

The Estimate Talk You Should Have

When someone asks for an estimate, here&s a professional response:

"Based on our understanding of the requirements, we estimate [most likely] for this scope. We're most confident in this number if assumptions X, Y, Z are correct. If they're not, the estimate could go up to [pessimistic]. The estimate includes [how much testing, code review, etc.]. This estimate assumes we can start immediately with a team of [size]. If you want a fixed-price quote, we'd need to add 30% contingency, making it [fixed price]."

This answer is honest about uncertainty while still being useful.

Re-estimation During the Project

Projects change. You discover something unexpected. You learn that an assumption was wrong. Re-estimate. Point out that the timeline will change. Get stakeholder agreement on a new plan.

The worst thing you can do is maintain the original estimate even when you know it's wrong. Communicate the change early, when you discover it, not on day 89 of a 90-day project.