Aufwandsschätzung in der Softwareentwicklung: Methoden, Unsicherheit und warum Schätzungen scheitern

Jedes Angebot für ein Softwareprojekt enthält eine Aufwandsschätzung, auch wenn sie nur als Summe erscheint. Die Zahl allein verrät allerdings nicht, wie breit die Unsicherheit dahinter ist. Je weniger zum Zeitpunkt des Angebots entschieden ist, desto breiter müsste sie sein. Dieser Artikel zeigt, was eine Aufwandsschätzung in der Softwareentwicklung leisten kann, welche Schätzmethoden es gibt, warum Schätzungen scheitern und wie Sie eine fremde Schätzung im Angebot prüfen.

Was eine Aufwandsschätzung in der Softwareentwicklung ist — und was sie nicht ist

Eine Aufwandsschätzung ist eine Wahrscheinlichkeitsaussage. Sie nennt eine Bandbreite, in der der tatsächliche Aufwand mit einiger Sicherheit liegt, und die Annahmen, unter denen das gilt. Eine Punktzahl ist sie nicht. Im Projektalltag tragen allerdings drei verschiedene Größen denselben Namen:

• Schätzung: Wie viel Aufwand wird das Vorhaben voraussichtlich verursachen? Sie beschreibt, was zu erwarten ist.
• Ziel: Wie viel darf es kosten, bis wann muss es fertig sein? Ein Ziel beschreibt einen Wunsch, keine Machbarkeit.
• Zusage: Was verspricht ein Anbieter verbindlich? Eine Zusage entsteht erst, wenn Schätzung und Ziel abgeglichen sind.

Selbst die Fachliteratur trennt hier nicht sauber. Eine Auswertung von Lehrbüchern und Forschungsarbeiten fand, dass der Begriff „Aufwandsschätzung” dort häufig ohne Klärung seiner Bedeutung verwendet wird.

Als Einheit dienen Stunden oder Personentage. Euro entstehen erst durch den Satz, und ein niedriger Satz sagt wenig, solange die Stundenzahl unsicher ist — was der Stundensatz daraus macht.

Der Unsicherheitskegel (Cone of Uncertainty): wovon die Genauigkeit einer Schätzung abhängt

Der Unsicherheitskegel beschreibt, wie stark eine Aufwandsschätzung in der Softwareentwicklung je nach Projektphase streuen kann. Am breitesten ist sie vor der Anforderungsklärung. Dann ist noch offen, welche Abläufe das System abbildet, welche Schnittstellen es braucht und wie viele Sonderfälle es gibt. Mit jeder getroffenen Entscheidung wird sie schmaler: nach dem abgestimmten Anforderungsumfang, nach dem Entwurf der Oberfläche, nach der Detailarchitektur. Die Phasen sind dabei nur Stellvertreter. Die Bandbreite verengt sich, weil offene Fragen entschieden sind, nicht weil Zeit vergangen ist.

In vielen Darstellungen stehen an den Phasen konkrete Faktoren. Wir nennen hier bewusst keine, denn für diese Werte liegt uns keine belastbare Primärquelle vor. Zwei Einordnungen dagegen lassen sich belegen.

Herkunft der Grafik. Laurent Bossavit ist in „The Leprechauns of Software Engineering” der Herkunft des Kegels nachgegangen. In Barry Boehms Buch von 1981 fand er eine Fußnote, nach der die Bandbreiten subjektiv bestimmt wurden. Außerdem wendet er ein, dass der Kegel symmetrisch ist. Eine frühe Schätzung wäre demnach ebenso oft zu hoch wie zu niedrig — nach seiner Einschätzung passt das nicht zur Erfahrung, dass Softwareprojekte weit öfter zu spät als zu früh fertig werden.

Empirische Prüfung. Eveleens und Verhoef haben den Kegel 2009 an Prognosedaten realer Organisationen untersucht. Die Kegelform entsteht demnach, wenn Schätzer den tatsächlichen Aufwand möglichst genau treffen wollen. Sie entsteht aber auch, wenn die Schätzgenauigkeit gleich bleibt oder sogar sinkt. Der Grund: Gegen Projektende ist der verbrauchte Aufwand bekannt, und nur noch der Rest wird geschätzt. Waren Prognosen dagegen politisch gefärbt, etwa um eine Freigabe zu erreichen, fanden die Autoren andere Formen bis hin zu gar keinem Kegel.

Für Sie als Auftraggeber folgt daraus zweierlei. Eine frühe Aufwandsschätzung in der Softwareentwicklung ist nur so belastbar wie die Entscheidungen dahinter. Und dass sich eine Schätzung im Projektverlauf dem Ergebnis nähert, beweist noch nicht, dass gut geschätzt wurde.

Methoden der Aufwandsschätzung in der Softwareentwicklung im Vergleich

Die gängigen Verfahren unterscheiden sich weniger im Rechenweg als in ihrer Datengrundlage und im Zeitpunkt, ab dem sie tragen. Die Tabelle beschreibt deshalb Voraussetzungen, keine Genauigkeit.

Methode	Worauf sie beruht	Wann sie trägt	Wo sie an Grenzen stößt
Expertenschätzung (Wideband Delphi)	Urteil erfahrener Fachleute, bei Wideband Delphi in mehreren Runden	früh, wenn Erfahrung mit ähnlichen Systemen vorhanden ist	schwer nachvollziehbar, wenn Annahmen nicht dokumentiert sind
Analogieschätzung	Ist-Aufwand vergleichbarer, abgeschlossener Projekte	wenn eigene Projekthistorie vorliegt	nur so gut wie die Vergleichbarkeit der Projekte
Bottom-up über Projektstrukturplan	Summe der Einzelschätzungen je Arbeitspaket	nach der Anforderungsklärung	nur so vollständig wie der Strukturplan
Drei-Punkt-Schätzung / PERT	optimistischer, wahrscheinlichster und pessimistischer Wert	als Ergänzung jeder anderen Methode	die drei Werte sind selbst Schätzungen
Function Points (IFPUG)	Funktionsumfang aus Anwendersicht, gezählt nach Regelwerk	wenn Anforderungen fachlich beschrieben sind	Umrechnung in Stunden braucht eigene Produktivitätsdaten
COCOMO II	parametrisches Modell aus Größe und Einflussfaktoren	wenn die Größe schätzbar ist	ohne Kalibrierung auf eigene Projektdaten wenig aussagekräftig; zu den Einflussfaktoren: Aufwandsmodelle wie COCOMO II
Story Points / Planning Poker	relative Größe im Vergleich zu anderen Aufgaben desselben Teams	Sprint-Planung eines eingespielten Teams	teamspezifisch, nicht in Stunden übertragbar

Welche Methode genauer schätzt, hat Magne Jørgensen in einer Übersichtsarbeit zu Expertenschätzung und formalen Modellen untersucht. In zehn von 16 Vergleichsstudien lag die Expertenschätzung im Mittel genauer als das Modell. Als Indizien dafür nennt er zwei Punkte: Die Modelle waren nicht auf die jeweilige Organisation kalibriert, und die Fachleute verfügten über Kontextwissen, das in keinem Modell steckte. Vier Studien kombinierten außerdem beide Ansätze. Die Kombination erreichte im Mittel ungefähr die Genauigkeit der besten Einzelmethode. Eine Rangliste folgt daraus allerdings nicht, denn das Ergebnis hing an Kalibrierung und Kontext.

Drei-Punkt-Schätzung (PERT): Bandbreite statt Punktwert

Die Drei-Punkt-Schätzung fragt je Arbeitspaket drei Werte ab: optimistisch (O), wahrscheinlichst (M) und pessimistisch (P). Die PERT-Schätzung verdichtet sie zu Erwartungswert und Streuung:

E = (O + 4M + P) / 6 und σ = (P − O) / 6

Ein Beispiel in Stunden, rein zur Illustration: Eine Schnittstelle mit O = 40 h, M = 80 h und P = 200 h ergibt E = 93 h und σ ≈ 27 h. Der Erwartungswert liegt damit über dem wahrscheinlichsten Wert, weil der pessimistische Wert weiter von M entfernt ist als der optimistische. Wer nur M ins Angebot schreibt, unterschlägt genau diese Differenz.

Story Points schätzen — warum sie in kein Angebot gehören

Story Points messen keine Zeit. Sie beschreiben die Größe einer Aufgabe im Verhältnis zu anderen Aufgaben desselben Teams, geschätzt etwa beim Planning Poker. Gedacht sind sie für die Sprint-Planung innerhalb dieses Teams. In Stunden übersetzen lassen sich Story Points erst über die Velocity eines eingespielten Teams, und die setzt eine stabile Besetzung voraus. Jede wechselnde Besetzung wirft ein eingespieltes Team zurück und verschiebt damit auch diese Rechengröße. Für den Vergleich zweier Angebote sind Story Points deshalb unbrauchbar: Die Punkte des einen Teams sagen nichts über die des anderen.

Warum Schätzungen in Softwareprojekten scheitern

Dass Budgets systematisch reißen, ist gut belegt. Für Sie als Auftraggeber zählt die Frage davor: warum schon die Schätzung danebenliegt. Drei Ursachen lassen sich unterscheiden.

1. Der Anker. Wer vor der Schätzung erfährt, welches Budget sich der Auftraggeber vorstellt, schätzt womöglich nicht mehr unabhängig. Jørgensen und Sjøberg beobachteten das 2001 in einer Entwicklungsorganisation: Frühe Kostenrahmen lagen dort nahe an dem, was der Kunde vermutlich akzeptieren würde. Die Planung stützte sich teils auf diesen „Price-to-Win” statt auf die Schätzung. In einem Experiment derselben Arbeit mit Studierenden prägte ein früher Richtwert die späteren Detailschätzungen stark. Das galt auch, als die Teilnehmenden ausdrücklich erfuhren, dass der Wert weder auf Daten noch auf Expertenwissen beruhte. Von allen Ursachen ist diese die einzige, die Sie als Auftraggeber selbst steuern.

2. Nicht aufgeschlüsselte Tätigkeiten. Eine Bottom-up-Schätzung ist nur so vollständig wie ihr Projektstrukturplan. Wer nur das Programmieren zerlegt, schätzt Test, Integration, Migration und Abstimmung pauschal oder gar nicht. Was diese Tätigkeiten kosten, steht in unserer Übersicht dazu, was Integration und Migration treiben. Hinzu kommt die Nacharbeit, die in keinem Angebot steht.

3. Planungsoptimismus. In seiner Übersichtsarbeit beschreibt Jørgensen überoptimistische Schätzungen als Auslöser ernster Liefer- und Steuerungsprobleme in Softwareprojekten. Zwei Umstände verstärken das nach seiner Darstellung. In Bieterrunden werden eher die Anbieter ausgewählt, die zu optimistisch schätzen. Außerdem überschätzen Schätzende die Genauigkeit ihrer eigenen Bandbreiten. Deshalb fragt die Checkliste weiter unten auch nach den Vergleichsprojekten hinter einer Zahl.

Festpreis ohne Discovery-Phase: warum sich das Risiko nur verschiebt

Ein Festpreis, zugesagt nach dem ersten Gespräch, entsteht an der breitesten Stelle des Kegels. Er muss deshalb den oberen Rand der Bandbreite abdecken, entweder als Aufschlag im Preis oder über Nachträge, sobald sich der Umfang konkretisiert. Das Risiko verschwindet also nicht. Es wechselt nur die Stelle, an der Sie es bezahlen.

Eine vorgeschaltete, separat beauftragte Klärungsphase — die Discovery-Phase — setzt früher an. Sie trifft die offenen Entscheidungen, bevor jemand einen Preis zusagt, und verengt so die Bandbreite. Ihre Eingangsgröße ist das fachliche Lastenheft. Belastbare Zahlen zu Dauer, Budgetanteil oder Wirkung einer solchen Phase haben wir nicht gefunden. Die verfügbaren Angaben stammen von Anbietern, die solche Phasen verkaufen, deshalb steht hier keine.

Die Gegenposition gehört dazu: Eine bezahlte Klärungsphase ist auch ein Vertriebsinstrument und bindet Sie an einen Anbieter. Sie trägt nur, wenn ihr Ergebnis — Anforderungen, fachlicher Schnitt, Schätzung mit Annahmen — an jeden anderen Anbieter weitergegeben werden kann. Wie sich die Vertragsmodelle unterscheiden, erklärt unser Beitrag Festpreis oder Time & Material.

Wie Sie eine Aufwandsschätzung für Softwareentwicklung im Angebot prüfen

Die folgenden Fragen führen einen einzigen Punkt unserer Angebots-Checkliste aus: „Wie wurde die Stundenzahl geschätzt?” Die übrigen Fragen an ein Angebot stehen im Stundensatz-Artikel.

1. Steht eine Bandbreite da oder ein Punktwert? Ein Punktwert verschweigt die Unsicherheit, er beseitigt sie nicht.
2. Welche Annahmen und Ausschlüsse sind genannt? Erst sie machen zwei Schätzungen vergleichbar.
3. Ist die Schätzung nach Arbeitspaketen aufgeschlüsselt — oder steht nur eine Summe da? Erst die Aufschlüsselung zeigt, ob Test, Integration, Migration und Abstimmung überhaupt enthalten sind.
4. Mit welcher Methode und gegen welche abgeschlossenen Projekte wurde geschätzt? Eine gute Antwort nennt vergleichbare Vorhaben mit ihrem tatsächlichen Aufwand — das bremst den Planungsoptimismus.
5. Wurde geschätzt, bevor oder nachdem Sie ein Budget genannt haben? Unabhängig ist die Schätzung nur, wenn der Anbieter zuerst schätzt und Sie Ihren Rahmen erst danach nennen.
6. Nach welchem Ereignis wird neu geschätzt? Etwa nach der Anforderungsklärung oder nach dem ersten Inkrement. Fehlt ein solcher Punkt, tut die Schätzung so, als stünde der Umfang schon fest.

Fazit

Eine Aufwandsschätzung in der Softwareentwicklung ist eine Bandbreite mit Annahmen. Wie breit sie sein muss, hängt davon ab, welche Entscheidungen schon getroffen sind. Wer eine Zusage verlangt, solange die wichtigsten offen sind, bezahlt die Unsicherheit mit — als Aufschlag oder als Nachtrag.

Ob Ihr Vorhaben noch am Anfang steht oder schon ein Angebot auf dem Tisch liegt: Ein Blick von außen hilft beim Einordnen. In einer kostenlosen Erstberatung klären wir gemeinsam, an welcher Stelle des Kegels Ihr Vorhaben heute steht und welche offene Entscheidung die Bandbreite am stärksten verengen würde.