# Warum Menschen nicht schätzen können, wie lange es dauert, eine Software umzusetzen

> Vom Bauchgefühl zur belastbaren Prognose.

- **Autor:** Dominic Asche
- **Datum:** 02 / 2026
- **Lesezeit:** 3 min
- **URL:** https://fse-group.de/thinktank/warum-wir-schlecht-im-schaetzen-sind

Es gibt wohl kaum einen Satz in der IT-Welt, der häufiger für Stirnrunzeln sorgt, als: „Wann seid ihr fertig?“ Was als einfache Frage beginnt, endet in Missverständnissen, Stress und enttäuschten Erwartungen. Doch warum ist es für Menschen eigentlich so schwer, die Dauer von Softwareprojekten realistisch einzuschätzen?

### Zeit ist ein schlechter Ratgeber

Menschen sind notorisch schlecht darin, Zeit zu schätzen. Das gilt besonders für Softwareprojekte. Dahinter stecken nicht nur menschliche Schwächen wie übermäßiger Optimismus („Optimismus-Bias”) oder die Annahme, alles würde wie geplant verlaufen („Planungsfehlschluss”). Softwareentwicklung selbst ist komplex, dynamisch und voller Unsicherheiten. An der Oberfläche sieht man nur die sichtbare Aufgabe, darunter liegen verborgene Abhängigkeiten. Komplexität heißt: Habe ich A erledigt, sind B und alle weiteren Schritte oft noch unbekannt.

In der Realität treffen Entwickler regelmäßig auf unvollständige Anforderungen, unerwartete technische Probleme und nicht-lineare Skalierungen, bei denen scheinbar kleine Änderungen plötzlich enorme Auswirkungen haben. Zeit-Schätzungen ignorieren zudem externe Einflüsse, von Krankheit und Fluktuation im Team bis hin zu Altlasten wie Legacy-Code.

### Zeit als Schätzung: Irrweg

Zeit-Schätzungen in Stunden, Tagen oder Wochen sind irreführend und regelrecht kontraproduktiv. Sie stammen aus einer Ära, in der Manager:innen auf feste Deadlines und vermeintliche Planbarkeit pochten. In der Praxis führen solche Schätzungen regelmäßig ins Fiasko. Steve McConnell beschreibt das mit dem Cone of Uncertainty: Zu Beginn eines Projekts sind Schätzungen unweigerlich ungenau, erst im Verlauf lässt sich Präzision gewinnen.

### Datengetriebene Story Points

Wer nach einer Schätzung fragt, fragt eigentlich nach einem Plan, der mit einer bestimmten Wahrscheinlichkeit eintritt. Genau hier entfalten Story Points ihre Stärke: Statt eine idealisierte Dauer in Tagen oder Wochen zu schätzen, bewertet die Methode systematisch Aufwand und Komplexität einer Aufgabe.

Bei FSE erfolgt die Aufwandsschätzung nach einem festen, datengetriebenen Verfahren, immer auf Basis einer vor der Schätzung erstellten, gemeinsamen Umsetzungsroadmap. Wir betrachten vier Ebenen einer Anforderung, um Unsicherheiten und Komplexität messbar zu machen:

- UI: Interaktionen, mit denen Nutzer direkt in Berührung kommen.

- Business Logic: Regeln und Prozesse, die die Kernfunktionalität bestimmen.

- Datenbank-Integration: Schnittstellen zu internen und externen Datenquellen.

- Manual Testing: Aufwände für manuelle Tests jenseits der definierten Anforderungen.

### So machen wir das greifbar (konkret):

- Skala & Anker: Jede Ebene wird auf einer Fibonacci-Skala (1, 2, 3, 5, 8, 13 …) bewertet. Für jede Stufe gibt es Ankerbeispiele (z. B. UI=3: ein Formular mit Validierung; UI=8: mehrstufiger Dialog mit Edge-Cases).

- Faktoren & Abhängigkeiten: Wir erfassen Abhängigkeiten (Systeme, Teams, Freigaben), Unbekannte (Exploration), Compliance-Schritte und Datenqualität. Daraus ergibt sich ein Risikofaktor (0/10/20 %).

- Aggregation: Story Points = Summe der vier Ebenen × (1+Risikofaktor).

- Kalibrierung: Auf Basis historischer Velocity (SP/Sprint) der beteiligten Teams entsteht eine Bandbreiten-Prognose (z. B. P50/P90).

- Beispiel: Feature X → UI = 5, BL = 8, DB = 3, MT = 2 → 18 SP; mittleres Risiko (+20 %) → 22 SP. Team-Velocity: 45–55 SP/Sprint → Forecast: 0,4–0,5 Sprint (P50), bis 0,7 (P90).

- Governance: Voraussetzung ist eine Definition of Ready (gemeinsame Roadmap-Schritte, Akzeptanzkriterien). Nachsteuerung erfolgt bei Wissenszuwachs – der Forecast verengt sich über die Projektlaufzeit.

Auf Basis historischer Projektdaten und klar definierter Kriterien ergibt sich ein valides, reproduzierbares Schätzergebnis in Form von Story Points. Diese Punkte spiegeln technische Komplexität, externe Abhängigkeiten und Risiken wider.

Die Wirksamkeit dieser Methodik ist wissenschaftlich fundiert und messbar. Ein von uns begleitetes Projekt zeigte: Die herkömmliche Zeitschätzung prognostizierte zunächst „vier Wochen”, tatsächlich waren es zehn. Mit der datenbasierten Methode erreichten wir bereits kurzfristig Prognosegenauigkeiten bis zu 90 %.

### Zeit macht blind, Komplexität zeigt Unsicherheit

Wer heute noch auf klassische Zeitschätzungen pocht, steuert Projekte mit verbundenen Augen. Zeitangaben suggerieren Sicherheit, wo es keine gibt, und erzeugen Druck, Enttäuschung und Reibungsverluste. Komplexität lässt sich nicht in Kalenderwochen pressen. Führungskräfte, die das ignorieren, riskieren systematisch Fehleinschätzungen in Planung, Budgetierung und Ressourcensteuerung.
Story Points sind ein strategisches Werkzeug. Sie machen Unsicherheit sichtbar, Komplexität greifbar und liefern belastbare Entscheidungsgrundlagen. Unternehmen, die das verinnerlichen, sind im Vorteil. Sie planen realistischer, steuern effizienter und scheitern seltener.

#### Quellenverzeichnis

- McConnell, Steve: More Effective Agile: A Roadmap for Software Leaders, 2019

- McConnell, Steve: Aufwandsschätzung bei Softwareprojekten, 2006

- Kahneman & Tversky: Planning Fallacy / Hindsight Bias