Software estimation has a bad reputation, and much of it is deserved. Projects run late, scope expands, and the initial timeline looks increasingly fictional as the deadline approaches. But the failure mode isn’t that estimation is impossible — it’s that most teams are doing it wrong, asking the wrong questions, ignoring the right data, and using estimates for purposes they’re not suited for.
Good project estimation isn’t about predicting the future with precision. It’s about making informed decisions under uncertainty, surfacing risks early, and maintaining calibration over time. These are learnable skills, and teams that develop them ship more predictably than teams that treat estimation as guesswork or theater.
The Two Failure Modes
Teams fail at estimation in two distinct ways. The first is overconfidence: estimates that assume everything goes right, no unknown unknowns emerge, no dependencies slip, and no engineer gets sick for a week. These estimates feel good in sprint planning and look terrible in retrospectives. The second failure mode is sandbagging: padding estimates so generously that no one believes them, which destroys their information value and creates perverse incentives around what done means.
Neither failure mode is solved by better arithmetic. Both are solved by changing what estimation is for.
Estimate Ranges, Not Points
A single number — this will take three weeks — communicates false precision. The actual information is something like: under good conditions, two weeks; under typical conditions with one or two surprises, three to four weeks; if we hit a major unknown, five or six. That’s a distribution, not a point, and planning around a distribution produces better decisions.
In practice, this means communicating estimates as ranges with named conditions. Pulse lets you annotate tasks with confidence levels and risk flags, so the project view shows not just what’s scheduled but how confident the team is about each piece. Stakeholders who understand that a feature is on track at medium confidence make better prioritization decisions than stakeholders who see a green status and assume certainty.
Use Historical Cycle Time, Not Intuition
The most reliable input to a new estimate is historical data from similar past work. How long did the last three API integrations take, from first commit to deploy? How long do database migration tasks typically run versus their initial estimate? This data exists in every team’s project history, and almost no one uses it systematically.
- Track actual cycle time against estimated time for every task over a 60-day period
- Calculate your team’s estimation accuracy by task type and complexity level
- Use these ratios to calibrate future estimates — if your team consistently underestimates database work by 40 percent, adjust accordingly
Pulse surfaces this data automatically in the sprint analytics view: estimated hours versus actual hours by task type, broken down by engineer and sprint. Within two or three sprints of actively using this data, teams see significant improvement in estimation accuracy.
Separate Estimation from Commitment
A critical dysfunction in many organizations is treating estimates as commitments. When how long will this take is heard as promise me a date, engineers respond with inflated numbers designed to protect themselves rather than honest ranges designed to inform planning. This destroys the information value of estimation entirely.
Good estimation culture requires explicit separation: an estimate is a prediction based on current knowledge, and it will be updated as knowledge changes. A commitment is something different — a deliberate choice to prioritize and protect a deadline — and it should be made consciously, not conflated with an estimate. Leaders who understand this distinction get better estimates, because engineers trust that honesty won’t be punished.
Build in Re-estimation Checkpoints
A project estimate made at the start of discovery will be wrong. Not because the team is bad at estimation, but because the start of discovery is the point of minimum information. Good estimation practice includes planned re-estimation checkpoints as information accumulates: after design is complete, after the first working prototype, after the first integration test. Treat the initial estimate as a hypothesis and each checkpoint as an opportunity to update it with real data. Teams that build this habit stop dreading the retrospective conversation about why the timeline slipped, because they’ve been having that conversation continuously throughout the project rather than only at the end.