Manage Backlog

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):

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:

1. Aufteilen wenn Schaetzung > 8 Punkte (oder > 1 Woche Aufwand): in 2-4 kleinere Eintraege zerlegen
2. Schaetzen mit der gewahlten Projektskala
3. Verfeinern vager Abnahmekriterien zu testbaren Bedingungen
4. 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-Erstellung
• create-work-breakdown-structure — PSP-Arbeitspakete koennen zu Backlog-Eintraegen werden
• plan-sprint — Sprint-Planung waehlt von der Spitze des Backlogs
• generate-status-report — Backlog-Burn-down speist Status-Berichte
• conduct-retrospective — Verbesserungspunkte aus der Retrospektive fliessen in den Backlog zurueck