FSE Group

Think Tank

Ideen. Meinung. Zukunft.

Think Piece

Datum 02 / 2026

Dominic Asche

Lesezeit 3 min

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

Vom Bauchgefühl zur belastbaren Prognose.

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 richtig zu schätzen – und das gilt besonders für Softwareprojekte. Das liegt nicht nur an menschlichen Schwächen wie übermäßigem Optimismus („Optimismus-Bias“) oder der falschen Annahme, alles würde wie geplant verlaufen („Planungsfehlschluss“). Softwareentwicklung selbst ist komplex, dynamisch und voller Unsicherheiten. Ähnlich wie ein Eisberg zeigt sie an der Oberfläche nur eine kleine Aufgabe, während sich darunter eine Vielzahl verborgener Komplexitäten versteckt. Komplexität bedeutet, dass wenn ich A erledigt habe, B und alle weiteren Schritte mir noch unbekannt sind.

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 können. Zeit-Schätzungen ignorieren zudem externe Einflüsse, von Krankheit und Fluktuation im Team bis hin zu technischen Altlasten wie Legacy-Code.

Zeit als Schätzung: Irrweg!

Zeit-Schätzungen in Stunden, Tagen oder Wochen sind nicht nur irreführend, sondern regelrecht kontraproduktiv. Sie stammen aus einer Ära, in der Manager:innen und Entscheider:innen auf feste Deadlines und vermeintliche Planbarkeit pochten. Doch in der Praxis führen solche Schätzungen zu einem Fiasko. Wie der bekannte Software-Experte Steve McConnell eindrucksvoll beschreibt, bewegen wir uns immer innerhalb des sogenannten Cone of Uncertainty: zu Beginn eines Projektes sind Schätzungen unweigerlich ungenau, und erst im Verlauf des Projektes lässt sich Präzision gewinnen.

Datengetriebene Story Points

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

Bei FSE erfolgt die Aufwandsschätzung anhand eines festen, datengetriebenen Verfahrens – und zwar immer auf Basis einer vor der Schätzung erstellten, gemeinsamen Umsetzungsroadmap. Wir betrachten vier Ebenen einer Anforderung, um Unsicherheiten und Komplexitäten 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/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 so 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: Während die herkömmliche Zeitschätzung zunächst „vier Wochen“ prognostizierte, tatsächlich aber zehn Wochen benötigte, erreichten wir mit der datenbasierten Methode 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. Die Wahrheit ist: Komplexität lässt sich nicht in Kalenderwochen pressen. Führungskräfte, die das nicht verstehen, 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 klar 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