Schätzansätze vergleichen und den passenden wählen
Die Wahl der richtigen Kostenschätzungsmethode entscheidet darüber, wie verlässlich Ihr Budget ist. Zu grobe Methoden führen zu Überraschungen, zu detaillierte Methoden kosten unverhältnismäßig viel Vorarbeit. Dieser Artikel stellt die gängigsten Schätzverfahren für Softwareprojekte vor, vergleicht ihre Stärken und zeigt, wann welche Methode zum Einsatz kommen sollte.
1. Analogieschätzung (Top-Down)
Prinzip: Kosten werden aus vergleichbaren, bereits abgeschlossenen Projekten abgeleitet.
Vorgehen:
1. Ähnliches Referenzprojekt identifizieren
2. Tatsächliche Kosten des Referenzprojekts ermitteln
3. Unterschiede bewerten und Anpassungsfaktoren anwenden
| Eigenschaft | Bewertung |
|---|---|
| Genauigkeit | ±30–50 % |
| Aufwand für die Schätzung | Gering (1–2 Stunden) |
| Benötigte Informationen | Historische Projektdaten |
| Geeignet für | Frühe Projektphasen, Machbarkeitsprüfungen |
| Nicht geeignet für | Neuartige Projekte ohne Referenz |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
Beispiel:
Das letzte CRM-Projekt kostete 120.000 €. Das neue ist ähnlich, aber hat zusätzlich eine mobile App. Anpassungsfaktor: +40 %.
→ Schätzung: 168.000 €
2. Parametrische Schätzung
Prinzip: Kosten werden anhand messbarer Parameter berechnet (z. B. Anzahl Bildschirmmasken, API-Endpunkte, Datenbankentitäten).
Typische Parameter und Erfahrungswerte:
| Parameter | Durchschnittlicher Aufwand |
|---|---|
| Einfache CRUD-Seite | 2–4 Tage |
| Komplexe Geschäftslogik-Seite | 5–10 Tage |
| API-Endpunkt (einfach) | 0,5–1 Tag |
| API-Endpunkt (komplex) | 2–4 Tage |
| Datenbankentität (inkl. Migrations) | 0,5–1,5 Tage |
| Integration (Drittanbieter-API) | 3–8 Tage |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
| Eigenschaft | Bewertung |
|---|---|
| Genauigkeit | ±20–35 % |
| Aufwand für die Schätzung | Mittel (4–8 Stunden) |
| Benötigte Informationen | Grobe Anforderungsliste |
| Geeignet für | Projekte mit vergleichbaren Komponenten |
| Nicht geeignet für | Hochinnovative oder forschungslastige Projekte |
3. Bottom-Up-Schätzung
Prinzip: Das Projekt wird in kleine Arbeitspakete zerlegt, jedes einzeln geschätzt, dann summiert.
Vorgehen:
1. Work Breakdown Structure (WBS) erstellen
2. Jedes Arbeitspaket einzeln schätzen
3. Aufwände summieren
4. Zuschläge für PM, QA und Puffer addieren
| Eigenschaft | Bewertung |
|---|---|
| Genauigkeit | ±10–25 % |
| Aufwand für die Schätzung | Hoch (1–3 Tage) |
| Benötigte Informationen | Detaillierte Anforderungen |
| Geeignet für | Projekte ab der Planungsphase |
| Nicht geeignet für | Sehr frühe Ideenphase |
4. Drei-Punkt-Schätzung (PERT)
Prinzip: Für jeden Posten werden drei Schätzungen abgegeben (optimistisch, wahrscheinlich, pessimistisch) und gewichtet gemittelt.
Formel:
Erwartungswert = (Optimistisch + 4 × Wahrscheinlich + Pessimistisch) ÷ 6Beispiel für ein Feature „Benutzerverwaltung":
- Optimistisch: 8 Tage
- Wahrscheinlich: 12 Tage
- Pessimistisch: 22 Tage
- Erwartungswert: (8 + 48 + 22) ÷ 6 = 13 Tage (Kalkulationsbeispiel)
| Eigenschaft | Bewertung |
|---|---|
| Genauigkeit | ±15–25 % |
| Aufwand für die Schätzung | Mittel bis hoch |
| Benötigte Informationen | Erfahrene Schätzer mit Domänenwissen |
| Geeignet für | Projekte mit hoher Unsicherheit |
| Nicht geeignet für | Einfache, gut verstandene Aufgaben |
5. Story-Point-basierte Schätzung (Agile)
Prinzip: Aufwand wird in relativen Einheiten (Story Points) geschätzt, dann über die Team-Velocity in Zeit und Kosten umgerechnet.
Vorgehen:
1. User Stories definieren
2. Story Points vergeben (Fibonacci: 1, 2, 3, 5, 8, 13, 21)
3. Team-Velocity messen (Story Points pro Sprint)
4. Kosten pro Sprint berechnen
Beispiel:
- Gesamtes Backlog: 150 Story Points
- Team-Velocity: 30 Story Points/Sprint (2-Wochen-Sprint)
- Anzahl Sprints: 150 ÷ 30 = 5 Sprints = 10 Wochen
- Kosten pro Sprint (3-Personen-Team): 24.000 €/Sprint (Kalkulationsbeispiel)
- Geschätzte Gesamtkosten: 120.000 € (Kalkulationsbeispiel)
| Eigenschaft | Bewertung |
|---|---|
| Genauigkeit | ±15–30 % (nach einigen Sprints deutlich besser) |
| Aufwand für die Schätzung | Mittel (laufend im Prozess) |
| Benötigte Informationen | User Stories, historische Velocity |
| Geeignet für | Agile Teams mit Erfahrungswerten |
| Nicht geeignet für | Neue Teams ohne Velocity-Daten |
Vergleichsübersicht
| Methode | Genauigkeit | Aufwand | Geeignete Phase | Voraussetzung |
|---|---|---|---|---|
| Analogie | ±30–50 % | Gering | Idee/Konzept | Referenzprojekte |
| Parametrisch | ±20–35 % | Mittel | Konzept/Planung | Grobe Anforderungen |
| Bottom-Up | ±10–25 % | Hoch | Planung/Umsetzung | Detaillierte Anforderungen |
| Drei-Punkt (PERT) | ±15–25 % | Mittel–Hoch | Planung | Erfahrene Schätzer |
| Story Points | ±15–30 % | Mittel | Umsetzung | Agiles Team mit Velocity |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
Praxisbeispiel: Drei Methoden im Vergleich
Ein Unternehmen plant ein Dokumentenmanagementsystem. Drei Teams schätzen mit unterschiedlichen Methoden:
| Methode | Ergebnis | Kommentar |
|---|---|---|
| Analogie (letztes DMS-Projekt × 1,2) | 95.000 € | Schnelle Orientierung, aber ungenau |
| Parametrisch (40 Masken × 3 Tage × 100 €/h) [3] | 112.000 € | Konkretere Basis, fehlende Nebenkosten |
| Bottom-Up (detaillierte WBS) | 135.000 € | Am vollständigsten, inkl. PM und QA |
(Kalkulationsbeispiel)
Die Analogieschätzung unterschätzt die Kosten, weil sie Nebenkosten nicht berücksichtigt. Die parametrische Schätzung ist genauer, vergisst aber oft PM und QA. Die Bottom-Up-Schätzung ist am realistischsten.
Einordnung: In frühen Phasen kann eine Analogieschätzung als erste Orientierung dienen. Mit zunehmender Detailtiefe lassen sich parametrische Methoden und eine Bottom-Up-Analyse sinnvoll ergänzen.
Fazit und Einordnung
1. Die Methode sollte zur Projektphase passen: Frühe Phasen benötigen meist gröbere Verfahren, spätere Phasen detailliertere.
2. Methodenkombinationen können die Aussagekraft erhöhen: Zwei unabhängige Schätzungen ergeben häufig ein robusteres Bild als nur eine.
3. Die Drei-Punkt-Schätzung ist bei Unsicherheit hilfreich: Sie bildet Risiken in strukturierter Form ab.
4. Annahmen sollten transparent dokumentiert werden: Die Belastbarkeit jeder Schätzung hängt wesentlich von ihren Annahmen ab.
5. Regelmäßige Aktualisierungen bleiben sinnvoll: Schätzungen sind Momentaufnahmen und sollten mit neuen Informationen fortgeschrieben werden.
Quellen
- Bitkom IT-Arbeitsmarkt (2025-10-01)
- GULP Stundensatzkalkulator (2025-06-01)
- StepStone – Gehälter IT-Softwareentwickler/in (2026-01-01)