Estimates are difficult for developers and product owners

📝 Discussion Summary (Click to expand)

The three most prevalent themes in the discussion are:

1. The Conflict Between Estimates as Forecasts vs. Estimates as Commitments

Many users noted that while estimates are inherently guesses about unknown work, management often treats them as unchangeable deadlines, leading to negative consequences.

Supporting Quote: "But after a while you learn that when they say 'What's the estimate for feature F?', they're in fact saying 'What deadline you wish to impose on yourself for feature F?'" - skydhash
Supporting Quote: "The estimates stopped being estimates. They became safety railings against being held accountable for unreasonable expectations." - vegetablepotpie

2. Software Novelty Makes Accurate Estimation Uniquely Difficult

A significant portion of the conversation revolved around the idea that software development, especially when involving innovation, deals with inherently novel problems, unlike repetitive physical engineering tasks (like building a standard bridge or airplane part). This novelty makes accurate forecasting extremely hard.

Supporting Quote: "But in the software world, predictable and repetitive tasks are also the kinds of tasks that are most easily automated, which means the time it takes to perform those tasks should asymptotically approach 0." - yen223
Supporting Quote: "Good software developer should always be solving new problems, as by the nature of software, once they solve a problem, they never solve that (exact) problem again. So we are persistently incompenent [sic]." - gilbetron

3. The Value of Iterative/Agile Approaches Over Fixed Estimates

Several participants advocated for methods that prioritize frequent delivery and learning (like Kanban or XP) over detailed upfront estimation, arguing that shipping early provides better information than prediction.

Supporting Quote: "Effort put into careful estimates is almost always better put into early, iterative delivery and product management that maximizes the information gained. Shipping early and often buys much clearer information on both I and R than you can ever get in a conference room." - wpietri
Supporting Quote: "The PM can use these complexity estimations + historical team performance to estimate time. The team is happy because they are not responsible for the PM's bad time estimation..." - rendall

🚀 Project Ideas

Evidence-Based Velocity Tracker (EBVT)

Summary

A service that automatically ingests historical task completion data (e.g., from Jira/GitHub Issues) and uses empirical analysis (like the data tracking mentioned in evidence-based scheduling) to generate and visualize probabilistic forecasts for future features.
Core value proposition: Provides data-driven, less subjective estimate ranges rather than single-point commitments, directly addressing the pain point that accurate range estimates are a "super-power" but require effort many teams skip.

Details

Key	Value
Target Audience	Product Owners, Engineering Managers, and teams frustrated by pressure to provide false precision.
Core Feature	Automated ingestion and analysis of historical throughput/cycle time to produce Monte Carlo simulation forecasts shown as likelihood curves (e.g., "90% chance this feature will finish between Week 8 and Week 12").
Tech Stack	Backend: Python (Pandas/NumPy for statistics, FastAPI for API). Frontend: React/TypeScript. Data Source Integrations: REST APIs for Jira, Linear, GitHub Projects.
Difficulty	Medium (Data normalization and statistical modeling complexity).
Monetization	Hobby

Notes

Why HN commenters would love it: It tackles the need for scientific rigor: "Evidence-based" stats tracking is the only somewhat scientific method I know of that can give you a good range of estimates." It directly supports the Kanban/flow mindset by focusing on validated historical data rather than initial speculative estimates.
Potential for discussion or practical utility: It provides a tool to mediate the conflict between stakeholders who demand dates (Zdragnar) and developers who see estimates as weaponized.

Stakeholder Expectation Communicator (SEC)

Summary

A lightweight tool that visualizes why an estimate is uncertain by forcing the estimator to categorize and score the underlying knowledge/assumptions, similar to the ROPE method but explicitly for knowledge gaps.
Core value proposition: Turns the "unknown unknowns" into quantified risk factors, helping managers understand that scope uncertainty is the core reason for large error bars, thus facilitating better negotiation ("If you want to de-risk this part, we need time for research").

Details

Key	Value
Target Audience	Developers, Tech Leads, and Product Managers struggling to communicate uncertainty ("When you say 'What's the estimate?', they're in fact saying 'What deadline you wish to impose on yourself?'").
Core Feature	For any given task/feature, the user inputs a time estimate, then scores several dimensions (e.g., Design Clarity, Dependency Visibility, Novelty, Coordination Overhead). The tool then generates a variance multiplier based on the scores.
Tech Stack	Frontend focused: Vanilla JS/Svelte for lightweight performance, perhaps using WebAssembly if complex visualization is added later. Stored via browser local storage or simple backend service (e.g., Firebase).
Difficulty	Low/Medium (Simple UI and calculation logic, but requires careful UX development to make the scoring useful).
Monetization	Hobby

Notes

Why HN commenters would love it: It directly addresses the issue that estimates are difficult because "prerequisites and constraints are not clear or not fully known." It gamifies surfacing these hidden factors rather than ignoring them.
Potential for discussion or practical utility: It provides a structured way for developers to push back professionally, shifting the conversation from "your estimate is wrong" to "we discovered assumptions driving the uncertainty."

Complexity-to-Time Decoupler (CTD)

Summary

A centralized service that manages and visualizes team velocity based on unitless Story Points or complexity scores, while providing PMs with customizable, historical "translation factors" (velocity mapping) rather than forcing developers to estimate in hours.
Core value proposition: Accepts the reality that complexity estimation is easier/more reliable than time estimation ("Story points or even story points are way more effective"), but provides a structured, transparent bridge for management to translate that complexity back into calendar timelines.

Details

Key	Value
Target Audience	Agile teams tired of points devolving into implicit time estimates ("points were always just a proxy for time") but still needing a metric for sprint planning and capacity management.
Core Feature	Maintain historical velocity (Points/Sprint) for specific feature types or team contexts. Allow PMs to define a "Complexity Conversion Rate" (e.g., "For standard CRUD this quarter, 1 PP = 1.5 days") which is clearly labeled as an interpretation for planning, separate from the team's complexity estimate.
Tech Stack	Backend: Go (for performance in high-throughput tracking). Database: PostgreSQL. Integration with existing Sprint tools (Jira/Azure DevOps) via webhooks to capture completed points and calculate velocity averages.
Difficulty	Medium (Requires robust integration layer and historical performance tracking, but the core calculation is straightforward averaging).
Monetization	Hobby

Notes

Why HN commenters would love it: It supports the concept of relative complexity estimation ("we are much better at estimating complexity") while still allowing business stakeholders to manage their schedules, satisfying both sides of the debate.
Potential for discussion or practical utility: It offers a concrete answer to "How does the PO translate the complexity to time?" by making that translation process explicit, visible, and historically validated, mitigating the risk of timeline coercion discussed by multiple users.