# Aufwandsschätzung Software: Methoden und Rechenbeispiel

> Für eine belastbare Aufwandsschätzung zerlegst du das Projekt in Arbeitspakete, schätzt jedes mit optimistischem, wahrscheinlichem und pessimistischem Wert und rechnest nach PERT: (O + 4M + P) / 6. Die Summe ergänzt du um eine Streuung und kommunizierst das Ergebnis als Spanne mit Wahrscheinlichkeit, etwa „62 bis 72 Personentage, mit 80 Prozent unter 69“.

- URL: https://go-projects.de/schaetzung-und-budget/aufwandsschaetzung-software/
- Sprache: de
- Aktualisiert: 2026-10-19
- Herausgeber: Go Projects (OnlineBuilders LLC, https://onlinebuilders.biz)

Eine Schätzung von „vier Wochen“ enthält fast immer einen unausgesprochenen Zusatz: wenn nichts dazwischenkommt. Genau das passiert aber in Softwareprojekten ständig. Daniel Kahneman und Amos Tversky haben das Phänomen 1979 als Planungsfehlschluss beschrieben. Menschen schätzen den eigenen Aufwand zu optimistisch, selbst wenn sie wissen, dass frühere Projekte länger gedauert haben.

Douglas Hofstadter hat daraus ein Gesetz gemacht, das jeder Entwickler kennt: Es dauert immer länger als erwartet, auch wenn man Hofstadters Gesetz berücksichtigt.

Die Lösung ist nicht, Zahlen einfach zu verdoppeln. Die Lösung ist, Unsicherheit ehrlich in die Schätzung einzubauen.

## Warum frühe Schätzungen so weit danebenliegen

Steve McConnell hat das Problem mit dem Kegel der Unsicherheit beschrieben. Je weniger über das Projekt bekannt ist, desto breiter ist die Spanne, in der das tatsächliche Ergebnis landen kann. Und zwar selbst bei erfahrenen Schätzern.

**Wie breit Schätzungen je Projektphase streuen (Verhältnis höchster zu niedrigster Wert)**

| Posten | Wert |
|---|---|
| Erste Idee | 0,25× bis 4× |
| Produktdefinition abgestimmt | 0,5× bis 2× |
| Anforderungen vollständig | 0,67× bis 1,5× |
| Oberflächendesign fertig | 0,8× bis 1,25× |

Quelle: Steve McConnell, Software Development's Cone of Uncertainty, Construx 2010

Zwei Dinge sind daran wichtig. Erstens ist das die beste erreichbare Genauigkeit, nicht die übliche. Schlechter schätzen geht immer. Zweitens wird der Kegel nicht von selbst schmaler. McConnell betont, dass die Projektleitung aktiv offene Fragen klären muss, damit die Unsicherheit sinkt. Laut seinem Whitepaper passiert die stärkste Verengung in den ersten 20 bis 30 Prozent der Projektlaufzeit.

Kritiker wie Laurent Bossavit weisen darauf hin, dass die konkreten Faktoren ursprünglich auf Expertenurteilen beruhen und nicht aus gemessenen Projektdaten stammen. Als Denkmodell taugt der Kegel trotzdem: Wer eine Festpreiszusage in der Ideenphase verlangt, verlangt eine Zahl, die um den Faktor 16 streuen kann.

## Die wichtigsten Methoden im Vergleich

**Schätzmethoden für Softwareprojekte**

| | Aufwand | Braucht Daten | Gut für |
|---|---|---|---|
| Expertenschätzung | gering | nein | erste Größenordnung |
| Analogieschätzung | gering | ja | Budgetrahmen |
| Bottom-up mit Dreipunkt | mittel | nein | Angebot, Freigabe |
| Wideband Delphi | mittel | nein | neue, unklare Themen |
| Function Points | hoch | ja | große Vorhaben, Verträge |
| Story Points mit Velocity | gering | ja | laufende agile Teams |

Die Analogieschätzung ist unterschätzt. Wer ein vergleichbares Projekt abgeschlossen hat und dessen echte Stunden kennt, hat eine bessere Basis als jede Formel. Das setzt voraus, dass man nach Projektende die tatsächlichen Aufwände festhält. Die wenigsten tun das. Schade. Eine einfache Tabelle mit Arbeitspaket, Schätzung und Ist-Wert, gepflegt über drei oder vier Projekte, ist mehr wert als jedes Schätzseminar, weil sie zeigt, wo das eigene Team regelmäßig danebenliegt.

Function Points zählen die fachliche Funktionalität (Eingaben, Ausgaben, Abfragen, Datenbestände, Schnittstellen) und sind als Verfahren der IFPUG genormt. Sie sind aufwendig und lohnen sich vor allem bei großen Vorhaben oder wenn Verträge auf messbarem Umfang beruhen sollen.

Für agile Teams im laufenden Betrieb gibt es einen eigenen Beitrag: [Story Points schätzen](https://go-projects.de/schaetzung-und-budget/story-points-schaetzen/).

## Rechenbeispiel: Dreipunktschätzung nach PERT

Die Dreipunktschätzung ist für die meisten Projekte der beste Kompromiss aus Aufwand und Ehrlichkeit. Für jedes Arbeitspaket gibt das Team drei Werte an: optimistisch (O), wahrscheinlich (M) und pessimistisch (P). Daraus ergibt sich der Erwartungswert E = (O + 4M + P) / 6 und eine Standardabweichung σ = (P − O) / 6.

Beispiel: ein Bestellportal, geschätzt in Personentagen.

| Arbeitspaket | O | M | P | E | σ |
|---|---|---|---|---|---|
| Login und Rollen | 4 | 6 | 12 | 6,7 | 1,3 |
| Kundenverwaltung | 8 | 12 | 20 | 12,7 | 2,0 |
| ERP-Schnittstelle | 10 | 20 | 50 | 23,3 | 6,7 |
| Berichte und Export | 5 | 8 | 15 | 8,7 | 1,7 |
| Tests und Deployment | 8 | 10 | 18 | 11,0 | 1,7 |

**Vom Paket zur Gesamtspanne**

- Summe der wahrscheinlichen Werte (M): 56 PT
- Summe der Erwartungswerte (E): 62,3 PT
- Gesamt-σ = √(Summe σ²): 7,5 PT
- 80 % Wahrscheinlichkeit unter (E + 0,84 σ): 68,6 PT
- **90 % Wahrscheinlichkeit unter (E + 1,28 σ): 71,9 PT**

Die Wurzelsumme der Varianzen setzt unabhängige Pakete voraus. In echten Projekten hängen Risiken oft zusammen, die tatsächliche Streuung ist dann größer.

Zwei Beobachtungen machen diese Rechnung wertvoll. Die Summe der wahrscheinlichsten Werte liegt bei 56 Tagen, der Erwartungswert bei 62. Wer nur die „realistische“ Zahl addiert, liegt systematisch zu niedrig, weil Verzögerungen größer ausfallen als Beschleunigungen. Zweitens steckt fast die gesamte Unsicherheit in einem Paket: der ERP-Schnittstelle. Statt den Gesamtpuffer aufzublähen, lohnt sich hier ein kurzer technischer Prototyp, bevor das Budget freigegeben wird.

## Wie du eine Schätzung kommunizierst

Die beste Rechnung nützt nichts, wenn am Ende eine einzelne Zahl im Protokoll steht. Drei Regeln helfen:

1. Immer eine Spanne nennen, nie einen Punktwert. „62 bis 72 Personentage“ statt „65“.
2. Die Wahrscheinlichkeit dazusagen. „Mit 80 Prozent Wahrscheinlichkeit unter 69.“
3. Die Annahmen aufschreiben. „Gilt unter der Annahme, dass die ERP-API dokumentiert ist und Testzugänge in Woche 1 bereitstehen.“

Punkt drei ist dein Schutz. Er wird oft vergessen. Wenn sich eine Annahme als falsch herausstellt, ist die Schätzung nicht gescheitert. Sie muss neu gemacht werden, und das ist ein normaler Vorgang.

Aus Personentagen wird Geld, indem du sie mit dem Tagessatz multiplizierst. Was dabei realistische Sätze sind und welche Kosten nach dem Go-live dazukommen, steht im Beitrag [Software entwickeln lassen: Kosten](https://go-projects.de/schaetzung-und-budget/software-entwickeln-lassen-kosten/).

## Fünf Fehler, die Schätzungen ruinieren

- Der Chef nennt vorab eine Zahl. Danach schätzt niemand mehr unabhängig, alle verankern sich an der Vorgabe.
- Nur die Programmierung wird geschätzt. Tests, Code-Reviews, Abstimmungen, Deployment und Dokumentation fehlen.
- Die Schätzung wird nie aktualisiert. Nach jedem Meilenstein sollte die Restschätzung neu gemacht werden.
- Zusätzliches Personal soll den Rückstand aufholen. Fred Brooks hat schon 1975 festgehalten, dass mehr Leute ein verspätetes Softwareprojekt noch später machen, weil Einarbeitung und Abstimmung Zeit kosten.
- Niemand vergleicht Schätzung und Ergebnis. Ohne diesen Abgleich lernt das Team nichts für das nächste Projekt.

Gegen den ersten Fehler hilft eine Technik aus Wideband Delphi: Alle schätzen verdeckt und gleichzeitig, erst dann wird verglichen und diskutiert.

## Schätzung und Vertrag

Eine Spanne lässt sich in jedem Vertragsmodell abbilden. Bei Abrechnung nach Aufwand wird sie zur Budgetobergrenze mit Informationspflicht. Beim Festpreis preist der Anbieter den oberen Rand plus Risikoaufschlag ein. Welches Modell wann passt, steht unter [Festpreis oder Time and Material](https://go-projects.de/schaetzung-und-budget/festpreis-oder-aufwand/). Und wer vor der Schätzung erst den Umfang ordnen muss, beginnt mit der [Planung des Softwareprojekts](https://go-projects.de/projektplanung/softwareprojekt-planen/).

Wenn du für eine riskante Schnittstelle oder neue Technik einen zweiten Blick von außen brauchst, kannst du sie in einer kostenlosen Erstberatung mit dem Team von [OnlineBuilders](https://onlinebuilders.biz/contact) durchgehen.

Nächster Schritt: Nimm die drei größten Arbeitspakete deines Projekts und lass zwei Leute aus dem Team unabhängig je drei Werte schätzen. Wo die pessimistischen Werte am weitesten auseinanderliegen, steckt dein größtes Risiko.

## Häufige Fragen

### Welche Schätzmethode ist die genaueste?

Keine einzelne. Am zuverlässigsten ist die Kombination aus zwei unabhängigen Methoden, etwa Bottom-up mit Dreipunktschätzung und eine Analogie zu einem abgeschlossenen Projekt. Liegen beide weit auseinander, fehlt eine Information.

### Wer sollte schätzen?

Die Leute, die die Arbeit machen. Schätzungen von Vorgesetzten oder Vertrieb sind erfahrungsgemäß zu optimistisch, weil sie oft ein Wunschergebnis vorwegnehmen.

### Wie viel Zeit sollte eine Schätzung kosten?

Für ein Angebot oder eine Budgetfreigabe sind ein bis drei Prozent des erwarteten Projektaufwands ein vernünftiger Rahmen. Mehr Zeit lohnt sich nur, wenn sie offene Fragen tatsächlich klärt, etwa durch einen technischen Prototyp für eine riskante Schnittstelle.

### Was ist der Unterschied zwischen Schätzung und Zusage?

Eine Schätzung ist eine Wahrscheinlichkeitsaussage. Eine Zusage ist eine Geschäftsentscheidung, wie viel Risiko man eingeht. Wer beides vermischt, macht aus jeder Schätzung einen Termin, der fast sicher nicht hält.

Foto: Sauvagette, CC BY-SA 4.0 (https://commons.wikimedia.org/wiki/File:Multiple_hourglasses.jpg)