pjt222/plan-sprint
i18n/de/skills/plan-sprint/SKILL.md
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.
$ install --global
skillsauthnpx skillsauth add pjt222/agent-almanac plan-sprintInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 15, 2026, 9:24 AM14.5s1 file scanned
SKILL.md
- name:
- plan-sprint
- description:
- >
- license:
- MIT
- allowed-tools:
- Read Write Edit Bash Grep Glob
- 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 speistdraft-project-charter— liefert Projektkontext und initialen Umfang fuer den ersten Sprintgenerate-status-report— Sprint-Fortschritt und Velocity an Stakeholder berichtenconduct-retrospective— Sprint-Durchfuehrung ueberpruefen und Planungsprozess verbesserncreate-work-breakdown-structure— PSP-Arbeitspakete koennen den Backlog in hybriden Agil-Wasserfall-Ansaetzen speisen
Related Skills
pjt222/unleash-the-agents
testing
VerifiedTrustedCommunity
Launch all available agents in parallel waves for open-ended hypothesis generation on problems where the correct domain is unknown. Use when facing a cross-domain problem with no clear starting point, when single-agent approaches have stalled, or when diverse perspectives are more valuable than deep expertise. Produces a ranked hypothesis set with convergence analysis and adversarial refinement.
9SKILL.mdUpdated Apr 15, 2026
pjt222/test-cli-application
tools
VerifiedTrustedCommunity
Write integration tests for a Node.js CLI application using the built-in node:test module. Covers the exec helper pattern, output assertions, filesystem state verification, cleanup hooks, JSON output parsing, error case testing, and state restoration after destructive tests. Use when adding tests to an existing CLI, testing a new command, verifying adapter behavior across frameworks, or setting up CI for a CLI tool.
9SKILL.mdUpdated Apr 15, 2026
pjt222/screen-trademark
development
VerifiedTrustedCommunity
Screen a proposed trademark for conflicts and distinctiveness before filing. Covers trademark database searches (TMview, WIPO Global Brand Database, USPTO TESS), distinctiveness analysis using the Abercrombie spectrum, likelihood of confusion assessment using DuPont factors and EUIPO relative grounds, common law rights evaluation, and goods/services overlap analysis. Produces a conflict report with a risk matrix. Use before adopting a new brand name, logo, or slogan — distinct from patent prior art search, which uses different databases, legal frameworks, and analysis methods.
9SKILL.mdUpdated Apr 15, 2026
pjt222/scaffold-cli-command
tools
VerifiedTrustedCommunity
Scaffold a new CLI command using Commander.js with options, action handler, three output modes (human-readable, quiet, JSON), and optional ceremony variant. Covers command naming, option design, shared context patterns, error handling, and integration testing. Use when adding a command to an existing Commander.js CLI, designing a new CLI tool from scratch, or standardizing command structure across a multi-command CLI.
9SKILL.mdUpdated Apr 15, 2026