Das Schätzen von Softwareprojekten war lange eine unbefriedigende Angelegenheit. Planning Poker gespielt, T-Shirt-Größen vergeben, Punkte geklebt. Die Ergebnisse waren selten belastbar genug, um daraus ein Kundenangebot abzuleiten.

Nach 15 Jahren Projektarbeit mit Kunden wie der ERGO, der Deutschen Post und der Deutschen Bahn ist die Überzeugung gereift: Schätzungen sind nicht das Problem. Unstrukturierte Schätzungen sind das Problem. Und der Verzicht auf Schätzungen ist das größte Risiko von allen.

Warum Schätzungen kein Overhead sind

„Aufwandsschätzungen sind Zeitverschwendung.“ Diese Position taucht regelmäßig auf, von Entwicklern und Projektverantwortlichen gleichermaßen. Schätzungen werden entweder übersprungen oder pflichtmäßig durchgeführt, weil es im Prozess vorgesehen ist. In beiden Fällen geht der eigentliche Wert verloren.

Denn der Wert einer Schätzung entsteht nicht erst mit dem Ergebnis. Er entsteht bereits während des Schätzprozesses:

Die Fachlichkeit wird tiefer durchdrungen, als es eine reine Anforderungslektüre ermöglicht. Entwickler setzen sich aktiv damit auseinander, was die Software leisten soll. Kritische Rückfragen decken Lücken in den Anforderungen auf, die sonst erst während der Implementierung sichtbar würden. Der Fachbereich wird gezwungen, vage Formulierungen zu konkretisieren.

Ein Feature, das nach einer kritischen Rückfrage komplett neu gedacht wird, kostet 1 bis 2 Stunden Diskussion. Das gleiche Feature ohne Rückfragen implementieren und dann im Benutzertest feststellen, dass die Grundannahme falsch war, kostet ein Vielfaches.

Das Coastline Paradox und seine Parallele zur Softwareschätzung

1967 stellte der Mathematiker Benoît Mandelbrot eine Frage, die auf den ersten Blick trivial wirkt: Wie lang ist die Küste von Großbritannien?

Die Antwort hängt vom Maßstab ab. In 100-km-Schritten gemessen sind es etwa 2.800 km. In 10-km-Schritten etwa 5.500 km. In 1-km-Schritten etwa 17.800 km. Je feiner der Maßstab, desto mehr Buchten, Fjorde und Felsen werden erfasst. Mandelbrot nannte das „Coastline Paradox“.

Die Parallele zur Softwareschätzung ist aufschlussreich. Je tiefer man in die Anforderungen eines Projekts einsteigt, desto mehr Komplexität wird sichtbar: Edge Cases, Integrationsanforderungen, Migrationspfade, Fehlerbehandlung. Jede Analyseebene offenbart neue Details.

Aber es gibt einen entscheidenden Unterschied: Eine Küste ist geometrisch fix. Die Details waren immer da, man sieht sie nur bei höherer Auflösung. Software-Anforderungen dagegen sind emergent. Sie verändern sich, während man sie analysiert. Neue Fragen führen zu neuen Anforderungen. Das Verständnis des Problems verändert das Problem selbst.

Bedeutet das, dass Schätzungen sinnlos sind? Im Gegenteil. Wer ernsthaft schätzt, muss Anforderungen durchdenken. Muss Fragen stellen, die sonst erst in der Implementierung auftauchen. Muss Abhängigkeiten erkennen, bevor sie zu Blockern werden. Und das Geschäft braucht eine Grundlage: Ohne belastbare Aufwandsindikation ist keine sinnvolle Entscheidung über Invest versus Mehrwert möglich.

Das Problem mit Bauchgefühl-Schätzungen

Bauchgefühl-Schätzungen sind die häufigste Methode und gleichzeitig die unzuverlässigste. Das typische Szenario läuft so ab: Ein Meeting, jemand wirft eine Zahl in den Raum, die Runde nickt. Ohne strukturierte Analyse, ohne historische Daten, ohne Risikobewertung.

Selbst erfahrene Software-Teams mit bewährten Verfahren und historischen Vergleichswerten liegen regelmäßig daneben. Softwareentwicklung ist komplex und schwer planbar. Wenn Experten mit strukturierten Methoden daneben liegen, ist die Erwartung, dass eine Schätzung aus dem Bauch heraus zuverlässig sein könnte, unrealistisch.

Die Konsequenzen sind vorhersehbar. Entweder endet das Projekt als Minimal-Version, die den eigentlichen Bedarf nicht deckt, oder es folgen Monate der Nachfinanzierung und Diskussionen. Das Vertrauen aller Beteiligten leidet, das Team steht unter Dauerdruck und das Projekt wird zum Negativbeispiel, das bei der nächsten Investitionsentscheidung als Argument dient.

Story-Points im Projektgeschäft

In der agilen Community hat die Ablehnung stundenbasierter Schätzungen zugunsten von Story-Points fast dogmatische Züge angenommen. Für langlaufende Produktentwicklungsteams, die ihre Velocity kennen und pflegen, ist relatives Schätzen ein sinnvoller Ansatz.

Im Projektgeschäft, also bei individueller Softwareentwicklung für externe Kunden, bricht dieses Modell an einer konkreten Stelle zusammen: Am Ende des Schätzprozesses muss ein Angebot stehen. Und ein Angebot wird in Euro formuliert, nicht in Story-Points.

Der Umweg über abstrakte Größen erzeugt eine Scheinpräzision: Die Story-Points müssen am Ende in einen Geldwert umgerechnet werden. Und diese Umrechnung basiert auf Erfahrungswerten, Teamkosten und letztlich auf Zeiteinheiten. Wenn am Ende ohnehin eine Arbeitseinheit stehen muss, stellt sich die Frage, was der Zwischenschritt über abstrakte Größen bringt.

Für die interne Sprint-Planung und Priorisierung haben Story-Points ihren Platz. Für die externe Angebotserstellung im Projektgeschäft sind sie ein unnötiger Umweg. Die Stunde als Basis ist etabliert, nachvollziehbar und für den Kunden transparent.

Was KI beim Schätzen leisten kann und was nicht

KI-Werkzeuge liefern bei der Konzeption neuer Projekte brauchbare Ergebnisse: Lösungsarchitektur, technische Recherche, erste Entwürfe. Dabei spucken sie auch Aufwandsschätzungen aus. Die Beobachtung nach mehreren Monaten Nutzung: KI schätzt fast immer deutlich höher als die Einschätzung aus 25 Jahren Projekterfahrung.

Die Erklärung liegt vermutlich in den Trainingsdaten: Wenn die Datenbasis überwiegend aus Projekten besteht, die über Budget gelaufen sind (was für einen Großteil aller Softwareprojekte zutrifft), tendiert die KI zu konservativen Schätzungen.

Das ist nicht grundsätzlich falsch. Möglicherweise bildet die KI ab, was Projekte tatsächlich kosten, inklusive aller versteckten Aufwände, die bei menschlichen Schätzungen gerne kleingerechnet werden. Das Problem entsteht, wenn Entscheider diese Zahlen unreflektiert übernehmen: Sinnvolle Projekte werden nicht gestartet, weil sie „zu teuer“ erscheinen, oder Budgets werden aufgebläht.

Aufwandsschätzungen gehören zu den Aufgaben, die Erfahrung, Kontext und Verantwortungsbewusstsein erfordern. KI-Schätzungen dienen als zweite Meinung und als Benchmark, nicht als Entscheidungsgrundlage.

Der Schätzsheet-Ansatz

Aus den beschriebenen Erfahrungen hat sich ein strukturierter Schätzprozess entwickelt, den wir intern „Schätzsheet“ nennen. Das Grundprinzip ist einfach, die Wirkung liegt in der Konsequenz der Anwendung:

Aufgaben herunterbrechen: Das Projekt wird in kleine, schätzbare Einheiten gegliedert: User Stories („Login“, „Passwort vergessen“) und technische Aufgaben („Datenimport“, „Schnittstelle ABC“). Kleine Einheiten sind zuverlässiger zu schätzen als große Blöcke, weil sie weniger versteckte Komplexität enthalten.

Vergessene Aufwände einplanen: Projektmanagement, Qualitätssicherung, Framework-Updates, Test-Support, Installation und Deployment. Diese Posten werden in der Schätzung häufig übersehen, obwohl sie in der Praxis 20 bis 30 Prozent des Gesamtaufwands ausmachen

können. Das Schätzsheet enthält diese Posten als Standardpositionen, die bewusst bewertet und nicht versehentlich vergessen werden.

Risikofaktoren berücksichtigen: Externe Schnittstellen? Unerfahrenes Team? Hohes erwartetes Nutzeraufkommen? Unscharfe Anforderungen? Diese Faktoren fließen als Aufschläge in die Kalkulation ein. Das macht die Schätzung transparenter und die Diskussion über Risiken explizit.

Ergebnis nachvollziehbar machen: Das Endergebnis ist keine einzelne Zahl, sondern eine aufgeschlüsselte Kalkulation. Der Kunde sieht, welches Feature welchen Aufwand verursacht, wo die Risikozuschläge liegen und wo Einsparpotenzial besteht. Diese Transparenz schafft Vertrauen und ermöglicht informierte Entscheidungen1.

Schätzsheet Download

Fazit

Jede Softwareschätzung ist mit Unsicherheit behaftet. Das ist kein Defekt des Verfahrens, sondern die Natur der Sache. Die Aufgabe ist nicht, diese Unsicherheit zu eliminieren, sondern sie zu beherrschen.

Drei Prinzipien haben sich über 15 Jahre bewährt. Erstens mehr Zeit in die initiale Analyse investieren, weil die Stunden am Anfang ein Vielfaches am Ende sparen. Zweitens ehrliche Spannen kommunizieren, statt Punktlandungen zu versprechen, weil eine Schätzung eine fundierte Annahme ist und keine Garantie. Drittens ein Umfeld schaffen, in dem Anpassungen Professionalität bedeuten und nicht Scheitern, weil sich Projekte verändern und die Schätzung das abbilden muss.