Everyone knows the estimates are wrong. Everyone uses them anyway. Here is how to make them useful.
Software estimation has a credibility problem. Everyone knows the estimates are wrong. Everyone uses them anyway. The question isn’t how to make estimates perfect — it’s how to make them useful.
Estimation doesn’t fail because teams are incompetent. It fails because every traditional method assumes conditions that almost never exist in practice.
Requirements are incomplete — always. The client doesn’t know what they want until they see what they don’t want. The PM wrote a spec that covers the happy path but not the twelve edge cases that surface in week three. Dependencies between systems haven’t been mapped because no one’s built this particular combination before.
And yet every estimation method starts from the premise that you know what you’re building. You don’t. Not fully. Not yet.
The cone of uncertainty, developed by Barry Boehm and refined by Steve McConnell, quantifies this gap. At the start of a project, before detailed requirements exist, estimates are typically off by a factor of four in either direction. A feature you estimate at four weeks might take one — or sixteen. That’s not a rounding error. That’s a fundamentally different project.
The data hasn’t improved with time. A 2024 BCG survey of global C-suite executives found that nearly half reported more than 30% of their IT projects coming in over budget and late. The Standish Group’s CHAOS reports, tracking IT project outcomes since 1994, continue to show that only about 31% of projects meet their original success criteria. This isn’t an outlier problem. This is the baseline.
Most teams rely on some combination of four approaches. Each has merit. None solves the core problem.
| Method | What it does well | Where it breaks down |
|---|---|---|
| Expert judgment | Captures tacit domain knowledge | Anchoring; only as good as the expert’s direct experience |
| Analogy-based estimation | Leverages organizational memory | Requires truly comparable past projects; rarely exists |
| Parametric models (COCOMO) | Enforces structural thinking | Key inputs (lines of code, function points) are themselves guesses |
| Planning poker | Surfaces team disagreements early | Anchoring still happens; slow for large backlogs |
Expert judgment is the most common and least structured. A senior developer reviews requirements and gives a number based on experience. When the expert has built something nearly identical before, this works. When they haven’t, it’s intuition wearing the costume of analysis.
Analogy-based estimation compares the current project to past projects. More disciplined than gut feel, but it requires comparable prior work. Even when the domain matches, team composition, tech stack, and integration complexity can make two “similar” projects wildly different.
Parametric models like COCOMO attempt to formalize the relationship between project size and effort. The math is sound. The problem is the inputs. COCOMO requires you to know the system size before building it — and that input is itself a guess.
Planning poker is the agile answer to estimation bias. The team independently assigns story points to each task, then discusses disagreements. In theory, this prevents the loudest voice from dominating. In practice, anchoring still happens, the process is slow, and the output reflects group psychology as much as engineering analysis.
If these methods fail so reliably, why does everyone keep using them? Three reasons.
First, organizations need a number. Budgets require numbers. Contracts require numbers. Board decks require numbers. The pressure to produce a specific figure overwhelms the honest answer — which is usually “it depends on at least six things we haven’t figured out yet.”
Second, estimation is often performed by the people who will do the work, or by the vendor who will bill for it. Both have incentives that don’t fully align with accuracy. Internal teams underestimate to get project approval. Vendors underestimate to win the deal, then recover margin through change orders. Neither is acting in bad faith necessarily — the system rewards optimism and punishes expressed uncertainty.
Third, there’s no widely accepted alternative. If you reject lump-sum estimates, what do you replace them with? Most buyers don’t have a framework for evaluating a range-based estimate, and most vendors aren’t structured to sell one. So the industry defaults to false precision because it’s legible, even when it’s wrong.
The shift that matters isn’t methodological — it’s conceptual. Stop treating an estimate as a prediction. Start treating it as a calibration tool.
A prediction says: “This will cost $200,000 and take five months.” A calibration says: “Based on the current scope, cost likely falls between $150,000 and $280,000, with the range driven by these specific unknowns.” The second statement is less satisfying. It’s also more honest, and far more useful for decision-making.
Story points measure relative complexity rather than time. A feature rated at 8 points is roughly twice as complex as one rated at 4, regardless of who builds it or how fast they work. For early-stage estimation — before a team is assigned and before implementation details are decided — story points are a more honest unit than hours.
This is where AI-assisted estimation changes the equation. Not because AI is smarter than your senior developer — it isn’t, for any single project. But because it does something no individual can do: pattern-match across thousands of projects simultaneously. When a senior developer estimates a feature, they’re drawing on maybe 20 or 30 comparable builds they’ve personally experienced. An AI estimator draws on patterns from thousands. It won’t catch the nuance that your particular legacy API is a nightmare to integrate with — but it will flag that “user authentication with SSO” is consistently underestimated by teams encountering it for the first time.
Describe your software or AI project. Get a full scope with story-point pricing, sprint estimates, and a downloadable plan in minutes. No calls, no waiting.
Scope Your Project for FreeFree and instant. Try the estimator now.
Here is a practical process that works whether or not you use any particular tool.
Start with a plain-language project description. Not a spec. Not a PRD. A clear description of what the software needs to do, who uses it, and what outcomes matter. If you can’t describe it without jargon, you don’t understand it well enough to estimate it.
Generate an initial scope with story points. Whether you do this with AI, an experienced architect, or your team, the goal is the same: break the project into feature areas, break features into tasks, and assign relative complexity. Resist the urge to convert to hours immediately. Stay in story points until the scope is stable.
Review and adjust with your team. No automated estimate captures everything. Review the output with people who know the domain, the tech stack, and the integration landscape. The value of the initial estimate isn’t that it’s right — it’s that it gives the team something concrete to react to rather than starting from a blank page.
Use the estimate to budget and negotiate. A structured, range-based estimate is a different negotiating tool than a lump-sum quote. When a vendor says “$250,000,” you can now ask: “For which features? At what story point sizing? With what assumptions about integrations?” If their scope doesn’t match yours, you’ve found the gap before signing — not after.
The teams that estimate most accurately are not the ones with the best tools. They’re the ones that have built the same kind of thing before. AI estimation tries to approximate that experience at scale — not to replace expertise, but to make it available earlier in the process, before the budget is locked and the contract is signed.
Perfect estimation is a fantasy. But useful estimation — the kind that tells you where the risks are, what the assumptions are, and what the range looks like — is achievable. It just requires giving up the comfort of a single number and replacing it with something messier and more honest.
You don’t need a perfect estimate. You need one that’s structured enough to argue with. The rest is conversation. Try the Fraction estimator with your project brief — it won’t give you a final number, but it’ll give you a structured breakdown you can actually push back on.
Software estimates fail because every traditional method assumes you know what you’re building — but requirements are almost always incomplete at the point when estimates are needed most. The cone of uncertainty quantifies this: at the start of a project, estimates can be off by a factor of four in either direction. This isn’t a team competency problem; it’s baked into the estimation process itself.
No single method is reliably accurate. The best approach is triangulation: combine expert judgment, analogy-based sizing, and AI-assisted pattern matching, then treat disagreement between methods as a signal worth investigating. Teams that estimate well don’t pick one method and trust it — they look for where methods converge and where they diverge.
Story points measure relative complexity rather than time. A feature rated at 8 points is roughly twice as complex as one rated at 4, regardless of who builds it or how fast they work. Hours conflate effort with duration and assume you already know who is doing the work. At the early estimation stage, story points are a more honest unit because they make uncertainty visible rather than hiding it inside a false hour count.
Outcome-based pricing ties payment to delivered features rather than hours logged. This shifts the risk of estimation error from the buyer to the vendor, which creates a strong incentive for the vendor to scope accurately before committing. It also makes the estimate visible and arguable: you can compare vendors on a per-story-point basis and ask what assumptions drive their pricing.
A 2024 BCG survey of global C-suite executives found that nearly half reported more than 30% of their organization’s IT projects coming in over budget and late. The Standish Group’s CHAOS reports have tracked IT project outcomes since 1994 and continue to show that only about 31% of projects meet their original success criteria. Overruns are the norm, not the exception.
AI estimation tools help by pattern-matching across thousands of past projects simultaneously — far more than any individual developer can draw on. They won’t catch nuance specific to your legacy stack or team dynamics, but they reliably flag feature categories that are consistently underestimated by teams encountering them for the first time. The output is a structured baseline to react to, not a final answer.
Praveen Ghanta is a five-time founder and serial entrepreneur. He is the founder of DevHawk.ai, an AI-powered engineering management platform, and Fraction.work, which connects fast-growing companies with top fractional tech and growth marketing talent. Previously, he founded HiddenLevers, a risk analytics platform for wealth management that he bootstrapped from inception to acquisition by Orion Advisor Solutions in 2021, serving thousands of advisors and $600B in assets. He earlier founded SmartWorkGroups, acquired by Intralinks in 2000.
Connect on LinkedIn →Describe your software or AI project. Get a full scope with story-point pricing, sprint estimates, and a downloadable plan in minutes. No calls, no waiting.
Scope Your Project for FreeWorking on a data strategy? Talk to a Fraction CTO. → Book an intro call
