7 Techniken, um die Genauigkeit von Entwicklungsschätzungen mit Claude Code zu verdreifachen

Du hast “3 Tage” gesagt — es wurden 2 Wochen. Die klassische Projektmanagement-Falle. Die Ursache? Niemand hat den Code vor der Schätzung gelesen. Lass Claude Code zuerst die Codebasis lesen und die Schätzgenauigkeit verdreifacht sich.

1. Schätzen durch Lesen des Blast Radius

Wenn eine Aufgabe eintrifft, erst den Umfang klären.

claude -p "
Aufgabe: Spalte 'phone_number' zur users-Tabelle hinzufügen und
Anzeige/Bearbeitung im Profilbildschirm ermöglichen.

Liste jede Datei auf, die wir anfassen müssen:

1. DB-Schicht (migrations, schema)
2. API-Schicht (request/response types)
3. UI-Schicht (Formulare, Anzeige)
4. Tests (bestehende + neue)
5. Docs

Füge pro Datei eine Schätzung der Zeilenänderungen hinzu.
"

Eine “3-Datei-Änderung” entpuppt sich regelmäßig als “14 Dateien + 6 Tests”.

2. Vergangene ähnliche Aufgaben heranziehen

Ziehe Ist-Werte aus der git-Historie.

claude -p "
Finde jeden PR der letzten 6 Monate, der eine Spalte zur users-Tabelle hinzugefügt hat:

1. PR-Titel + Nummer
2. Tage von Start bis Merge
3. Geänderte Dateien
4. Review-Runden
5. Bug-Anzahl nach Deploy

Nutze git log --grep='add.*column' --since='6 months ago'.
Gib Mittelwert und Median an, plus eine Baseline für diese Schätzung.
"

“Ähnliche vergangene PRs dauerten im Schnitt 5 Arbeitstage” gibt dir eine verteidigbare Baseline.

3. Versteckte Abhängigkeiten aufdecken

Scope Creep killt Zeitpläne.

claude -p "
Untersuche für das Hinzufügen von 'phone_number' versteckte Auswirkungen:

1. Such-/Filterfunktionen, die aktualisiert werden müssen
2. Benachrichtigungsfunktionen (SMS)
3. Externe API-Integrationen (CRM, E-Mail)
4. Datenschutz-Compliance (GDPR / ähnliches)
5. Bestehende Analytics / Event-Tracking
6. Änderungen an mobiler App

Bewerte jede Auswirkung als Hoch/Mittel/Niedrig.
"

Spät auftauchende GDPR- oder Mobile-Arbeit vervielfacht Schätzungen um ein Mehrfaches.

4. Risikopuffer berechnen

Unsicherheit quantifizieren.

claude -p "
Berechne Risikopuffer-Faktoren für diese Aufgabe:

Faktoren:
- Vertrautheit mit verwandtem Code (hoch/mittel/niedrig)
- Testabdeckung verwandter Bereiche
- Kohäsion des berührten Codes
- Historie fehleranfälliger Bereiche
- Anzahl externer Abhängigkeiten
- Verfügbarkeit der Reviewer

Ordne jedem 1.0-2.0 zu, dann gib aus:
Endschätzung = reine Implementierungszeit × Produkt der Faktoren.
"

“3 Tage × 1.8 = 5.4 Tage” — mechanisch und verteidigbar.

5. Begründungsdokumente zu Schätzungen generieren

Für Stakeholder.

claude -p "
Schreibe docs/estimates/{task-id}.md:

## Aufgabenübersicht
## Blast Radius (Claudes Analyse)
## Ist-Werte vergangener ähnlicher Aufgaben
## Risikofaktoren und Pufferfaktoren
## Endschätzung (optimistisch / standard / pessimistisch)
## Annahmen und explizite Out-of-Scope-Punkte

Granularität: PM-lesbar.
"

“3 Tage” ohne Begründung ist nicht verteidigbar. Ein Begründungsdokument schafft Buy-in.

6. Regelmäßige Schätzung-vs-Ist-Analyse

Für kontinuierliche Verbesserung der Genauigkeit.

claude -p "
Für im letzten Monat abgeschlossene Aufgaben:

1. Schätzung vs. Ist-Delta aggregieren
2. Aufgaben mit hoher vs. niedriger Genauigkeit kategorisieren
3. Gründe für Abweichungen klassifizieren
4. Verbesserungen für das nächste Mal

Ausgabe nach docs/estimates/retrospective-$(date +%Y-%m).md.
Format für die monatliche Team-Retro.
"

Bringt team-spezifische Verzerrungen wie “wir verdoppeln immer bei DB-Arbeit” zum Vorschein.

7. Große Aufgaben in Phasen gliedern (Rolling Wave Planning)

Schätze riesige Aufgaben nicht in einem Schuss.

claude -p "
Zerlege 'Checkout-Flow-Neuschreibung' in gestufte Schätzungen:

Phase 1: Discovery (bestehenden Code analysieren, Anforderungen definieren) → X Tage
Phase 2: Design (technisches Designdokument) → Y Tage
Phase 3: PoC (Minimum-Implementierung) → Z Tage

Detaillierte Schätzung nur für Phase 1.
Phasen 2-3 nach Abschluss von Phase 1 neu schätzen.

Dies ist 'Rolling Wave Planning'.
"

Bei Arbeit mit hoher Unsicherheit sind phasenweise Schätzungen Pflicht. One-Shot-Schätzungen für große Arbeiten fliegen immer aus dem Ruder.

Schätzregeln in CLAUDE.md kodieren

## Estimation Rules

### Required process
- Tasks ≥1 day: scope with Claude Code first
- Tasks ≥3 days: state risk buffer explicitly
- Tasks ≥5 days: use phased estimates

### Buffer factor baselines
- Unfamiliar code: 1.5x
- Coverage <50%: 1.3x
- External API integration: 1.4x
- Legacy code: 1.8x

### Communication
- Always present optimistic / standard / pessimistic
- Escalate within 24h if scope shifts

Anti-Patterns

❌ Schätzen nur aus dem Bauchgefühl

Menschliche Schätzungen sind fast immer optimistisch verzerrt. Lass Claude Code zuerst den Code lesen.

❌ Null Puffer

“Punktgenaue” Schätzungen rutschen immer. Minimum 1.3x.

❌ Nachträgliches Rechtfertigen

Verstecke keine Ist-Abweichungen. Analysiere in Retros zur Verbesserung.

❌ Phasenschätzung überspringen

“Ich will die komplette Schätzung jetzt” ist eine Falle. Schlage Rolling Wave Planning vor.

Fazit

• Lass Claude Code den Blast Radius lesen
• Zitiere Ist-Werte vergangener ähnlicher Aufgaben
• Decke versteckte Abhängigkeiten auf
• Quantifiziere Risikopuffer
• Generiere Begründungsdokumente
• Führe monatliche Genauigkeits-Retros durch
• Gliedere große Aufgaben in Phasen
• Kodifiziere Regeln in CLAUDE.md

Bessere Schätzungen = höheres Teamvertrauen. “Liefert wie versprochen” verdient größere Aufgaben.

Verwandt: Team-Zusammenarbeit / PR-Qualität 10x / Entwickler-Onboarding

Offizielle Dokumentation: Anthropic Claude Code / Rolling Wave Planning (PMI)