Glossary
Effort estimation predicts time and resources required for development tasks. Accuracy improves through reference class forecasting, breaking down scope, and providing estimators with codebase context before estimating - not through better guessing technique.
I've shipped hundreds of estimates across three companies. My accuracy improved dramatically when I stopped relying on gut feel and started using historical data from our actual codebase.
Effort estimation is the process of predicting the amount of time, resources, work, or complexity required to complete a software development task - whether that task is shipping a feature, refactoring a module, fixing a bug, or paying down technical debt. It is one of the most persistently difficult problems in software engineering, not because engineers are bad at estimating, but because software work is non-fungible. Two tasks that seem similar on paper ( "Update the user profile API" and "Update the billing API") can differ by 10x in effort depending on codebase context: coupling, existing test coverage, architectural constraints, prior changes to those modules, and the experience of the engineer. Effort estimation has systematic biases that make estimates consistently wrong: optimism bias (assuming best-case conditions), scope inflation (discovering unknowns after estimation), unknown unknowns (not knowing what you don't know), and anchoring (settling on the first number suggested). What actually improves accuracy is not better estimating technique but better information. Estimators who have visibility into the codebase they're estimating produce tighter estimates because they can see constraints, dependencies, and complexity that make a difference.
Estimation failures create two cascading problems: missed commitments and schedule pressure. When estimates are systematically optimistic, delivery dates slip. Stakeholders learn not to trust estimates, which reduces their confidence in product leadership's planning. Engineering teams respond to pressure by cutting corners ( skipping tests, rushing reviews, deferring documentation), which increases technical debt and creates cascading failures downstream. Accurate estimation breaks this cycle.
Estimation accuracy also affects roadmap credibility. A product manager commits to shipping three features this quarter. If estimates are honest and grounded in reality, the PM can explain why: "Feature A takes 5 weeks, Feature B takes 3 weeks, Feature C takes 4 weeks. Our team velocity is 10 points per week. That's 12 weeks of work. We have 13 weeks this quarter, so we can ship all three." That's credible. When estimates are optimistic, the PM commits to the same three features, but actual delivery takes 16 weeks. The PM is seen as a poor planner or liar, even though the problem was estimation, not planning.
From a resource allocation perspective, estimation affects team sizing. If a company estimates projects take 10 weeks but really take 14 weeks, the company will chronically be understaffed for the work they're committing to. Accurate estimation reveals the true demand and lets companies right-size teams. Chronic understaffing (which is what inaccurate optimistic estimation creates) reduces velocity, increases burnout, and drives engineer turnover.
A product manager brings a new feature to the engineering team: "Add export functionality so users can download their data as a CSV file." The team estimates it at 3 weeks (12 story points, assuming 4 points per week velocity). Three weeks later, the feature is shipped.
What determines that estimate? Not the complexity of generating a CSV file ( that's trivial). The estimate depends on context questions:
The estimated effort varies wildly based on these answers:
The feature is the same - export data. The effort is different because the codebase context is different. Estimators who understand the codebase context before estimating produce more accurate estimates because they factor in these constraints. Estimators who don't have that context estimate optimistically (Scenario 1) and miss the real risk (Scenarios 2 and 3).
Estimation accuracy improves through three mechanisms:
First, reference class forecasting: Don't estimate in a vacuum. Find similar historical work. "We did something similar last quarter. That was 6 weeks. This seems slightly smaller, so 5 weeks." Reference class forecasting beats intuition. When no similar work exists, admit uncertainty: "We have no reference class, so this estimate is uncertain. I'd estimate 5-9 weeks depending on what we learn." Expressing uncertainty ranges is more honest and useful than pretending precision.
Second, breaking down scope: Large estimates are inaccurate. Breaking a feature into smaller pieces makes estimates tighter because less uncertainty attaches to each piece. Instead of "Export feature: 8 weeks", break it into "Generate CSV from user table (2 weeks), Handle permissions (1 week), Add GDPR compliance (2 weeks), Create async export job (1 week), Add progress UI (1 week), Testing and edge cases (1 week)." The sum is still 8 weeks, but each piece is estimated with more confidence.
Third, codebase familiarity: Estimators who know the code they're estimating produce better estimates. They understand where the complexity is. This is why estimators should review code before estimating. The PM's role is to provide that opportunity: "Before we estimate, here's the existing export code (if it exists). Here's the permissions layer. Here's the data schema." Estimators who spend 30 minutes reviewing the relevant code estimate more accurately than estimators who estimate cold.
From a product team perspective, PMs can improve estimation accuracy by:
"Bad estimates are because engineers can't estimate." Engineers who estimate poorly are usually working with incomplete information. Ask an engineer for an estimate without context, and they'll guess. Give them the same engineer access to relevant code, prior work, and architectural constraints, and their estimate will improve. The problem is rarely the estimator, usually the information available to them.
"We should increase capacity to hit aggressive timelines." Adding engineers doesn't proportionally increase velocity in mature codebases. The ramp time for new engineers and communication overhead often offsets the additional capacity in the short term. Aggressive schedules are an estimation problem, not a capacity problem. The right response is to estimate honestly, then negotiate scope or timeline based on realistic capacity.
"Story points should measure complexity, not time." Story points collapse two dimensions (complexity and uncertainty) into one number. That number means different things to different people. Team A says "5 points = complex but well-understood." Team B says "5 points = medium effort." Team C says "5 points = about a week." The ambiguity is the problem. Better to estimate in explicit terms: effort (weeks), uncertainty (low / medium / high), and complexity (low / medium / high) as separate dimensions.
Q: Should product managers attend estimation? Yes, for clarification. The PM should explain requirements during estimation, not negotiate the estimate downward. If an estimate feels high, the PM's job is to understand why and check if there's scope to reduce. If the estimate is high because the codebase is genuinely complex, that's information the PM needs to make roadmap decisions.
Q: How do we estimate work we've never done before? Find the closest reference class ("This billing integration is similar to the payment integration we did last year, which was 6 weeks"), break it into smaller pieces, and be explicit about uncertainty. "6-9 weeks, depending on API stability and test coverage of the billing system." Acknowledging uncertainty is more useful than false confidence.
Q: Should we compare estimates across teams? No. Story point systems are team-specific and incommensurable across teams. Team A's 5 points ≠ Team B's 5 points. Velocity comparisons between teams are meaningless. Velocity trends within a team are meaningful.
Keep reading
Related resources
