How I estimate work

Role of Estimates in Organizations

• Many see estimates as primarily a political and budgeting tool, not an engineering tool: they decide which work gets funded, sequenced, or cut.
• A recurring theme: stakeholders almost always have a hidden time budget (“appetite”) and use “estimates” to back into that, rather than to discover it.
• Several commenters argue estimates are not really for engineers; they’re for sales, marketing, finance, CX, etc. to plan commitments, budgets, and launches.

Difficulty and Uncertainty in Estimation

• Strong disagreement over the statement “it is not possible to accurately estimate software projects.”
• One camp says unknown unknowns, changing requirements, and exploratory work make accurate estimates fundamentally unreliable beyond small, well‑understood tasks.
• Others insist estimation is a learnable skill: use historical data, repeated practice, and tight coupling between estimation and execution to get within ~10–20% at team level.
• People highlight that the truly hard part is genuine technical or requirements ambiguity, not just code size.

Business Pressures and Cross-Functional Tensions

• Sales and product “need dates” to close deals and plan roadmaps; “it’ll be done when it’s done” is seen as untenable for many businesses.
• Several anecdotes describe sales overpromising dates and then blaming engineering, and engineers underestimating impact of missed dates on revenue.
• House‑renovation and bridge analogies are debated: critics say other industries also routinely miss estimates; defenders note they still must estimate to win work.

Scope, Time, and Quality Trade-offs

• Popular framing: time, scope, and cost/quality—pick two. Fixing both time and scope is called unrealistic except for trivial work.
• Many endorse the article’s strategy: discover the acceptable time range, then flex scope and implementation approach to fit it (multiple “trim levels,” MVP vs deluxe).
• Others argue this only works if engineering is genuinely allowed to cut scope and adjust quality.

Estimation Techniques and Practices

• Heuristics mentioned: multiply original guess by 2 (or π), escalate to the next “human unit” (days→week→month), 1h/1d/1w/1m buckets, “two‑days‑or‑less” thumbs‑up, tracer‑bullet PoCs.
• Strong split over story points, t‑shirt sizes, and planning poker: some report good aggregate accuracy and valuable team discussion; others find them burdensome, ambiguous, and invariably translated back into time anyway.
• Several emphasize closing the loop—systematically comparing estimates to actuals and using historical team velocity or function‑point‑like measures.

Team, Process, and AI Factors

• Estimates depend heavily on who does the work, competing priorities, interrupts, and team composition; engineers are not fungible.
• Some report better discipline and deadline performance in hardware/semiconductor contexts than in web/SaaS.
• LLMs are being experimented with for estimation and exploratory implementations; current sentiment is that they overestimate and lack real sense of time, but can help surface unknowns and alternate designs.