pjt222/manage-backlog
i18n/de/skills/manage-backlog/SKILL.md
Einen Produkt- oder Projekt-Backlog mit priorisierten Eintraegen, Abnahmekriterien und Schaetzungen erstellen und pflegen. Umfasst User-Story-Schreiben, MoSCoW- Priorisierung, Backlog-Grooming, Eintragsteilung und Statusverfolgung. Verwenden beim Start eines neuen Projekts und Umwandlung von Umfang in umsetzbare Eintraege, beim laufenden Grooming vor der Sprint-Planung, bei Neu-Priorisierung nach Stakeholder-Feedback oder Scope-Aenderungen oder beim Aufteilen zu grosser Eintraege in implementierbare Stuecke.
$ install --global
skillsauthnpx skillsauth add pjt222/agent-almanac manage-backlogInstall 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:23 AM18.9s1 file scanned
SKILL.md
- name:
- manage-backlog
- 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, backlog, user-stories, prioritization, grooming, moscow
- locale:
- de
- source_locale:
- en
- source_commit:
- 6f65f316
- translator:
- claude-opus-4-6
- translation_date:
- 2026-03-16
Produkt-Backlog verwalten
Einen Backlog von Arbeitseintraegen erstellen, priorisieren und pflegen, der als einzige Wahrheitsquelle fuer ausstehende Arbeit dient, anwendbar auf agile und klassische Projektmethoden.
Wann verwenden
- Start eines neuen Projekts und Umwandlung von Umfang in umsetzbare Eintraege
- Laufendes Backlog-Grooming vor der Sprint-Planung
- Neu-Priorisierung von Arbeit nach Stakeholder-Feedback oder Scope-Aenderungen
- Aufteilen zu grosser Eintraege in implementierbare Stuecke
- Ueberpruefen und Archivieren abgeschlossener oder abgebrochener Eintraege
Eingaben
- Erforderlich: Projektumfang (aus Charter, PSP oder Stakeholder-Input)
- Optional: Vorhandene Backlog-Datei (BACKLOG.md) zur Aktualisierung
- Optional: Priorisierungs-Framework-Praeferenz (MoSCoW, Wert/Aufwand, WSJF)
- Optional: Schaetzungsskala (Story Points, T-Shirt-Groessen, Personentage)
- Optional: Sprint- oder Iterations-Feedback, das Backlog-Aktualisierungen erfordert
Vorgehensweise
Schritt 1: Backlog-Struktur erstellen oder laden
Wenn kein Backlog vorhanden ist, BACKLOG.md mit Standardspalten erstellen. Wenn einer vorhanden ist, lesen und Struktur validieren.
# Product Backlog: [Project Name]
## Last Updated: [YYYY-MM-DD]
### Summary
- **Total Items**: [N]
- **Ready for Sprint**: [N]
- **In Progress**: [N]
- **Done**: [N]
- **Cancelled**: [N]
### Backlog Items
| ID | Title | Type | Priority | Estimate | Status | Sprint |
|----|-------|------|----------|----------|--------|--------|
| B-001 | [Title] | Feature | Must | 5 | Ready | — |
| B-002 | [Title] | Bug | Should | 2 | Ready | — |
| B-003 | [Title] | Task | Could | 3 | New | — |
### Item Details
#### B-001: [Title]
- **Type**: Feature | Bug | Task | Spike | Tech Debt
- **Priority**: Must | Should | Could | Won't
- **Estimate**: [Points or size]
- **Status**: New | Ready | In Progress | Done | Cancelled
- **Acceptance Criteria**:
- [ ] [Criterion 1]
- [ ] [Criterion 2]
- **Notes**: [Context, links, dependencies]
#### B-002: [Title]
...
Erwartet: BACKLOG.md existiert mit gueltiger Struktur und Zusammenfassungsstatistiken.
Bei Fehler: Wenn die Datei fehlerhaft ist, unter Beibehaltung vorhandener Eintragsdaten neu strukturieren.
Schritt 2: Eintraege schreiben oder verfeinern
Fuer jeden neuen Eintrag als User Story oder Anforderung schreiben:
- User-Story-Format: "Als [Rolle] moechte ich [Faehigkeit], damit [Nutzen]"
- Anforderungsformat: "[System/Komponente] soll [Verhalten] wenn [Bedingung]"
Jeder Eintrag muss haben:
- Eindeutige ID (B-NNN, aufsteigend)
- Klaren Titel (imperativische Verbform)
- Typklassifizierung
- Mindestens 2 Abnahmekriterien (testbar, binaeres Bestehen/Nicht-Bestehen)
Beispiel:
#### B-005: Enable User Login with OAuth
- **Type**: Feature
- **Priority**: Must
- **Estimate**: 5
- **Status**: Ready
- **Acceptance Criteria**:
- [ ] User can log in using GitHub OAuth
- [ ] User session persists for 24 hours
- [ ] Failed login shows clear error message
- **Notes**: Requires OAuth app registration in GitHub
Erwartet: Alle Eintraege haben Titel, Typen und Abnahmekriterien.
Bei Fehler: Eintraege ohne Abnahmekriterien werden als Status: New markiert (nicht Ready). Sie koennen keinen Sprint betreten.
Schritt 3: Mit MoSCoW oder Wert/Aufwand priorisieren
Das gewahlte Priorisierungs-Framework anwenden:
MoSCoW (Standard):
- Must: Projekt scheitert ohne dies. Nicht verhandelbar.
- Should: Wichtig, aber Projekt kann ohne es erfolgreich sein. Einbeziehen wenn Kapazitaet erlaubt.
- Could: Schoen zu haben. Nur einbeziehen, wenn kein Einfluss auf Must/Should-Eintraege.
- Won't: Explizit aus aktuellem Umfang ausgeschlossen. Fuer kuenftige Beruecksichtigung dokumentiert.
Wert/Aufwand-Matrix (Alternative):
| | Geringer Aufwand | Hoher Aufwand | |---|-----------|-------------| | Hoher Wert | Zuerst tun (Quick Wins) | Danach tun (grosse Wetten) | | Geringer Wert | Drittens tun (Fueller) | Nicht tun (Geldgruben) |
Die Backlog-Tabelle sortieren: Zuerst Must-Eintraege (nach Wert innerhalb von Must), dann Should, dann Could.
Erwartet: Jeder Eintrag hat eine Prioritaet. Backlog ist nach Prioritaet sortiert.
Bei Fehler: Wenn Stakeholder ueber Prioritaeten uneinig sind, Must-vs-Should-Entscheidungen an den Projektauftraggeber eskalieren.
Schritt 4: Groomen — Aufteilen, Schaetzen und Verfeinern
Eintraege auf Sprint-Bereitschaft pruefen. Fuer jeden Eintrag:
- Aufteilen wenn Schaetzung > 8 Punkte (oder > 1 Woche Aufwand): in 2-4 kleinere Eintraege zerlegen
- Schaetzen mit der gewahlten Projektskala
- Verfeinern vager Abnahmekriterien zu testbaren Bedingungen
- Als Ready markieren wenn der Eintrag Titel, Abnahmekriterien, Schaetzung und keine Blockaden hat
Aufteilung dokumentieren:
**Split**: B-003 split into B-003a, B-003b, B-003c (original archived)
#### B-003a: Set Up Database Schema
- **Type**: Task
- **Priority**: Must
- **Estimate**: 3
- **Status**: Ready
- **Acceptance Criteria**:
- [ ] Users table created with email, name fields
- [ ] Migrations run successfully on dev environment
#### B-003b: Implement User CRUD Operations
- **Type**: Task
- **Priority**: Must
- **Estimate**: 5
- **Status**: Ready
- **Acceptance Criteria**:
- [ ] Create user endpoint returns 201 with user object
- [ ] Update user endpoint validates required fields
Erwartet: Alle Must- und Should-Eintraege haben Ready-Status.
Bei Fehler: Eintraege, die nicht geschaetzt werden koennen, benoetigen einen Spike (zeitbegrenzte Rechercheaufgabe), der dem Backlog hinzugefuegt wird.
Schritt 5: Zusammenfassung aktualisieren und archivieren
Die Zusammenfassungsstatistiken aktualisieren. Done- und Cancelled-Eintraege in einen Archivabschnitt verschieben:
### Archive
| ID | Title | Status | Sprint | Completed |
|----|-------|--------|--------|-----------|
| B-001 | Enable User Login with OAuth | Done | S-003 | 2025-03-15 |
| B-004 | Add Dark Mode Theme | Cancelled | — | 2025-03-10 |
Die Zusammenfassung durch Zaehlen der Eintraege in jedem Status aktualisieren:
# Count Ready items
grep "| Ready |" BACKLOG.md | wc -l
# Count In Progress items
grep "| In Progress |" BACKLOG.md | wc -l
# Count Done items
grep "| Done |" BACKLOG.md | wc -l
Erwartet: Zusammenfassungsstatistiken stimmen mit tatsaechlichen Eintragsanzahlen ueberein. Archivabschnitt enthaelt alle geschlossenen Eintraege.
Bei Fehler: Wenn Zaehler nicht uebereinstimmen, durch Grep der Status-Werte neu zaehlen und Zusammenfassung manuell aktualisieren.
Validierung
- [ ] BACKLOG.md existiert mit Standardstruktur
- [ ] Jeder Eintrag hat eindeutige ID, Titel, Typ, Prioritaet und Status
- [ ] Alle Must- und Should-Eintraege haben Abnahmekriterien
- [ ] Eintraege sind nach Prioritaet sortiert (Must zuerst, dann Should, dann Could)
- [ ] Kein Eintrag auf > 8 Punkte geschaetzt ohne aufgeteilt zu sein
- [ ] Zusammenfassungsstatistiken sind korrekt
- [ ] Done/Cancelled-Eintraege sind archiviert
Haeufige Stolperfallen
- Keine Abnahmekriterien: Eintraege ohne Kriterien koennen nicht als fertig verifiziert werden. Jeder Eintrag braucht mindestens 2 testbare Kriterien.
- Alles hat Must-Prioritaet: Wenn mehr als 50% der Eintraege Must sind, sind die Prioritaeten nicht real. Must-Eintraege zwangs-ranken.
- Zombie-Eintraege: Eintraege, die monatelang ohne Fortschritt im Backlog liegen, sollten neu bewertet oder abgebrochen werden.
- Schaetzungen ohne Kontext: Story Points sind relativ — ein Team muss einen Referenz-Eintrag haben (z.B. "B-001 ist unser 3-Punkte-Referenz").
- Aufteilen erzeugt Fragmente: Beim Aufteilen sicherstellen, dass jeder Kind-Eintrag unabhaengig lieferbar und wertvoll ist.
- Backlog als Ablageort: Der Backlog ist keine Wunschliste. Regelmaessig Eintraege aussortieren, die nicht mehr mit den Projektzielen uebereinstimmen.
- Fehlende Abhaengigkeiten: Blockierende Eintraege im Notizen-Feld vermerken. Ein blockierter Eintrag sollte nicht als Ready markiert werden.
Verwandte Skills
draft-project-charter— Charter-Umfang speist die initiale Backlog-Erstellungcreate-work-breakdown-structure— PSP-Arbeitspakete koennen zu Backlog-Eintraegen werdenplan-sprint— Sprint-Planung waehlt von der Spitze des Backlogsgenerate-status-report— Backlog-Burn-down speist Status-Berichteconduct-retrospective— Verbesserungspunkte aus der Retrospektive fliessen in den Backlog zurueck
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