The Most Stressful Conversation in Software
Sooner or later, every PM ends up in this conversation. A stakeholder asks: How long will this take? The PM looks at the engineering lead. The engineering lead looks at the team. Somebody says two weeks or a quarter or by the end of the year. The number gets written down. Plans get made around it. Then reality happens, the work takes longer, and everyone is unhappy.
This pattern repeats so often that many engineers have lost faith in estimation entirely. Some teams have stopped doing it. Some PMs avoid the conversation. But estimation, however imperfect, is unavoidable. Companies need to plan. Customers need expectations set. Roadmaps need rough shapes. The question is not whether to estimate but how to estimate honestly.
This article covers why estimates are usually wrong (it is not because the team is bad at math), what useful estimation actually looks like, and the simple practices that turn estimation from theatre into something that helps.
Why Estimates Go Wrong
Several reasons. None is fixable by being smarter or working harder. They are baked into how software work happens.
Reason One: The Work Is Genuinely Uncertain
Software is not assembly. Every project involves things the team has never built before. Some of those things turn out to be harder than expected. A few turn out to be easier. On average, the unknowns slow things down because there are more ways for something to go wrong than to go right. This is not a team failure. It is the nature of building things that did not exist before.
Reason Two: Optimism Bias
People are bad at imagining everything that could go wrong. When a developer estimates a piece of work, they imagine the happy path and forget about the dependencies, the edge cases, the meeting time, the bug they did not know they would hit, and the design feedback that will require rework. This is not laziness; it is human cognition. The fix is structural, not moral.
Reason Three: Pressure to Underestimate
Stakeholders want fast answers. The engineer who says two weeks looks more capable than the one who says maybe three to six weeks, depending . The honest answer is the second one. The polite answer is the first. Many estimates are polite, not honest, and the resulting plans are built on polite fictions.
Reason Four: Scope Drift
The work that gets estimated and the work that actually ships are rarely the same. Requirements get added during the build. Edge cases get discovered. Stakeholders ask for one more thing. By the time it is done, the team has built something larger than the original estimate covered. The estimate was for the original scope; the work was the new scope. The math was doomed before it started.
Reason Five: Hidden Work
Estimates often cover the visible feature. They miss the testing, the documentation, the deployment work, the support of the launch, the bug fixes after, the rework when the design changes, and the meeting time to coordinate it all. The feature might be three weeks of coding. The full delivery is six to eight weeks of total effort. Estimating only the coding part undercounts by half.
What an Honest Estimate Looks Like
Honest estimates have several features in common. None of them is a single number.
They Are Ranges, Not Points
An honest estimate is three to six weeks , not four weeks . The range communicates that there is real uncertainty. A single number pretends the uncertainty is not there. People who hear single numbers plan around them as if they were facts, which produces the broken plans we keep seeing.
They Include Confidence Levels
Three to six weeks, with a sixty percent chance we hit the lower end if nothing surprising happens. The confidence is useful information. If a project must hit a deadline, knowing that the estimate is fragile is more important than the midpoint number.
They Distinguish Coding From Total Time
Two weeks of coding, but the full release including testing, rollout, and bug fixes is closer to four to six weeks of 'elapsed time. Stakeholders who care about when can we use this need the second number, not the first.
They Name the Unknowns
The biggest uncertainty is whether we can integrate with the existing payment system in less than a week. If we can, this is three weeks. If we cannot, it could be six. Naming the unknowns gives stakeholders a real picture and lets the team prioritise reducing the biggest unknowns first.
Different Kinds of Estimates
Not all estimates are the same kind of beast. Different questions deserve different methods. Mixing them up is one of the bigger sources of confusion in estimation.
T-Shirt Sizes (Rough, Early)
Small, medium, large, extra large. Used for very early estimates, often when many features are being compared at once. Useful for prioritisation conversations. This is a large and that is a small tells you something. This is six weeks and that is two days at the same stage is false precision.
Story Points (Sprint-Level)
Numbers (often Fibonacci: 1, 2, 3, 5, 8, 13) attached to individual stories during sprint planning. The numbers are relative: a five-point story is roughly two and a half times a two-point story. Over time, the team learns how many points they complete per sprint (their velocity), which lets them estimate how many stories will fit in upcoming sprints.
Time Estimates (Concrete, Late)
Three to five days for this story. Two weeks for this feature. Time estimates are most reliable when made by the people doing the work, immediately before they do it, with clear acceptance criteria. The further out in time, and the less the team knows about the work, the worse time estimates perform.
Calendar Forecasts (Roadmap-Level)
This will likely ship in Q3. Useful for roadmaps. Should always be communicated as a range, with confidence. Likely Q3, possibly slipping to Q4 if the integration work is harder than expected. Single-quarter calendar promises tend to produce the most disappointment.
Estimate Type When to Use Common Mistakes
T-shirt sizes Comparing many ideas; very early Treating S/M/L as if they were precise
stage time estimates
Story points Planning sprints; tracking team Comparing points across teams;
velocity converting points to hours
mechanically
Time estimates Stories ready to build; concrete Single numbers; not including testing
commitments and overhead
Calendar forecasts Roadmaps; stakeholder Pretending dates are commitments;
expectations not communicating uncertainty
Story Points: A Closer Look
Story points deserve their own section because they are widely used and widely misused. The original idea is simple. Each story gets a number that represents its size relative to other stories. The numbers come from the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21) because the gaps between numbers grow with size, matching how confidence about size decreases as size grows.
Why Points Instead of Hours
Hours feel precise but are not. Different developers work at different speeds. The same developer is faster on familiar work than on unfamiliar work. Hours estimates degrade quickly. Points are deliberately fuzzy and relative, which is more honest about how estimation actually works. Over time, a team learns its average points-per-sprint and can plan based on that.
How to Estimate Points
Most teams use planning poker or a similar method. Each engineer simultaneously reveals their estimate for a story. If the estimates differ widely, the team discusses why. The discussion usually surfaces hidden complexity or hidden assumptions. Then the team agrees on a number. The agreement matters more than the specific number.
Common Misuses
- 1. Treating points as hours. "If a one-point story takes four hours, a five-point story takes twenty hours." This misses the point. Five-point stories are not just larger; they are riskier. The four-times-larger story often takes six or eight times the time because the unknowns multiply.
- 2. Comparing across teams. Each team's points are specific to that team's context. Team A's five-point story and Team B's five-point story are not the same size. Aggregating points across teams produces meaningless numbers.
- 3. Inflating points to look productive. Some teams, pressured to show progress, gradually inflate their point estimates so they can claim more points per sprint. This is human and unhelpful. The remedy is to use velocity for planning, not for performance evaluation.
- 4. Demanding precision. If the team is debating between three and five for a story, the answer is probably "either is fine, pick one and move on." The cost of debating is usually larger than the cost of being slightly off.
How to Improve Estimates Over Time
Estimates do not have to stay terrible. They can get better, but only if the team treats estimation as a craft that requires feedback. Several practices help.
Track Actuals vs. Estimates
After each piece of work, record what the original estimate was and what the actual time turned out to be. Over months, patterns emerge. Maybe your team consistently underestimates by thirty percent. Maybe you underestimate small stories but overestimate large ones. Knowing the pattern lets you adjust future estimates explicitly. Without tracking, you keep making the same mistakes.
Conduct Estimation Retrospectives
Once a quarter, look at the estimates that were most wrong. Why? Was it scope drift? Hidden technical debt? An optimistic individual? A surprise dependency? The answers improve future estimates. Most teams skip this step and keep being surprised by the same things.
Add Buffers Honestly
If history says your team finishes work in twenty percent more time than estimated, build that into your numbers. The team estimates four weeks; based on history, plan for five. The buffer is not padding; it is a calibration of the estimation process itself. Stakeholders prefer the realistic number once they see how reliable it is.
Re-Estimate at Logical Points
Big work should be re-estimated as the team learns more. The estimate at the start of a quarter, before any of the work has been done, is the worst it will ever be. The estimate after two weeks of work is much better. Update stakeholders rather than treating the original number as fixed.
How to Talk About Estimates With Stakeholders
Estimation conversations get tense for predictable reasons. Stakeholders want certainty. The team has uncertainty. The PM is in the middle. Some practices help.
Communicate the Range, Not the Point
Three to five weeks is more useful and more honest than four weeks . Initially, stakeholders may push for the single number. Hold the line. After a few projects in which the range turns out to be reliable and the single number turns out to be wrong, they will start to prefer the range.
Explain the Drivers of Uncertainty
The estimate is wide because we have not built this kind of integration before. Stakeholders who understand why an estimate is uncertain handle the uncertainty better than those who do not. The explanation is part of the estimate, not decoration.
Update Frequently
Once you give an estimate, stay accountable to it. If something changes the estimate, update the stakeholder before they ask. Surprises in either direction (faster or slower) erode trust. Predictable updates build trust.
Resist Pressure to Commit Without Information
Sometimes a stakeholder will ask for a date before the team has had a chance to investigate. The right answer is I cannot give you a useful date yet, but I can give you one in two days after we look at the work properly. The two-day delay produces a usable estimate. The instant answer produces a fiction.
When Estimation Is Not Worth It
Some teams have moved to no estimates for certain kinds of work, and there are situations where that is the right call. The cost of estimating is non-zero. Sometimes the cost is larger than the value of the estimate.
- Very small stories. If a story is clearly less than a day, the estimate is not improving any plan. Just do the work.
- Highly uncertain research work. A spike to investigate a hard technical question cannot be meaningfully estimated. Time-box it instead: "we will spend three days on this and then assess what we learned."
- Continuous improvement work. Bug fixing, performance tuning, and small enhancements often work better as a steady stream than as estimated chunks. Reserve a fraction of capacity for it and stop trying to estimate each item.
- Mature, well-known work. Some teams build the same kinds of things over and over and have very stable velocity. They can plan capacity without estimating each item, just by knowing how much they ship per sprint.
A Final Word
Estimation is one of the most thankless parts of the PM job. Every estimate will be wrong. Stakeholders will remember the ones that were too optimistic and forget the ones that were too pessimistic. The team will sometimes resent being asked. And yet companies cannot operate without rough plans, and rough plans require rough estimates.
The PMs who build a reputation for honest, well-calibrated estimates have a quiet superpower. Their stakeholders trust their numbers. Their plans hold up. Their teams feel respected because the estimates are realistic instead of punitive. Reaching this state takes a year or two of deliberate practice and the discipline of tracking actuals against estimates. The investment pays back for the rest of your career.
Key Takeaways
- Every estimate is wrong. The goal is not perfect accuracy but honest communication about uncertainty.
- Honest estimates are ranges with confidence levels, distinguish coding from total elapsed time, and name the biggest unknowns explicitly.
- Different estimate types serve different purposes: t-shirt sizes for early comparison, story points for sprints, time estimates for ready-to-build work, calendar forecasts for roadmaps. Do not mix them up.
- Story points are deliberately fuzzy and relative. Common misuses include treating them as hours, comparing across teams, and demanding precision they were not designed to provide.
- Improve estimates over time by tracking actuals, running estimation retrospectives, adding honest buffers, and re-estimating as you learn. Without feedback, the same mistakes repeat indefinitely.