---

name: plan-sprint description: > Einen Sprint planen durch Verfeinern von Backlog-Eintraegen, Definieren eines Sprint-Ziels, Berechnen der Teamkapazitaet, Auswaehlen von Eintraegen und deren Zerlegung in Aufgaben. Erstellt eine SPRINT-PLAN.md mit Ziel, ausgewaehlten Eintraegen, Aufgabengliederung und Kapazitaetszuweisung. Verwenden beim Start eines neuen Sprints in einem Scrum- oder agilen Projekt, bei erneuter Planung nach wesentlicher Scope-Aenderung, beim Uebergang von Ad-hoc-Arbeit zu strukturiertem Sprint-Rhythmus oder nach Backlog-Grooming, wenn Eintraege bereit fuer die Aufnahme sind. license: MIT allowed-tools: Read Write Edit Bash Grep Glob metadata: author: Philipp Thoss version: "1.0" domain: project-management complexity: intermediate language: multi tags: project-management, sprint, agile, scrum, capacity, sprint-planning locale: de source_locale: en source_commit: 6f65f316 translator: claude-opus-4-6 translation_date: "2026-03-16"

Sprint planen

Einen zeitbeschraenkten Sprint planen, indem verfeinerte Backlog-Eintraege bis zur Teamkapazitaet ausgewaehlt, ein klares Sprint-Ziel definiert und ausgewaehlte Eintraege in umsetzbare Aufgaben zerlegt werden. Dieser Skill erstellt einen vollstaendigen Sprint-Plan, der die Teamarbeit waehrend der Sprint-Iteration steuert.

Wann verwenden

• Start eines neuen Sprints in einem Scrum- oder agilen Projekt
• Erneute Sprint-Planung nach wesentlicher Scope-Aenderung
• Uebergang von Ad-hoc-Arbeit zu strukturiertem Sprint-Rhythmus
• Nach Backlog-Grooming, wenn Eintraege fuer den Sprint bereit sind
• Planen des ersten Sprints nach Genehmigung des Projektauftrags

Eingaben

• Erforderlich: Product Backlog (priorisiert, mit Schaetzungen)
• Erforderlich: Sprint-Dauer (typischerweise 1-2 Wochen)
• Erforderlich: Teammitglieder und ihre Verfuegbarkeit
• Optional: Velocity aus vorherigen Sprints (Story Points oder abgeschlossene Eintraege)
• Optional: Sprint-Nummer und Datumsbereich
• Optional: Uebertragene Eintraege aus dem vorherigen Sprint

Vorgehensweise

Schritt 1: Backlog-Eintraege ueberpruefen und verfeinern

Die aktuelle BACKLOG.md lesen. Fuer jeden Kandidaten-Eintrag nahe der Backlog-Spitze pruefen, ob er Folgendes hat:

• Klaren Titel und Beschreibung
• Abnahmekriterien (testbare Bedingungen)
• Schaetzung (Story Points oder T-Shirt-Groesse)
• Keine ungeloesten Blockaden

Eintraege ohne diese Elemente verfeinern. Eintraege, die auf mehr als die Haelfte der Sprint-Kapazitaet geschaetzt werden, in kleinere, handhabbare Teile aufteilen.

Erwartet: Die obersten 10-15 Backlog-Eintraege sind "sprint-bereit" mit Abnahmekriterien und Schaetzungen.

Bei Fehler: Wenn Eintraege keine Abnahmekriterien haben, diese jetzt schreiben. Wenn Eintraege nicht geschaetzt werden koennen, ein Verfeinerungsgespraech einplanen und nur bereite Eintraege auswaehlen.

Schritt 2: Sprint-Ziel definieren

Ein einziges klares Sprint-Ziel schreiben — einen Satz, der beschreibt, was der Sprint erreichen wird. Das Ziel soll:

• Innerhalb der Sprint-Dauer erreichbar sein
• Wertvoll fuer Stakeholder sein
• Testbar sein (am Sprint-Ende verifizierbar)

**Sprint Goal**: [One sentence describing the objective]

Beispiel: "Enable users to reset their password through email verification with two-factor authentication."

Erwartet: Sprint-Ziel als ein klarer, testbarer Satz formuliert.

Bei Fehler: Wenn kein kohaerentes Ziel entsteht, koennen die Backlog-Prioritaeten verstreut sein — den Product Owner konsultieren, um sich auf ein einziges wertvolles Ergebnis zu konzentrieren.

Schritt 3: Teamkapazitaet berechnen

Verfuegbare Personentage fuer jedes Teammitglied berechnen:

## Team Capacity
| Team Member | Available Days | Overhead (%) | Net Capacity |
|-------------|---------------|-------------|--------------|
| [Name] | [Sprint days - PTO] | 20% | [Available × 0.8] |
| [Name] | [Sprint days - PTO] | 20% | [Available × 0.8] |
| **Total** | | | **[Sum] person-days** |

Overhead beruecksichtigt Besprechungen, Reviews, Ad-hoc-Anfragen (typischerweise 15-25%).

Bei Story Points: Velocity aus dem vorherigen Sprint als Kapazitaet verwenden. Beim ersten Sprint 60-70% des theoretischen Maximums verwenden.

Erwartet: Kapazitaet in Personentagen oder Story Points berechnet mit dokumentierten Annahmen.

Bei Fehler: Wenn keine historische Velocity existiert, konservativ planen — auf 60% Kapazitaet planen und nach dem Sprint anpassen. Besser weniger versprechen und liefern als zu viel versprechen und scheitern.

Schritt 4: Eintraege auswaehlen und Sprint-Backlog zusammenstellen

Eintraege von der Spitze des Product Backlogs auswaehlen, bis die Kapazitaet erreicht ist. Jeden ausgewaehlten Eintrag in Aufgaben zerlegen (je 2-8 Stunden):

# Sprint Plan: Sprint [N]
## Document ID: SP-[PROJECT]-S[NNN]

### Sprint Details
- **Sprint Goal**: [From Step 2]
- **Duration**: [Start date] to [End date]
- **Capacity**: [From Step 3] person-days / [N] story points
- **Team**: [List team members]

### Sprint Backlog
| ID | Item | Points | Tasks | Assignee | Status |
|----|------|--------|-------|----------|--------|
| B-001 | [Item title] | 5 | 4 | [Name] | To Do |
| B-002 | [Item title] | 3 | 3 | [Name] | To Do |
| B-003 | [Item title] | 8 | 6 | [Name] | To Do |
| **Total** | | **16** | **13** | | |

### Task Breakdown

#### B-001: [Item title]
**Acceptance Criteria**: [From backlog item]

- [ ] Task 1: [Description] (4h, [Assignee])
- [ ] Task 2: [Description] (2h, [Assignee])
- [ ] Task 3: [Description] (4h, [Assignee])
- [ ] Task 4: [Description] (2h, [Assignee])

#### B-002: [Item title]
**Acceptance Criteria**: [From backlog item]

- [ ] Task 1: [Description] (3h, [Assignee])
- [ ] Task 2: [Description] (4h, [Assignee])
- [ ] Task 3: [Description] (2h, [Assignee])

#### B-003: [Item title]
**Acceptance Criteria**: [From backlog item]

- [ ] Task 1: [Description] (3h, [Assignee])
- [ ] Task 2: [Description] (4h, [Assignee])
- [ ] Task 3: [Description] (2h, [Assignee])
- [ ] Task 4: [Description] (3h, [Assignee])
- [ ] Task 5: [Description] (4h, [Assignee])
- [ ] Task 6: [Description] (2h, [Assignee])

### Risks and Dependencies
| Risk | Impact | Mitigation |
|------|--------|-----------|
| [Risk 1] | [Impact] | [Mitigation] |
| [Risk 2] | [Impact] | [Mitigation] |

### Carry-Over from Previous Sprint
| ID | Item | Reason | Remaining Effort |
|----|------|--------|-----------------|
| B-XXX | [Item] | [Reason] | [Hours/points] |

Erwartet: Sprint-Backlog mit bis zur Kapazitaet ausgewaehlten Eintraegen, jeder in Aufgaben mit Zeitschaetzungen zerlegt.

Bei Fehler: Wenn die Gesamtpunkte die Kapazitaet ueberschreiten, den niedrigst-priorisierten Eintrag entfernen. Die Kapazitaet nie um mehr als 10% ueberschreiten. Wenn Abhaengigkeiten die Sequenzierung blockieren, Eintraege neu anordnen oder verschieben.

Schritt 5: Verpflichtungen dokumentieren und speichern

Den Sprint-Plan in SPRINT-PLAN.md (oder SPRINT-PLAN-S[NNN].md fuer die Archivierung) schreiben. Bestaetigen:

• Sprint-Ziel ist mit ausgewaehlten Eintraegen erreichbar
• Kein Teammitglied ist ueberbelastet (>100% Kapazitaet)
• Abhaengigkeiten zwischen Eintraegen sind korrekt sequenziert
• Uebertragene Eintraege sind in der Kapazitaet beruecksichtigt
• Alle Abnahmekriterien aus Backlog-Eintraegen kopiert

Eine abschliessende Validierung durchfuehren:

# Check that total task hours align with capacity
grep -A 100 "Task Breakdown" SPRINT-PLAN.md | grep -o '([0-9]*h' | sed 's/[^0-9]//g' | awk '{sum+=$1} END {print "Total hours:", sum}'

Erwartet: SPRINT-PLAN.md erstellt mit vollstaendigem Sprint-Backlog und Aufgabengliederung. Gesamtstunden sollten kleiner gleich 80% der verfuegbaren Personentage multipliziert mit 8 Stunden sein.

Bei Fehler: Wenn Verpflichtungen nicht mit dem Ziel uebereinstimmen, die Eintragsauswahl in Schritt 4 ueberarbeiten. Wenn Aufgabenstunden die Kapazitaet ueberschreiten, den letzten Eintrag entfernen oder Aufgaben feingranularer zerlegen.

Validierung

• Sprint-Ziel ist ein klarer, testbarer Satz
• Teamkapazitaet berechnet mit dokumentierten Annahmen (Overhead-%, Urlaub beruecksichtigt)
• Ausgewaehlte Eintraege ueberschreiten die Kapazitaet nicht (Punkte oder Personentage)
• Jeder ausgewaehlte Eintrag hat Abnahmekriterien in der Aufgabengliederung
• Jeder ausgewaehlte Eintrag ist in Aufgaben zerlegt (je 2-8 Stunden)
• Kein Teammitglied ueber 100% Kapazitaet belastet
• Uebertragene Eintraege aus dem vorherigen Sprint mit verbleibendem Aufwand dokumentiert
• Abhaengigkeiten zwischen Eintraegen korrekt sequenziert
• Risiken und Minderungsmassnahmen dokumentiert
• SPRINT-PLAN.md-Datei erstellt und gespeichert

Haeufige Stolperfallen

• Kein Sprint-Ziel: Ohne Ziel ist der Sprint nur ein Beutel voller Aufgaben. Das Ziel gibt Fokus und eine Grundlage fuer Scope-Entscheidungen waehrend des Sprints.
• Ueberprogrammierung: Auf 100% Kapazitaet zu planen ignoriert Unterbrechungen, Fehler und Overhead. Auf 70-80% planen, um Puffer fuer Unerwartetes zu haben.
• Aufgaben zu gross: Aufgaben ueber 8 Stunden verbergen Komplexitaet und erschweren die Fortschrittsverfolgung. Zerlegen, bis Aufgaben 2-8 Stunden betragen.
• Uebertragung ignorieren: Unfertige Eintraege aus dem letzten Sprint verbrauchen Kapazitaet in diesem Sprint. Sie explizit in Kapazitaetsberechnungen beruecksichtigen.
• Sprint-Ziel als Eintragliste: "B-001, B-002, B-003 abschliessen" ist kein Ziel. Ein Ziel beschreibt das Ergebnis: "Benutzer koennen ihr Passwort per E-Mail-Verifikation zuruecksetzen."
• Kein Aufgabeneigentuemer: Jede Aufgabe sollte zur Planungszeit einen Verantwortlichen haben, um Kapazitaetskonflikte fruehzeitig aufzudecken.
• Abnahmekriterien weglassen: Aufgaben ohne Abnahmekriterien koennen nicht getestet werden. Abnahmekriterien aus Backlog-Eintraegen in den Aufgabengliederungsabschnitt kopieren.

Verwandte Skills

• manage-backlog — Product Backlog pflegen und priorisieren, der die Sprint-Planung speist
• draft-project-charter — liefert Projektkontext und initialen Umfang fuer den ersten Sprint
• generate-status-report — Sprint-Fortschritt und Velocity an Stakeholder berichten
• conduct-retrospective — Sprint-Durchfuehrung ueberpruefen und Planungsprozess verbessern
• create-work-breakdown-structure — PSP-Arbeitspakete koennen den Backlog in hybriden Agil-Wasserfall-Ansaetzen speisen