Entwicklungsschätzungen mit Claude Code für echte Projekte

Eine Entwicklungsschätzung ist kein Ratespiel um die exakte Zahl von Tagen. In echten Projekten erklärt eine gute Schätzung Scope, Annahmen, Unbekanntes, Risiken, Review-Zeit und Verifikation, damit Produkt, Engineering und Kunde auf derselben Grundlage entscheiden.

Der typische Anfängerfehler ist, nur die reine Coding-Zeit zu zählen. “Ein Telefonfeld im Profil ergänzen” klingt klein, kann aber eine Datenbankmigration, API-Typen, Formularvalidierung, CSV-Exporte, Audit-Logs, Tests, Release Notes und Reviewer-Verfügbarkeit betreffen. Eine Migration verändert Datenbankschema oder Daten. Sie verdient eine eigene Schätzung, weil Daten nicht immer so leicht zurückgedreht werden können wie Code.

Claude Code macht Schätzungen nicht magisch exakt. Der Nutzen liegt darin, das Repository zu lesen, den Blast Radius sichtbar zu machen, Annahmen und Unbekanntes in Tabellen zu zwingen und Risiken aus dem Bauchgefühl herauszuholen. Lass Claude Code keine sicheren Termine erfinden. Lass es übersehene Arbeit finden.

Dieser Ansatz passt zum Empirismus des offiziellen Scrum Guide: Transparenz, Inspektion und Anpassung. Für die Nachverfolgung mehrerer Issues und PRs sind GitHubs milestones docs hilfreich. Für relative Schätzung lohnt sich Atlassians estimation guide. Für Claude Code selbst nutze die offizielle overview und CLI reference.

Als interne Ergänzung passen Codebase Navigation, das Bug-Report-Template und die Code-Review-Checkliste.

Eingaben Der Schätzung Trennen

Vor Terminen kommen fünf Eingaben.

Eingabe	Einfache Bedeutung	Was Claude Code leisten kann
scope	Was drin ist und was nicht	Dateien, verwandte Features, Tests
assumptions	Was wahr sein muss	Produktregeln, Rechte, Release-Pfad
unknowns	Was noch unklar ist	Dateien, Fragen, Verantwortliche
risk buffer	Raum für Fehler und Wartezeit	Migration, Auth, Billing, Review-Queue
evidence	Warum die Zahl belastbar ist	Frühere PRs, git history, Testanzahl

Vermeide eine einzelne Aussage wie “2 Tage”. Besser ist: “niedrig 1,5 Tage, wahrscheinlich 3 Tage, hoch 5 Tage, falls CRM in Scope ist.” Eine Spanne ist kein Zeichen von Unsicherheit im schlechten Sinn. Sie zeigt, was bekannt ist und was sich noch bewegen kann.

flowchart LR
  A["Anfrage"] --> B["repo scan"]
  B --> C["Aufgaben zerlegen"]
  C --> D["Annahmentabelle"]
  D --> E["Risikoregister"]
  E --> F["Schätzspanne"]
  F --> G["Review-Prompt"]
  G --> H["Kundenzusammenfassung"]

Vier Realistische Use Cases

Der erste Fall ist ein Profilfeld in einem SaaS. phone_number kann Datenbankschema, API-Validierung, UI, Suche, CSV-Export, Audit-Logs, Datenschutz und Tests berühren. Wenn es personenbezogene Daten sind, gehören Log-Masking und Lösch- oder Exportregeln in die Schätzung.

Der zweite Fall ist ein Bug in einer Legacy-Oberfläche. “Der Filter funktioniert nicht” kann alte Query-Helper, Cache, URL-Parameter, Fixtures und E2E-Tests betreffen. Bitte Claude Code zuerst um Impact Map und Verifikationsweg, bevor du den Fix verlangst.

Der dritte Fall ist ein Beratungsangebot oder eine interne DX-Anfrage. Ein Kunde sagt “wir brauchen ein Admin-Panel”, aber der echte Scope kann Login, Rollen, Audit, CSV, Benachrichtigungen, Rechteübergabe und Betriebsdokumentation umfassen. Claude Code kann bestehende Issues und Code lesen und Arbeit finden, die in der Anfrage fehlt.

Der vierte Fall ist eine monetarisierte Content-Seite. Eine kleine MDX-Änderung kann Performance, interne Links, OGP, strukturierte Daten, Lokalisierung, Screenshots und AdSense-taugliches Layout betreffen. Veröffentlichungsqualität ist mehr als Textbearbeitung.

Häufige Fehler

Der erste Fehler ist, die erste Intuition als Zusage zu teilen. “Vermutlich ein Tag” ist vor dem Repo-Scan nur ein Wunsch. Sobald dieser Wunsch beim Stakeholder ankommt, sieht eine bessere Schätzung wie Verzögerung aus.

Der zweite Fehler ist, Review und Verifikation als kostenlos zu behandeln. Sechs Stunden Implementierung können trotzdem Tests, Review-Fixes, Staging-Prüfung, Release Notes und Deployment-Koordination brauchen.

Der dritte Fehler ist, Unbekanntes in einem vagen Buffer zu verstecken. “30% drauf” hilft nicht, wenn der Grund fehlt: externe API unklar, Rollback nicht entworfen, Reviewer-Warteschlange, fehlende Fixtures oder unscharfe Produktregeln.

Der vierte Fehler ist, einer KI-Zahl ohne Belege zu glauben. Wenn Claude Code “3 Tage” sagt, aber keine Dateien, früheren PRs, Tests und Risiken nennt, ist das nur gut formulierte Prosa.

Step 1: Read-Only Repo Scan

Starte mit der Form des Repositories. Noch nicht editieren.

git status --short
git branch --show-current
git rev-parse --show-toplevel

rg --files \
  -g '!*node_modules*' \
  -g '!dist' \
  -g '!build' \
  -g '!coverage' \
  -g '!*.lock' \
  | sort \
  | head -200

find . -maxdepth 3 \( \
  -name package.json -o \
  -name pyproject.toml -o \
  -name go.mod -o \
  -name Cargo.toml -o \
  -name AGENTS.md -o \
  -name CLAUDE.md -o \
  -name README.md \
\) -print

Danach lässt du Claude Code eine read-only Karte erstellen.

claude -p "
Run a read-only repo scan.
Do not edit, create files, or add dependencies.

Return:
1. apps, packages, and services
2. runtime, test, and build entrypoints
3. generated folders to ignore
4. 10 files that must be read for this estimate
5. reasons this task cannot yet be estimated
"

Step 2: Aufgabe Zerlegen

Zerlege in Einheiten, die reviewbar und prüfbar sind.

claude -p "
Task: Let users add, view, and edit a phone number on their profile.

Break this into reviewable work items.
For each item include:
- name
- likely files
- implementation work
- test work
- definition of done
- size: small, medium, or large

Also list out-of-scope items.
Separate guessed product rules as assumptions.
"

Meist entstehen DB, API, UI, Tests und Release-Arbeit. Wenn eine Einheit nicht in eine PR passt, teile sie vor der Schätzung.

Step 3: Annahmentabelle

Annahmen sind spätere Bruchstellen. Schreibe sie auf.

| ID | Assumption | Why it matters | Owner | Confirm by |
| --- | --- | --- | --- | --- |
| A1 | Phone number is optional | Required fields change validation and migration | PM | 2026-06-05 |
| A2 | Web only, no mobile app change | Mobile release adds review and store delay | PM | 2026-06-05 |
| A3 | Existing user rows stay null | Backfill work is not included | Tech lead | 2026-06-06 |

claude -p "
Review this assumptions table.
Find assumptions that could break the estimate.
Add missing owners, deadlines, and questions.
Move anything risky into a risk register.
"

Step 4: Risikoregister

Ein Risikoregister listet Bedingungen, die den Plan brechen können.

| Risk | Trigger | Impact | Mitigation | Buffer |
| --- | --- | --- | --- | --- |
| DB rollback is unclear | migration changes existing rows | High | dry-run and rollback plan | 0.5-1 day |
| External CRM stores phone | CRM field mapping appears | Medium | check integration owner | 0.5 day |
| Review queue is full | no reviewer within 24h | Medium | book review slot early | 1 day |
| Test data is missing | no edge-case users | Medium | create fixtures first | 0.5 day |

Buffer ist kein Polster für langsames Arbeiten. Er ist Platz für Unbekanntes, Fehler und Wartezeit. Authentifizierung, Billing, private Daten, Löschflüsse und Migrationen brauchen mehr explizites Risiko als reine UI-Arbeit.

Step 5: Eine Spanne Berechnen

Dieses Skript kann direkt kopiert und ausgeführt werden.

// estimate-range.mjs
const tasks = [
  { name: "Repo scan and design check", hours: 2, risk: 1.1 },
  { name: "DB migration and schema", hours: 4, risk: 1.4 },
  { name: "API contract and validation", hours: 5, risk: 1.2 },
  { name: "Profile UI update", hours: 6, risk: 1.2 },
  { name: "Tests and fixtures", hours: 5, risk: 1.3 },
  { name: "Review fixes and release note", hours: 3, risk: 1.2 },
];

const base = tasks.reduce((sum, task) => sum + task.hours, 0);
const likely = tasks.reduce((sum, task) => sum + task.hours * task.risk, 0);
const low = Math.max(base * 0.8, base - 4);
const high = likely * 1.35;

const day = 6;
const format = (hours) => `${hours.toFixed(1)}h / ${(hours / day).toFixed(1)}d`;

console.log(`Low:    ${format(low)}`);
console.log(`Likely: ${format(likely)}`);
console.log(`High:   ${format(high)}`);

node estimate-range.mjs

Behandle den Multiplikator nicht als Wahrheit. risk: 1.4 bedeutet “dieser Bereich ist unsicher”. Wenn du ihn änderst, notiere den Grund im Issue oder in der PR.

Step 6: Kritisch Prüfen Lassen

Bevor ein Kunde die Schätzung sieht, soll Claude Code sie angreifen.

You are a critical project estimation reviewer.

Review this estimate before I share it with a client.
Find:
1. hidden scope
2. weak assumptions
3. missing tests
4. missing rollout or rollback work
5. fake precision
6. tasks that should be split

Return findings first.
Then provide a revised low / likely / high range.
Do not make the estimate look more certain than the evidence supports.

Die Formulierung zählt. “Mach es schöner” erzeugt schönere Sätze. “Kritisch prüfen” erzeugt nützlichen Widerstand.

Step 7: Kundenzusammenfassung Schreiben

Interne Notizen werden zu einem kurzen Entscheidungsdokument.

# Development Estimate Summary

## Scope
- Add optional phone number to user profile.
- Update DB schema, API validation, profile UI, and tests.
- Include release note and manual verification.

## Not included
- SMS notification.
- Mobile app release.
- Historical data backfill.
- CRM integration changes unless confirmed.

## Estimate
- Low: 3 business days
- Likely: 4-5 business days
- High: 7 business days if CRM or migration rollback work expands

## Assumptions
- Phone number is optional.
- Web only.
- Existing users can keep the value empty.

## Risks
- DB rollback plan must be reviewed before implementation.
- Reviewer availability may add one calendar day.

## Next decision
- Confirm whether CRM and mobile app are in scope by 2026-06-05.

Lege die Schätzung in GitHub Issues oder einem milestone ab, damit Ist-Werte später vergleichbar sind.

## Estimate
- Low:
- Likely:
- High:
- Confidence: Low / Medium / High

## Scope
- [ ]

## Out of scope
- [ ]

## Assumptions
- [ ]

## Risks
- [ ]

## Verification
- [ ] Unit tests:
- [ ] Integration tests:
- [ ] Manual check:

## Actual result
- Started:
- Merged:
- Extra work found:
- What to adjust next time:

Der Abschnitt Actual result macht die nächste Schätzung zu Lernen statt Meinung.

Consulting CTA

Schätzung ist ein guter Beratungseinstieg, weil Leser den Ablauf an ihr Repository, ihre Kundensprache und ihre Teamregeln anpassen müssen. ClaudeCodeLab kann Schätztemplates, Claude-Code-Review-Prompts, PR-Checklisten und Rollout-Regeln entwerfen. Wenn du den Ablauf mit deinen Issues oder Angeboten verbinden willst, sende Kontext über Claude Code Training und Beratung.

Praktisch Getestet

Masa hat diesen Workflow bei einer kleinen Profilfeld-Änderung getestet. Die erste Intuition war “ein halber Tag UI”. Nach dem repo scan kamen DB-Schema, API-Validierung, CSV-Export, Audit-Logs, Tests und Review-Queue dazu. Die kundentaugliche Spanne wurde 4-5 wahrscheinliche Arbeitstage, mit 7 Tagen als hohem Fall bei CRM-Arbeit. Claude Code war nützlich, weil es versteckte Dateien und Unbekanntes früh sichtbar gemacht hat, nicht weil es ein Datum erraten hat.