Software-Projektschätzung: Ein praxisnaher Leitfaden für Projektmanager
Software-Projektschätzung: Ein praxisnaher Leitfaden für Projektmanager Kombinieren Sie für die frühe Planung relative Größenbestimmung (Planning Poker oder T-Shirt-Größen) mit einer kalibrierten Bottom-up-Aufgabenschätzung für den verbindlich festgelegten Umfang.
Software-Projektschätzung: Ein praxisnaher Leitfaden für Projektmanager
Kombinieren Sie für die frühe Planung relative Größenbestimmung (Planning Poker oder T-Shirt-Größen) mit einer kalibrierten Bottom-up-Aufgabenschätzung für den verbindlich festgelegten Umfang. Diese Kombination bietet in jeder Phase des Projektlebenszyklus den besten Kompromiss zwischen Geschwindigkeit und Belastbarkeit. Bevor Sie den Stakeholdern die Ergebnisse präsentieren, erstellen Sie diese fünf Ergebnisse: eine Aufwandsspanne für das 50. und 90. Perzentil, eine Gesamtsumme in Personenmonaten, Ihren angenommenen gemischten Stundensatz, einen Prozentsatz für Unvorhergesehenes und ein schriftliches Annahmenprotokoll.
Wann welche Methode eingesetzt wird:
- Jetzt relative Größenbestimmung: Konzeptphase, vor der Angebotserstellung, bei der Backlog-Pflege oder immer dann, wenn sich die Anforderungen noch ändern
- Bottom-up-Schätzung: festgelegter Umfang mit definierten Abnahmekriterien, Festpreisangebote oder regulatorische/staatliche Beschaffung
- Beides parallel: große Programme, Modernisierung von Legacy-Systemen oder jedes Projekt, bei dem die Fehlerbandbreite einer einzelnen Methode zu groß ist, um sie zu vertreten
Wichtige Erkenntnisse
Eine verlässliche Software-Projektschätzung erfordert die Kombination aus relativer Größenbestimmung für die frühe Planung und einer kalibrierten Bottom-up-Prüfung für den verbindlich festgelegten Umfang. Sie sollte stets als 50/90-Spanne mit expliziten Annahmen angegeben werden.
| Punkt | Details |
|---|---|
| Methode an die Lebenszyklusphase anpassen | Verwenden Sie früh relative Größenbestimmung (T-Shirt-Größen, Story Points); wechseln Sie für den verbindlich festgelegten Umfang und Festpreisangebote zu einem Bottom-up-WBS. |
| Immer eine Spanne angeben | Geben Sie für die Planung das 50. Perzentil und für die Finanzierung das 90. Perzentil an; Punktschätzungen erzeugen eine trügerische Genauigkeit. |
| Annahmenprotokoll ist unverzichtbar | Dokumentieren Sie Umfangsgrenzen, Teamzusammensetzung und Volatilität, bevor Sie irgendetwas schätzen; dieses Protokoll dient als Prüfpfad. |
| Vor der Festlegung kalibrieren | Geschwindigkeit, Kosten pro Punkt und historische Analogien sind die Eingaben, die eine belastbare Schätzung von einer Vermutung unterscheiden. |
| Ridiculous Engineering | Die Scoping-Projekte von Ridiculous Engineering erstellen ein gemeinsames Annahmenprotokoll und eine 50/90-Spanne, bevor Arbeiten zum Festpreis vereinbart werden. |
Inhaltsverzeichnis
- Warum genaue Softwareschätzungen für Geschäftsentscheidungen wichtig sind
- Wann sollten Sie im Projektlebenszyklus Schätzungen durchführen?
- Welche Methoden zur Software-Schätzung sind am häufigsten?
- Wie führen Sie einen schrittweisen Schätzprozess durch?
- Wie modellieren Sie Unsicherheit in einer Softwareschätzung?
- Auf welche Schätzfehler und Verzerrungen sollten Sie achten?
- Welche Tools und Kennzahlen helfen Ihnen, zuverlässiger zu schätzen?
- Wann sollten Sie intern schätzen und wann eine Beratung hinzuziehen?
- Praxisbeispiel: End-to-End-Schätzung eines Releases mit drei Epics
- Ridiculous Engineering hilft Ihnen, belastbare Schätzungen zu erstellen
- Quellen
- FAQ
Warum genaue Softwareschätzungen für Geschäftsentscheidungen wichtig sind
Eine Schätzung ist keine Vermutung, die man in einer Tabelle schick herausputzt. Sie ist die wichtigste Grundlage für drei Entscheidungen, die darüber bestimmen, ob ein Projekt erfolgreich ist: Priorisierung des Umfangs, Budgetfreigabe und Ressourcenplanung. Liegt man in die eine oder andere Richtung falsch, sind die Folgen konkret: Unterfinanzierte Projekte werden während der Umsetzung im Umfang reduziert, überfinanzierte Projekte verschwenden Kapital, das anderweitig hätte eingesetzt werden können, und nicht abgestimmte Stakeholder verlieren lange vor der Auslieferung des Codes das Vertrauen in das Team.
Die SEI an der Carnegie Mellon University betrachtet die Schätzung von Softwarekosten als ein Instrument zur Beurteilung der Finanzierbarkeit und zur Priorisierung des Umfangs, wobei Größenmetriken und Kostentreiber zusammenwirken, um Abweichungen zu erklären. Diese Einordnung ist wichtig, weil sie Schätzungen als Disziplin zur Entscheidungsunterstützung positioniert und nicht als reine Terminplanung. Wenn Teams sie so verstehen, werden Schätzungen zu lebenden Artefakten, die Gespräche über Zielkonflikte unterstützen, statt zu festen Zusagen zu werden, die in Retrospektiven nachwirken.
Schlechte Schätzungen verstärken sich zudem gegenseitig. Für Product Owner bedeutet das verschobene Roadmap-Punkte. Für Projektmanager bedeutet es schwierige Gespräche, die mit einem besseren Prozess von Anfang an hätten vermieden werden können.
Wann sollten Sie im Projektlebenszyklus Schätzungen durchführen?
Schätzen ist kein einmaliges Ereignis. Die Genauigkeit, die Sie vernünftigerweise erreichen können, verändert sich, wenn Anforderungen ausgereifter werden, und auch die verwendete Methode sollte sich entsprechend ändern. Die Leitlinien des PMI zur agilen Projektschätzung beschreiben dies als Planung in rollierenden Wellen: Beginnen Sie mit groben Top-down-Schätzungen und arbeiten Sie diese schrittweise aus, sobald Sie mehr wissen.
-
Konzept / Machbarkeit (Fehlerbereich: ±50–100 %). Eingaben sind eine Problembeschreibung und eine grobe Funktionsliste. Verwenden Sie die analoge Schätzung oder T-Shirt-Größen. Das Ergebnis ist eine grobe Größenordnungsspanne, anhand derer entschieden wird, ob die Analysephase finanziert werden soll.
-
Angebot / Budget (Fehlerbereich: ±25–50 %). Eingaben sind ein übergeordnetes Umfangsdokument und alle verfügbaren Vergleichswerte. Verwenden Sie parametrische Modelle oder Affinitätsgruppierung. Das Ergebnis ist eine Budgetspanne mit expliziten Annahmen für den Finanzierungsantrag.
-
Release-Planung (Fehlerbereich: ±10–25 %). Eingaben sind ein priorisiertes Backlog mit Abnahmekriterien. Verwenden Sie Story Points mit Geschwindigkeitskalibrierung oder eine Bottom-up-WBS. Das Ergebnis ist eine Release-Prognose mit einer 50/90-Spanne.
-
Sprint- / Iterationsplanung (Fehlerbereich: ±5–15 %). Eingaben sind verfeinerte User Stories mit klaren Abnahmekriterien. Verwenden Sie Schätzungen auf Aufgabenebene in Stunden oder Story Points auf Basis einer bekannten Geschwindigkeit. Das Ergebnis ist eine Sprint-Zusage.
-
Auslöser für eine Neuschätzung. Schätzen Sie neu, wenn: Änderungen am Umfang 15–20 % der ursprünglichen Baseline überschreiten; ein technischer Spike eine grundlegend andere Architektur offenlegt; sich eine wichtige Abhängigkeit verändert; oder die tatsächliche Geschwindigkeit in mehr als zwei aufeinanderfolgenden Sprints um mehr als die Prognose abweicht.
Die oben genannten Fehlerbereiche sind praktische Spannen, keine Garantien. Sie spiegeln die Realität wider, dass die Unsicherheit abnimmt, wenn sich Anforderungen stabilisieren, und nicht einfach mit dem Fortschreiten des Kalenders.
Welche Software-Schätzmethoden sind am weitesten verbreitet?
Keine einzelne Technik funktioniert für jedes Projekt. Untersuchungen zu Schätzansätzen zeigen durchgängig, dass die Kombination mehrerer Methoden und der Vergleich der Ergebnisse bessere Erkenntnisse liefern, als sich allein auf eine Methode zu verlassen. Die folgende Tabelle ordnet jeder Methode ihre Eingaben, die erwartete Genauigkeit und den am besten geeigneten Kontext zu.
| Methode | Erforderliche Eingaben | Erwartete Genauigkeit | Am besten geeignete Projekttypen | Datenanforderungen |
|---|---|---|---|---|
| Top-down / analog | Historische Projektdaten, übergeordneter Umfang | ±25–50 % | Frühe Phase, Machbarkeit, vor dem Angebot | Aufzeichnungen früherer Projekte |
| Bottom-up (WBS-basiert) | Dekomponierte Aufgaben, Abnahmekriterien | ±5–15 % | Festgelegter Umfang, Festpreisangebote | Detaillierte Anforderungen |
| Parametrisch (COCOMO II) | Größe in KSLOC oder Funktionspunkten, Kostentreiber | ±10–25 % (kalibriert) | Große Programme, staatliche Beschaffung | Organisationsbezogene Kalibrierungsdaten |
| Expertenurteil / Wideband-Delphi | Fachexperten, strukturierter Konsensprozess | ±20–40 % | Neue Technologie, keine historischen Daten | Verfügbarkeit von Experten |
| Planning Poker / Story Points | Relative Referenzelemente, Teamkonsens | Nur relativ | Agile Teams, Backlog-Größenbestimmung | Historische Velocity-Daten für Prognosen |
| Funktionspunkte | Funktionale Anforderungen, Datenflüsse | ±10–25 % | Anforderungsintensive, vertraglich geregelte Arbeit | Funktionale Spezifikation |
| Codezeilen (LOC) | Bestehende Codebasis oder sprachspezifische Normen | ±25–50 % | Nur nach der Architekturüberprüfung | Code- oder Sprachbenchmarks |
Einige Hinweise zu den Methoden, die am häufigsten falsch eingesetzt werden:
Story Points messen Aufwand, Komplexität und Risiko, nicht Zeit. Die Schätzungsrichtlinien von Atlassian sind in diesem Punkt eindeutig: Die Umrechnung von Punkten in Stunden deutet meist auf eine unzureichende Zerlegung oder organisatorischen Druck hin, der die Schätzung verzerrt. Verwenden Sie Punkte für die relative Größenbestimmung und die auf der Velocity basierende Prognose; wandeln Sie sie erst dann in Termine um, wenn Kapazität und Abhängigkeiten berücksichtigt wurden.
LOC ist eine schwache Kennzahl in frühen Phasen, da sie erst beobachtet werden kann, nachdem Code geschrieben wurde. Die Übersicht von GeeksforGeeks zu Techniken der Größenschätzung weist darauf hin, dass LOC, Funktionspunkte, Use-Case-Punkte und die Anzahl von Entitäten bzw. Prozessen jeweils unterschiedliche Anwendungsbereiche haben. LOC eignet sich am besten für die Kalibrierung nach der Architektur, nicht für die Planung vor der Entwicklung.
COCOMO II ermittelt den Aufwand in Personenmonaten anhand der Größe (KSLOC oder Funktionspunkte), Skalierungsfaktoren und Aufwandsmultiplikatoren in den Modellen „Early Design“ und „Post-Architecture“. Das COCOMO-II-Handbuch stellt ausdrücklich fest: Das Modell muss anhand von Organisationsdaten kalibriert werden, um genaue Ergebnisse zu liefern. Ein nicht kalibrierter COCOMO-II-Durchlauf ist ein Ausgangspunkt, kein lieferbares Ergebnis.
Führen Sie bei Programmen mit hohen Risiken mindestens zwei sich ergänzende Methoden durch, beispielsweise ein parametrisches Modell zusammen mit einem Bottom-up-WBS, und betrachten Sie erhebliche Abweichungen als Anlass, Umfang, Annahmen oder Datenqualität zu untersuchen.
Wie führen Sie einen schrittweisen Schätzungsprozess durch?
Die Reihenfolge lautet: Dekomponieren → Größe bestimmen → Kalibrieren → Aggregieren → Unsicherheit quantifizieren → Validieren. Jeder Schritt erzeugt ein Artefakt. Überspringen Sie einen Schritt, verlieren Sie die Prüfspur, die eine Schätzung belastbar macht.
-
Definieren Sie Umfang und Annahmen. Erstellen Sie ein Annahmenprotokoll, bevor Sie irgendetwas dimensionieren. Dokumentieren Sie, was im Umfang enthalten ist, was ausdrücklich ausgeschlossen ist, welche Schnittstellen als vorhanden vorausgesetzt werden und von welcher Teamzusammensetzung Sie ausgehen. Dieses Protokoll ist das wichtigste einzelne Artefakt im Prozess.
-
Wählen Sie Ihre Größenmetrik. Story Points für relative Agile-Schätzungen; Funktionspunkte oder KSLOC für parametrische Modelle; Aufgabenstunden für eine Bottom-up-WBS. Stimmen Sie die Metrik auf die Methode und die Phase des Lebenszyklus ab.
-
Zerlegen Sie die Arbeit. Erstellen Sie eine Work-Breakdown-Struktur (WBS) oder eine Hierarchie aus Features, Epics und Stories. Für Agile-Teams ist dies das Backlog. Für Wasserfall- oder Festpreisprojekte ist es eine formale WBS. PMIs Leitfaden zur agilen Schätzung beschreibt dies als schrittweise Ausarbeitung: zunächst übergeordnete Epics, dann Stories und schließlich Aufgaben, sobald die Anforderungen ausgereifter sind.
-
Bestimmen Sie die Größe jedes Elements. Verwenden Sie Planning Poker für Story Points oder Schätzungen auf Aufgabenebene in Stunden für Bottom-up-Arbeiten. Wrikes Leitfaden zur agilen Schätzung empfiehlt, Schätzungen an Referenzelementen mit tatsächlich gelieferten Ergebnissen auszurichten. Dadurch verhindert das Team, Größen im luftleeren Raum zu bestimmen. Wenn das Team bei einem einzelnen Element länger als ein paar Minuten über Implementierungsdetails diskutiert, benötigt dieses Element einen Spike oder eine weitere Zerlegung – keine längere Diskussion.
-
Wenden Sie Kostentreiber und Kalibrierung an. Passen Sie rohe Größenschätzungen an Team-Erfahrung, technologische Neuartigkeit, Volatilität der Anforderungen und Integrationskomplexität an. Bei parametrischen Modellen sind dies formale Aufwandsmultiplikatoren. Bei Bottom-up-Schätzungen wenden Sie einen Kalibrierungsfaktor an, der aus Ihrer historischen Geschwindigkeit oder den Ist-Werten früherer Projekte abgeleitet wurde.
-
Aggregieren Sie und rechnen Sie in Kosten um. Summieren Sie den Aufwand über die WBS oder das Backlog. Rechnen Sie Personenstunden mithilfe Ihres gemischten Stundensatzes in Dollar um (vollständig belastet, einschließlich Leistungen und Gemeinkosten). Fügen Sie eine Reserve hinzu (typischerweise 15–25 % bei klar definiertem Umfang, 25–40 % bei Arbeiten mit hoher Unsicherheit).
-
Quantifizieren Sie die Unsicherheit und validieren Sie. Wenden Sie eine Dreipunktschätzung oder eine Monte-Carlo-Simulation an, um eine Bandbreite zu erzeugen. Prüfen Sie die Schätzung anhand historischer Vergleichswerte. Wenn sie deutlich von diesen Vergleichswerten abweicht, untersuchen Sie die Ursache, bevor Sie sie präsentieren.
Profi-Tipp: Führen Sie Schätzungsworkshops in einem einzigen Zeitfenster von 60–90 Minuten durch. Bestimmen Sie eine Moderation, deren Aufgabe es ist, das Team beim Größenbestimmen zu halten, statt über Architektur diskutieren zu lassen. Verwenden Sie zu Beginn drei Referenzelemente (ein kleines, ein mittleres und ein großes), um die Skala des Teams zu kalibrieren, bevor Sie das Backlog bearbeiten. Teams, die diesen Kalibrierungsschritt überspringen, erzeugen routinemäßig inkonsistente Größen zwischen den Sitzungen.
Wie modelliert man Unsicherheit in einer Softwareschätzung?
Geben Sie immer eine Bandbreite und ein Konfidenzperzentil an, nicht nur eine einzelne Zahl. Eine Punktschätzung vermittelt eine falsche Genauigkeit und führt dazu, dass das Team erklären muss, warum das Projekt „verspätet“ ist, sobald es außerhalb dieser Zahl landet.
Dreipunktschätzung (PERT) ist der praktische Ausgangspunkt. Erfassen Sie für jede Aufgabe oder jedes Arbeitselement drei Schätzungen: optimistisch (O), am wahrscheinlichsten (M) und pessimistisch (P). Der PERT-Erwartungswert wird als (O + 4M + P) / 6 berechnet. Die Standardabweichung beträgt (P - O) / 6. Aggregieren Sie diese Werte über die WBS, um eine Verteilung für die Gesamtschätzung zu erhalten.
Das 50/90-Perzentil-Framework ist die nützlichste Methode, diese Verteilung gegenüber Stakeholdern zu kommunizieren. Das 50. Perzentil (der Median) ist das Ergebnis, das Sie unter den aktuellen Annahmen ungefähr in der Hälfte der Fälle erwarten. Das 90. Perzentil ist das Budget oder der Zeitplan, bei dem Sie zuversichtlich sein können, dass Sie ihn nicht überschreiten. Verwenden Sie das 50. Perzentil für die interne Planung und das 90. Perzentil für Finanzierungsanträge und Festpreisverträge.
Monte-Carlo-Simulation geht noch weiter, indem sie Tausende von Iterationen über die vollständige Verteilung der Aufgabenschätzungen ausführt und eine Wahrscheinlichkeitskurve für die Gesamtsumme erzeugt. Eine einfache Monte-Carlo-Simulation können Sie in einer Tabellenkalkulation durchführen, indem Sie für jede Aufgabe Zufallsstichproben aus Dreiecksverteilungen (O, M, P) ziehen. Die Ausgabe zeigt Ihnen nicht nur den Median und das 90. Perzentil, sondern auch die Form des Risikos: Ein langer rechter Rand bedeutet, dass einige wenige Aufgaben den größten Teil des Terminrisikos tragen.
Statistik-Hinweis: Das Software-Kostenschätzungs-Framework des SEI verlangt ausdrücklich eine Analyse von Unsicherheit und Risiken, während die Anforderungen ausreifen, da Schätzungen in frühen Phasen eine nicht eliminierbare Unsicherheit enthalten, die durch noch so viel Planung nicht beseitigt werden kann.
Profi-Tipp: Verwenden Sie das 90. Perzentil für jede Zusage gegenüber Finanzabteilung, Führungskräften oder Kunden. Verwenden Sie das 50. Perzentil für die interne Sprint- und Release-Planung. Beide auf derselben Folie zu präsentieren und jeweils klar zu kennzeichnen, ist der schnellste Weg, Vertrauen der Stakeholder in Ihren Schätzungsprozess aufzubauen.
Auf welche Schätzfehler und Verzerrungen sollten Sie achten?
Das größte Anti-Pattern bei der Schätzung von Softwareprojekten besteht darin, eine Schätzung als Versprechen zu behandeln. Sobald eine Zahl zu einer Zusage wird, aktualisiert das Team sie nicht mehr, wenn es neue Erkenntnisse gewinnt, und die Lücke zwischen Schätzung und Realität wächst unbemerkt, bis sie zur Krise wird. Die Lösung ist strukturell: Präsentieren Sie Schätzungen immer als Bandbreiten mit ausdrücklichen Annahmen und legen Sie von Anfang an einen Rhythmus für Neuschätzungen fest.
Abgesehen von diesem strukturellen Versagen treten die folgenden Verzerrungen und Fehler besonders regelmäßig auf:
- Ankereffekt. Die erste Zahl, die in einer Schätzungssitzung genannt wird, wird zum Gravitationszentrum für alle nachfolgenden Schätzungen. Gegenmaßnahme: Verwenden Sie eine blinde Schätzung (alle schreiben ihre Zahl gleichzeitig auf, wie beim Planning Poker), bevor irgendeine Zahl laut ausgesprochen wird.
- Optimismusverzerrung. Teams unterschätzen die Dauer regelmäßig und überschätzen ihre eigene Produktivität. Gegenmaßnahme: Wenden Sie eine Referenzklassenprognose an, indem Sie das aktuelle Projekt mit den tatsächlichen Ergebnissen ähnlicher früherer Projekte vergleichen, nicht mit deren ursprünglichen Schätzungen.
- Story Points mit Stunden vermischen.Story Points sind ein relatives Größenmessinstrument. Wrikes Leitfaden zur agilen Aufwandsschätzung stellt klar, dass Schätzung Größenbestimmung und keine Terminplanung ist. Die Umrechnung von Points in Stunden führt bei allem, was über kurzfristige Kapazitätsprüfungen hinausgeht, zu einer falschen Präzision und untergräbt das Vertrauen des Teams in den Prozess.
- Schätzung durch Stellvertretung.Wenn eine Person im Namen des gesamten Teams schätzt oder die Schätzung eines Anbieters ohne unabhängige Prüfung akzeptiert wird, geht das verteilte Wissen verloren, das Schätzungen präzise macht. Die Personen, die die Arbeit ausführen, sollten den Arbeitsumfang einschätzen.
- Umfangsvergrößerung ohne neue Schätzung.Das Hinzufügen von Funktionen ohne Anpassung der Schätzung führt dazu, dass sich Projekte verdoppeln, während das Budget unverändert bleibt. Legen Sie einen Schwellenwert fest (typischerweise eine Umfangsänderung von 15–20 %), der eine formelle neue Schätzung auslöst.
Für Anbieterangebote und Festpreisverträge gilt eine kurze Checkliste zur Risikominderung: Verlangen Sie vom Anbieter, alle Annahmen schriftlich zu dokumentieren; bitten Sie um historische Kalibrierungsdaten oder Referenzprojekte; und beauftragen Sie für jedes Vorhaben oberhalb der Wesentlichkeitsschwelle Ihrer Organisation eine unabhängige Schätzung. Projekte zur Modernisierung von Legacy-Systemensind besonders anfällig für verborgene Komplexität, die erst nach Beginn der Arbeiten sichtbar wird, wodurch eine unabhängige Prüfung besonders wertvoll ist.
Welche Tools und Kennzahlen helfen Ihnen, zuverlässiger zu schätzen?
Für agile Teams sollten Sie zunächst zwei Kennzahlen standardisieren: Velocity (in einem Sprint gelieferte Story Points) und Kosten pro Point (Gesamtkosten des Sprints geteilt durch die gelieferten Points). Alles Weitere baut auf diesen beiden Zahlen auf. Bei großen Programmen, die parametrische Modelle verwenden, hat ein kalibriertes COCOMO-II-Modell mit mindestens drei bis fünf vergangenen Projekten im Kalibrierungsdatensatz Priorität.
Die oben genannten Benchmarkbereiche sind Referenzwerte, keine Zielvorgaben. Kalibrieren Sie sie anhand der Historie Ihres eigenen Teams, bevor Sie externe Benchmarks verwenden.
Vorlagen, deren Pflege sich lohnt:
- Annahmenprotokoll:ein lebendes Dokument, das bei jedem Ereignis einer neuen Schätzung aktualisiert wird
- Historisches Kalibrierungsblatt:tatsächlicher im Vergleich zum geschätzten Aufwand vergangener Projekte, geordnet nach Projekttyp und Teamzusammensetzung
- PERT-/Monte-Carlo-Tabelle:Drei-Punkt-Eingaben für jedes WBS-Element, aggregiert zu einer Gesamtverteilung
- Velocity-Tracker:rollierende Velocity von Sprint zu Sprint mit Notizen zu Auffälligkeiten (Teamänderungen, Feiertage, Umfangsspitzen)
COCOMO II lohnt sich, wenn Ihre Organisation mehrere große Programme durchführt (typischerweise mit mehr als 50.000 Codezeilen oder entsprechenden Function Points) und über historische Daten zu seiner Kalibrierung verfügt. Der Kalibrierungsaufwand ist beträchtlich: Rechnen Sie bei einer Erstkalibrierung mit zwei bis vier Wochen für Datenerfassung und Modellanpassung sowie mit laufenden Aktualisierungen, sobald neue Projekte abgeschlossen werden. Für kleinere Teams oder Arbeiten in einer früheren Phase sind ein gut gepflegter Velocity-Tracker und ein Kalibrierungsblatt hilfreicher als ein unkalibriertes parametrisches Modell. Das Agile-AdvantageFramework erklärt, warum relative Größenbestimmung und Velocity-basierte Prognosen bei iterativer Entwicklung tendenziell besser abschneiden als parametrische Schätzungen zu einem einzelnen Zeitpunkt.
Wann sollten Sie intern schätzen und wann eine Beratung hinzuziehen?
Bei einem Umfang von weniger als drei Sprints, einem stabilen Backlog und einem Team, das bereits ähnliche Arbeiten geliefert hat, ist eine interne Schätzung die richtige Wahl. Bei großen, teamübergreifenden, risikoreichen oder auf die Modernisierung von Legacy-Systemen ausgerichteten Arbeiten schafft eine externe Beratung Mehrwert, indem sie Kalibrierungsdaten, eine unabhängige Prüfung und Schätzmethoden einbringt, die das interne Team möglicherweise bisher nicht verwendet hat.
Bevor Sie einen Anbieter beauftragen oder ein Festpreisangebot anfordern, stellen Sie dieses Nachweispaket zusammen:
- Schriftlich formulierte Abnahmekriterien für jedes Feature im Umfang
- Schnittstellenspezifikationen für alle externen Systeme, mit denen die Software verbunden werden muss
- Mindestens zwei historische Vergleichsprojekte (vergangene Projekte ähnlicher Art und Größe) mit tatsächlichen Aufwandsdaten
- Ein Risikoregister, das technische, organisatorische und Abhängigkeitsrisiken abdeckt
- Ergebnisse aller technischen Spikes, die zur Klärung architektonischer Unbekannter durchgeführt wurden
- Eine Annahme zur Teamzusammensetzung (Rollen, Erfahrungsniveau, Vollzeit oder Teilzeit)
- Eine Bewertung der Anforderungsvolatilität (wie wahrscheinlich ist eine Umfangsänderung und in welchen Bereichen)
Entscheidungsablauf:
- Sie verfügen über eine historische Velocity und ein stabiles Backlog:Führen Sie intern eine auf der Velocity basierende Bottom-up-Schätzung durch.
- Sie haben viele Unbekannte oder neuartige Technologien: Führen Sie zunächst einen Spike durch und schätzen Sie anschließend mithilfe der Ergebnisse des Spikes neu.
- Sie bereiten einen Festpreisvertrag oder ein Angebot für eine Behörde vor: Verwenden Sie mindestens zwei ergänzende Methoden und ziehen Sie eine unabhängige Prüfung in Betracht.
- Sie modernisieren Altsysteme oder integrieren mehrere Plattformen: Das Risiko verborgener Komplexität ist hoch genug, dass sich die Unterstützung durch eine Beratung bei der Schätzung selbst häufig lohnt.
Profi-Tipp: Wenn Sie ein Festpreisprojekt verhandeln, teilen Sie Ihr Annahmenprotokoll mit dem Anbieter und bitten Sie ihn, jede Annahme schriftlich zu bestätigen oder zu korrigieren. Abweichungen zwischen Ihren Annahmen und denen des Anbieters sind der zuverlässigste Indikator für Nachträge. Sie vor der Unterzeichnung zu klären, ist günstiger, als sie während der Umsetzung zu klären.
Ridiculous Engineerings Softwareberatung und Unterstützung bei der Umsetzung beginnen typischerweise mit einer Scoping-Sitzung, in der ein gemeinsames Annahmenprotokoll und ein Bereich vom 50. bis zum 90. Perzentil erstellt werden, bevor Festpreisarbeiten vereinbart werden. Dieser Prozess schützt beide Seiten.
Praxisbeispiel: Eine Version mit drei Epics durchgängig schätzen
Dieses Beispiel liefert einen Aufwandsbereich vom 50. bis zum 90. Perzentil, eine Gesamtsumme in Personenmonaten und eine Umrechnung in Dollar für die Veröffentlichung einer mittelgroßen Webanwendung. Alle Zahlen dienen nur der Veranschaulichung; kalibrieren Sie sie anhand der Daten Ihres eigenen Teams.
Eingaben und Annahmen:
- Drei Epics: Benutzerauthentifizierung (Epic A, größtenteils wiederverwendete Muster), Reporting-Dashboard (Epic B, neue Entwicklung) und Integration einer Drittanbieter-API (Epic C, moderate Unbekannte)
- Team: zwei Senior-Entwickler, ein Entwickler auf mittlerem Niveau, ein QA-Engineer
- Velocity: 32 Story Points pro zweiwöchigem Sprint (gleitender Durchschnitt über drei Sprints)
- Gemischter Stundensatz: 150 $/Stunde (vollständig kalkuliert)
- Sprint-Kapazität: 80 Personenstunden pro Entwickler und Sprint
- Anforderungsvolatilität: moderat (auf pessimistische Schätzungen wird ein Multiplikator von 25 % angewendet)
Sizing- und PERT-Eingaben:
PERT-Erwartungswert pro Epic = (O + 4M + P) / 6. Gesamter PERT-Erwartungswert: 105 Story Points.
Umrechnung in Sprints und Personenmonate:
Bei 32 Punkten pro Sprint erfordern 105 Punkte ungefähr 3,3 Sprints (50. Perzentil). Die pessimistische Gesamtsumme von 168 Punkten erfordert ungefähr 5,3 Sprints (90. Perzentil, vor Anpassung an die Volatilität).
Bei einem vierköpfigen Team mit 80 Stunden pro Person und zweiwöchigem Sprint entspricht jeder Sprint 320 Personenstunden oder ungefähr 1,9 Personenmonaten (bei 168 Stunden pro Personenmonat). Gesamter Aufwandsbereich: ein Bereich von Personenmonaten vom 50. bis zum 90. Perzentil, auf den die Volatilität angewendet wurde.
Umrechnung in Dollar:
Bei einem gemischten Stundensatz reichen die geschätzten Kosten von einer mittleren Schätzung bis zu einer höheren Schätzung mit eingerechnetem Puffer.
Der Volatilitätsmultiplikator verdoppelt die Obergrenze nahezu – genau darum geht es. Wenn nur die wahrscheinlichste Schätzung präsentiert worden wäre, hätte dies ein Budget festgelegt, das beim Ergebnis des 90. Perzentils ohne Vorwarnung überschritten worden wäre.
Ridiculous Engineering hilft Ihnen, belastbare Schätzungen zu erstellen
Ridiculous Engineering arbeitet mit Produktteams und Führungskräften aus dem Business zusammen, um klar abgegrenzte Leistungen auf Grundlage expliziter Annahmen, kalibrierter Aufwandsbereiche und einer ehrlichen Risikobewertung zu erstellen – nicht auf Grundlage optimistischer Einzelwerte, die darauf ausgelegt sind, einen Auftrag zu gewinnen.
Unser Team bringt in die Schätzung dieselbe technische Disziplin ein wie in die Umsetzung: Wir dokumentieren Annahmen, wenden ergänzende Methoden an und präsentieren Bereiche vom 50. bis zum 90. Perzentil, damit Sie wissen, wozu Sie sich verpflichten. Wenn Sie eine Lieferantenauswahl, einen Finanzierungsantrag für den Vorstand oder einen Festpreisvertrag vorbereiten, beginnen Sie mit einem Scoping-Gespräch und bringen Sie das Annahmenprotokoll mit, das Sie mithilfe dieses Leitfadens erstellt haben.
Quellen
Dies sind die wertvollsten Referenzen, wenn Sie sich eingehender mit bestimmten Methoden befassen möchten:
- Agile-Schätzung: Planning Poker, Story Points und Größenbestimmung – Atlassian
- Softwarekostenschätzung erklärt – SEI (CMU)
- COCOMO-II-Handbuch
- Techniken zur Schätzung agiler Projekte – PMI
- Ultimativer Leitfaden zu Techniken für Agile-Schätzungen 2026 | Wrike
FAQ
Wie schätzen Sie ein Softwareentwicklungsprojekt?
Gliedern Sie den Umfang in eine Work-Breakdown-Struktur oder ein Backlog, schätzen Sie jedes Element mit einer Methode, die zu Ihrer Phase im Lebenszyklus passt (Story Points für Agile, Aufgabenstunden für einen festgelegten Umfang), berücksichtigen Sie Kostentreiber und Kalibrierung und fassen Sie anschließend alles zusammen, um eine Aufwandsspanne von 50/90 sowie einen Dollarbetrag anhand Ihres gemischten Stundensatzes zu ermitteln.
Was sind die vier wichtigsten Arten der Softwareschätzung?
Die vier großen Kategorien sind Expertenurteil (Wideband Delphi, Planning Poker), analoge Schätzung (Vergleich mit früheren Projekten), parametrische Schätzung (COCOMO II und ähnliche Modelle) und Bottom-up-Schätzung (auf der WBS basierende Aufgabenzerlegung). Die zuverlässigsten Schätzungen kombinieren mindestens zwei dieser Methoden.
Wie schätzen Sie die Kosten eines Softwareprojekts?
Rechnen Sie Ihre Aufwandsschätzung (in Personenstunden oder Personenmonaten) mithilfe eines vollständig belasteten gemischten Stundensatzes, der Gehälter, Zusatzleistungen und Gemeinkosten umfasst, in Dollar um.
Was ist die 50/90-Schätztechnik?
Die 50/90-Technik gibt zwei Perzentilergebnisse aus einer Wahrscheinlichkeitsverteilung des Aufwands oder der Dauer an. Das 50. Perzentil (der Median) ist das Ergebnis, das ungefähr in der Hälfte der Fälle erwartet wird; das 90. Perzentil entspricht dem Budget oder Zeitplan, der erforderlich ist, um mit hoher Zuversicht eine Überschreitung zu vermeiden. Verwenden Sie das 50. Perzentil für die interne Planung und das 90. Perzentil für Finanzierungsanträge und Festpreisverträge.
Wann sollten Story Points in Stunden umgerechnet werden?
Story Points sollten nur für kurzfristige Kapazitätsprüfungen in Stunden umgerechnet werden, beispielsweise um zu bestätigen, dass ein Sprint in die verfügbaren Teamstunden passt. Die Umrechnung von Story Points in Stunden für Prognosen über mehrere Sprints oder auf Release-Ebene führt zu einer Scheingenauigkeit und untergräbt das relative Größenmodell, das Story Points überhaupt erst nützlich macht.