# Why people cannot estimate how long it takes to build software > From gut feeling to a reliable forecast. - **Author:** Dominic Asche - **Date:** 02 / 2026 - **Reading time:** 3 min - **URL:** https://fse-group.de/en/thinktank/warum-wir-schlecht-im-schaetzen-sind There is hardly a sentence in the IT world that causes more frowning than “when will you be done?” What starts as a simple question ends in misunderstandings, stress and disappointed expectations. But why is it actually so hard for people to estimate the duration of software projects realistically? ### Time is a poor adviser People are notoriously bad at estimating time. That is especially true for software projects. Behind it are not only human weaknesses such as excessive optimism (“optimism bias”) or the assumption that everything will go as planned (“planning fallacy”). Software development itself is complex, dynamic and full of uncertainty. On the surface you only see the visible task; beneath it lie hidden dependencies. Complexity means: once A is done, B and all further steps are often still unknown. In reality developers regularly meet incomplete requirements, unexpected technical problems and non-linear scaling, where seemingly small changes suddenly have enormous effects. Time estimates also ignore external influences, from illness and staff turnover to legacy burdens such as legacy code. ### Time as an estimate: a wrong turn Time estimates in hours, days or weeks are misleading and outright counterproductive. They come from an era in which managers insisted on fixed deadlines and supposed predictability. In practice such estimates regularly lead to fiasco. Steve McConnell describes this with the cone of uncertainty: at the start of a project estimates are inevitably imprecise; precision can only be gained as it progresses. ### Data-driven story points Anyone asking for an estimate is really asking for a plan that holds with a certain probability. This is exactly where story points show their strength: instead of estimating an idealised duration in days or weeks, the method systematically assesses the effort and complexity of a task. At FSE, effort estimation follows a fixed, data-driven procedure, always based on a shared delivery roadmap created before the estimate. We look at four levels of a requirement to make uncertainty and complexity measurable: - UI: interactions that users come into direct contact with. - Business logic: rules and processes that determine the core functionality. - Database integration: interfaces to internal and external data sources. - Manual testing: effort for manual tests beyond the defined requirements. ### This is how we make it tangible (concretely): - Scale & anchors: each level is rated on a Fibonacci scale (1, 2, 3, 5, 8, 13 …). Every step has anchor examples (for example UI=3: a form with validation; UI=8: a multi-step dialogue with edge cases). - Factors & dependencies: we record dependencies (systems, teams, approvals), unknowns (exploration), compliance steps and data quality. From this a risk factor results (0/10/20%). - Aggregation: story points = sum of the four levels × (1 + risk factor). - Calibration: based on the historical velocity (story points per sprint) of the teams involved, a range forecast is produced (for example P50/P90). - Example: feature X → UI = 5, BL = 8, DB = 3, MT = 2 → 18 SP; medium risk (+20%) → 22 SP. Team velocity: 45–55 SP per sprint → forecast: 0.4–0.5 sprints (P50), up to 0.7 (P90). - Governance: a definition of ready is a prerequisite (shared roadmap steps, acceptance criteria). Adjustments follow as knowledge grows – the forecast narrows over the life of the project. Based on historical project data and clearly defined criteria, a valid, reproducible estimate emerges in the form of story points. These points reflect technical complexity, external dependencies and risks. The effectiveness of this method is scientifically grounded and measurable. One project we supported showed it: the conventional time estimate initially forecast “four weeks”, in reality it was ten. With the data-based method we reached forecast accuracy of up to 90% within a short time. ### Time blinds you, complexity shows uncertainty Anyone still insisting on classic time estimates today is steering projects blindfolded. Time figures suggest certainty where there is none and create pressure, disappointment and friction. Complexity cannot be pressed into calendar weeks. Leaders who ignore this systematically risk misjudgements in planning, budgeting and resource management. Story points are a strategic tool. They make uncertainty visible, complexity tangible and provide a reliable basis for decisions. Companies that internalise this have an advantage. They plan more realistically, steer more efficiently and fail less often. #### Sources - McConnell, Steve: More Effective Agile: A Roadmap for Software Leaders, 2019 - McConnell, Steve: Software Estimation – Demystifying the Black Art, 2006 - Kahneman & Tversky: Planning Fallacy / Hindsight Bias