When did estimates turn into deadlines?

Why Estimates Become Deadlines

• Many commenters say the first number uttered “sticks” due to anchoring bias; managers often treat it as a commitment, not a forecast.
• Estimates tend to get propagated up the org chart or into sales promises and then become politically immovable.
• Some report estimates being aggressively “negotiated down” and then enforced as hard deadlines.

Padding, Heuristics, and Coping Strategies

• Widespread use of rules of thumb:
  • Multiply by 2 or 3 (or π), or “double and bump the unit” (hours→days, days→weeks).
  • Give ranges (e.g., 6 weeks ± 2) or confidence levels (e.g., 90% likely).
• Many explicitly overestimate to survive blame culture, handle scope creep, and create slack for untracked but necessary work (documentation, mentoring, firefighting).
• Others warn that “super-inflated” estimates can look incompetent, especially to technically savvy managers.

Management, Culture, and Incentives

• Bad patterns described:
  • Treating every estimate as a deadline; ignoring changing specs; punishing overruns, ignoring causes.
  • High “volatility” in sprints (constant ticket swaps) destroying predictability.
• Some argue good managers use estimates as planning tools, accept uncertainty, and shield teams; bad ones use them as sticks.
• Several highlight that managers themselves face pressure from their own bosses, customers, and investors who need dates to coordinate sales, marketing, and contracts.

Nature of Software Estimation

• Debate over whether poor estimates are a “skill/experience issue” or fundamentally constrained by unknowns and lack of upfront paid investigation.
• Comparisons to construction, healthcare, and law: other fields also estimate and pad for risk, but software’s novelty, legacy complexity, and cross-team dependencies make it harder.
• Spiral/iterative development and “no estimates” approaches are suggested to focus on delivering small increments and learning, rather than long-range precision.

Proposed Better Practices

• Break work down; estimate only well-understood chunks.
• Explicitly separate scope (“engine” vs “complete feature”).
• Communicate ranges, risks, and confidence, and update regularly.
• Track actual vs estimated to calibrate multipliers per team/person.
• Fix culture: blameless postmortems, tolerance for honest misses, and realistic alignment of value, scope, and time.