Estimates are difficult for developers and product owners

Why Software Estimates Are Hard

• Many comments argue software work is inherently novel and complex, so past effort doesn’t transfer cleanly; “easy, repeatable” tasks tend to get automated away.
• Unknown prerequisites, unclear constraints, and hidden code interactions often dominate effort and only surface mid‑implementation.
• Time distributions are seen as heavy‑tailed/log‑normal: a “simple” task can blow up by orders of magnitude, not just 20–30%.

Estimates vs. Commitments

• Developers report that “estimates” quickly become deadlines and self‑imposed promises; ranges are collapsed to single dates via a “telephone game” up the org chart.
• Re‑planning is often treated as failure instead of learning, so people pad aggressively to protect themselves, which wastes time and erodes trust.
• Some describe estimates as tools of control or “debt servitude” for PMs and sales, similar to sales forecasts.

Value of Estimates and Counterarguments

• Others insist estimates are necessary for prioritization (is a feature worth 2 weeks vs 2 months?), coordination with marketing, sales, legal, and external commitments.
• Comparison to other engineering fields: bridges, films, pharma all miss estimates too, but still estimate and buffer (contingencies, change orders).
• A strong view: if software wants to be treated as a real engineering profession, it must be able to justify at least rough, order‑of‑magnitude estimates.

Methods and Heuristics

• Techniques mentioned: Delphi/Delphi‑like group methods, three‑point/PERT, ROPE (realistic/optimistic/pessimistic/“equilibristic”), Monte Carlo forecasts, cone of uncertainty.
• Agile techniques: planning poker with Fibonacci story points (complexity, not time), t‑shirt sizing, or coarse buckets (day/week/month/year).
• Heuristics: multiply by 2–π–8, move to next larger unit, always give ranges and confidence (P50/P90) instead of single numbers, and continuously update estimates as you learn.

Process, Tools, and Culture

• Strong support for Kanban/continuous delivery with rolling priorities and avoiding hard external dates; Scrum/SAFe are criticized as “Agilefall” when coupled to rigid roadmaps.
• Several emphasize that accurate forecasting depends on historical data and stable processes (“evidence‑based scheduling”), but few orgs systematically collect and analyze that.
• Jira and similar tools are seen as necessary for visibility by PMs but as “translation tax” by devs when they must constantly maintain tickets.
• Broad agreement that the real lever is trust, frequent delivery, and honest communication about uncertainty; without that, any estimation scheme gets weaponized or ignored.