Was macht Agiler Produkt-Owner?
Toolkit für Backlog-Verwaltung und Sprint-Durchführung für Produkt-Owner. Enthält User-Story-Generierung, Abnahmekriterien-Muster, Sprint-Planung und Velocity-Tracking.
Inhaltsverzeichnis
- Workflow zur User-Story-Generierung
- Abnahmekriterien-Muster
- Workflow zur Epik-Aufteilung
- Workflow zur Sprint-Planung
- Backlog-Priorisierung
- Referenzdokumentation
- Werkzeuge
Workflow zur User-Story-Generierung
Erstelle INVEST-konforme User Stories aus Anforderungen:
- Identifiziere die Persona (wer von dieser Funktion profitiert)
- Definiere die Aktion oder Fähigkeit, die benötigt wird
- Formuliere den Nutzen oder den gelieferten Wert
- Schreibe Abnahmekriterien mittels Given-When-Then
- Schätze Story Points mit der Fibonacci-Skala
- Validiere anhand der INVEST-Kriterien
- Füge mit Priorität zum Backlog hinzu
- Validierung: Die Story erfüllt alle INVEST-Kriterien; Abnahmekriterien sind testbar
User-Story-Vorlage
Als [Persona]
möchte ich [Aktion/Fähigkeit],
um [Nutzen/Wert] zu erhalten.
Beispiel:
Als Marketing-Manager
möchte ich Kampagnenberichte als PDF exportieren können,
um Ergebnisse mit Stakeholdern teilen zu können, die keinen Systemzugriff haben.
Story-Typen
| Typ | Vorlage | Beispiel |
|---|---|---|
| Feature | Als [Persona] möchte ich [Aktion], um [Nutzen] | Als Benutzer möchte ich Suchergebnisse filtern, um Artikel schneller zu finden |
| Verbesserung | Als [Persona] benötige ich [Fähigkeit], um [Ziel] | Als Benutzer benötige ich schnellere Seitenladezeiten, um Aufgaben ohne Frustration zu erledigen |
| Fehlerbehebung | Als [Persona] erwarte ich [Verhalten], wenn [Bedingung] | Als Benutzer erwarte ich, dass mein Warenkorb beim Aktualisieren der Seite erhalten bleibt |
| Befähiger | Als Entwickler muss ich [technische Aufgabe] umsetzen, um [Fähigkeit] zu ermöglichen | Als Entwickler muss ich Caching implementieren, um sofortige Suche zu ermöglichen |
Personen-Referenz
| Persona | Typische Bedürfnisse | Kontext |
|---|---|---|
| Endbenutzer | Effizienz, Einfachheit, Zuverlässigkeit | Tägliche Nutzung von Funktionen |
| Administrator | Kontrolle, Transparenz, Sicherheit | Systemverwaltung |
| Power-User | Automatisierung, Individualisierung, Shortcuts | Experten-Workflows |
| Neuer Benutzer | Anleitung, Lernen, Sicherheit | Onboarding |
Abnahmekriterien-Muster
Schreibe testbare Abnahmekriterien im Given-When-Then-Format.
Given-When-Then-Vorlage
Gegeben [Vorbedingung/Kontext],
Wenn [Aktion/Auslöser],
Dann [erwartetes Ergebnis].
Beispiele:
Gegeben der Benutzer ist mit gültigen Anmeldedaten eingeloggt,
Wenn er auf die Schaltfläche „Exportieren“ klickt,
Dann startet innerhalb von 2 Sekunden ein PDF-Download.
Gegeben der Benutzer hat ein ungültiges E-Mail-Format eingegeben,
Wenn er das Registrierungsformular absendet,
Dann wird eine Inline-Fehlermeldung angezeigt: „Bitte geben Sie eine gültige E-Mail-Adresse ein.“
Gegeben der Warenkorb enthält Artikel,
Wenn der Benutzer den Browser aktualisiert,
Dann bleibt der Warenkorb-Inhalt unverändert.
Checkliste für Abnahmekriterien
Jede Story sollte Kriterien für folgende Kategorien enthalten:
| Kategorie | Beispiel |
|---|---|
| Positivpfad | Gegeben gültige Eingabe, Wenn abgesendet, Dann Erfolgsmeldung angezeigt |
| Validierung | Sollte Eingabe ablehnen, wenn Pflichtfeld leer ist |
| Fehlerbehandlung | Muss benutzerfreundliche Meldung anzeigen, wenn API fehlschlägt |
| Leistung | Sollte Vorgang innerhalb von 2 Sekunden abschließen |
| Barrierefreiheit | Muss nur über Tastatur navigierbar sein |
Mindestanzahl Kriterien nach Story-Größe
| Story Points | Mindestanzahl AC |
|---|---|
| 1-2 | 3-4 Kriterien |
| 3-5 | 4-6 Kriterien |
| 8 | 5-8 Kriterien |
| 13+ | Story aufteilen |
Siehe references/user-story-templates.md für die vollständige Vorlagenbibliothek.
Workflow zur Epik-Aufteilung
Teile Epics in lieferbare, sprint-gerechte Stories auf:
- Definiere Epik-Umfang und Erfolgskriterien
- Identifiziere alle von der Epik betroffenen Personas
- Liste alle benötigten Fähigkeiten für jede Persona auf
- Gruppiere Fähigkeiten in logische Stories
- Validiere, dass jede Story ≤8 Punkte beträgt
- Identifiziere Abhängigkeiten zwischen Stories
- Reihenfolge der Stories für inkrementelle Lieferung
- Validierung: Jede Story liefert eigenständigen Wert; alle Stories decken den Epik-Umfang ab
Aufteilungstechniken
| Technik | Wann anwenden | Beispiel |
|---|---|---|
| Nach Workflow-Schritt | Linearer Prozess | „Checkout“ → „In den Warenkorb“ + „Zahlung eingeben“ + „Bestellung bestätigen“ |
| Nach Persona | Mehrere Benutzertypen | „Dashboard“ → „Admin-Dashboard“ + „Benutzer-Dashboard“ |
| Nach Datentyp | Mehrere Eingaben | „Import“ → „CSV importieren“ + „Excel importieren“ |
| Nach Operation | CRUD-Funktionalität | „Benutzer verwalten“ → „Erstellen“ + „Bearbeiten“ + „Löschen“ |
| Positivpfad zuerst | Risikominimierung | „Feature“ → „Grundablauf“ + „Fehlerbehandlung“ + „Randfälle“ |
Epik-Beispiel
Epik: Benutzer-Dashboard
Aufteilung:
Epik: Benutzer-Dashboard (34 Punkte gesamt)
├── US-001: Schlüsselkennzahlen anzeigen (5 Pkt) - Endbenutzer
├── US-002: Layout anpassen (5 Pkt) - Power-User
├── US-003: Daten als CSV exportieren (3 Pkt) - Endbenutzer
├── US-004: Mit Team teilen (5 Pkt) - Endbenutzer
├── US-005: Benachrichtigungen einrichten (5 Pkt) - Power-User
├── US-006: Nach Datumsbereich filtern (3 Pkt) - Endbenutzer
├── US-007: Admin-Übersicht (5 Pkt) - Admin
└── US-008: Caching aktivieren (3 Pkt) - Befähiger
Workflow zur Sprint-Planung
Plane Sprint-Kapazität und wähle Stories aus:
- Berechne Team-Kapazität (Velocity × Verfügbarkeit)
- Überprüfe Sprint-Ziel mit Stakeholdern
- Wähle Stories aus priorisiertem Backlog
- Fülle bis zu 80-85 % der Kapazität (fest zugesagt)
- Füge Dehnungsziele hinzu (10-15 % zusätzlich)
- Identifiziere Abhängigkeiten und Risiken
- Zerlege komplexe Stories in Aufgaben
- Validierung: Zugesagte Punkte ≤85 % Kapazität; alle Stories haben Abnahmekriterien
Kapazitätsberechnung
Sprint-Kapazität = Durchschnitts-Velocity × Verfügbarkeitsfaktor
Beispiel:
Durchschnitts-Velocity: 30 Punkte
Team-Verfügbarkeit: 90 % (ein Mitglied teilweise abwesend)
Angepasste Kapazität: 27 Punkte
Fest zugesagt: 23 Punkte (85 % von 27)
Dehnungsziele: 4 Punkte (15 % von 27)
Verfügbarkeitsfaktoren
| Szenario | Faktor |
|---|---|
| Vollständiger Sprint, kein Urlaub | 1,0 |
| Ein Teammitglied 50 % abwesend | 0,9 |
| Feiertag während des Sprints | 0,8 |
| Mehrere Mitglieder abwesend | 0,7 |
Sprint-Beladungsvorlage
Sprint-Kapazität: 27 Punkte
Sprint-Ziel: [Klares, messbares Ziel]
FEST ZUGESAGT (23 Punkte):
[H] US-001: Benutzer-Dashboard (5 Pkt)
[H] US-002: Exportfunktion (3 Pkt)
[H] US-003: Suchfilter (5 Pkt)
[M] US-004: Einstellungsseite (5 Pkt)
[M] US-005: Hilfe-Tooltipps (3 Pkt)
[L] US-006: Designoptionen (2 Pkt)
DEHNUNGSZIELE (4 Punkte):
[L] US-007: Sortieroptionen (2 Pkt)
[L] US-008: Druckansicht (2 Pkt)
Siehe references/sprint-planning-guide.md für die vollständigen Planungsverfahren.
Backlog-Priorisierung
Priorisiere das Backlog anhand von Wert- und Aufwandsbewertung.
Prioritätsstufen
| Priorität | Definition | Sprint-Ziel |
|---|---|---|
| Kritisch | Blockiert Benutzer, Sicherheit, Datenverlust | Sofort |
| Hoch | Kernfunktionalität, wichtige Benutzerbedürfnisse | Dieser Sprint |
| Mittel | Verbesserungen, Erweiterungen | Nächste 2-3 Sprints |
| Niedrig | Nice-to-have, kleinere Verbesserungen | Backlog |
Priorisierungsfaktoren
| Faktor | Gewicht | Fragen |
|---|---|---|
| Geschäftswert | 40 % | Umsatzauswirkung? Benutzernachfrage? Strategische Ausrichtung? |
| Benutzerauswirkung | 30 % | Wie viele Benutzer? Wie häufig genutzt? |
| Risiko/Abhängigkeiten | 15 % | Technisches Risiko? Externe Abhängigkeiten? |
| Aufwand | 15 % | Größe? Komplexität? Unsicherheit? |
INVEST-Kriterien-Validierung
Vor dem Hinzufügen zum Sprint jede Story validieren:
| Kriterium | Frage | Bestanden wenn... |
|---|---|---|
| Independent (Unabhängig) | Kann dies ohne andere nicht zugesagte Stories entwickelt werden? | Keine blockierenden Abhängigkeiten |
| Negotiable (Verhandelbar) | Ist die Implementierung flexibel? | Mehrere Ansätze möglich |
| Valuable (Wertvoll) | Liefert dies Benutzer- oder Geschäftswert? | Klarer Nutzen im „um“-Teil |
| Estimable (Schätzbar) | Kann das Team dies schätzen? | Ausreichend verstanden, um zu bewerten |
| Small (Klein) | Kann dies in einem Sprint abgeschlossen werden? | ≤8 Story Points |
| Testable (Testbar) | Können wir die Fertigstellung überprüfen? | Klare Abnahmekriterien |
Referenzdokumentation
User-Story-Vorlagen
references/user-story-templates.md enthält:
- Standard-Story-Formate nach Typ (Feature, Verbesserung, Fehlerbehebung, Befähiger)
- Abnahmekriterien-Muster (Given-When-Then, Should/Must/Can)
- INVEST-Kriterien-Validierungscheckliste
- Anleitung zur Story-Point-Schätzung (Fibonacci-Skala)
- Häufige Story-Antipatterns und deren Behebung
- Techniken zur Story-Aufteilung
Sprint-Planungsleitfaden
references/sprint-planning-guide.md enthält:
- Tagesordnung für Sprint-Planungsmeetings
- Formeln zur Kapazitätsberechnung
- Rahmenwerk zur Backlog-Priorisierung (WSJF)
- Leitfäden für Sprint-Zeremonien (Daily, Review, Retrospektive)
- Velocity-Tracking und Burndown-Muster
- Definition of Done-Checkliste
- Sprint-Kennzahlen und -Ziele
Werkzeuge
User-Story-Generator
# Generiere Stories aus einer Beispiel-Epik
python scripts/user_story_generator.py
# Plane Sprint mit Kapazität
python scripts/user_story_generator.py sprint 30
Generiert:
- INVEST-konforme User Stories
- Given-When-Then-Abnahmekriterien
- Story-Point-Schätzungen (Fibonacci-Skala)
- Prioritätszuweisungen
- Sprint-Beladung mit fest zugesagten und Dehnungszielen
Beispielausgabe
USER STORY: USR-001
========================================
Titel: Schlüsselkennzahlen anzeigen
Typ: story
Priorität: HOCH
Punkte: 5
Story:
Als Endbenutzer möchte ich Schlüsselkennzahlen und KPIs anzeigen,
um Zeit zu sparen und effizienter zu arbeiten
Abnahmekriterien:
1. Gegeben der Benutzer hat Zugriff, Wenn er Schlüsselkennzahlen anzeigt, Dann wird das Ergebnis angezeigt
2. Sollte Eingabe vor der Verarbeitung validieren
3. Muss klare Fehlermeldung anzeigen, wenn die Aktion fehlschlägt
4. Sollte innerhalb von 2 Sekunden abgeschlossen sein
5. Muss über Tastaturnavigation zugänglich sein
INVEST-Checkliste:
✓ Independent
✓ Negotiable
✓ Valuable
✓ Estimable
✓ Small
✓ Testable
Sprint-Kennzahlen
Verfolge die Sprint-Gesundheit und Team-Leistung.
Wichtige Kennzahlen
| Kennzahl | Formel | Ziel |
|---|---|---|
| Velocity | Abgeschlossene Punkte / Sprint | Stabil ±10 % |
| Verbindlichkeit | Abgeschlossen / Zugesagt | >85 % |
| Umfangsänderung | Während des Sprints hinzugefügte oder entfernte Punkte | <10 % |
| Übertrag | Nicht abgeschlossene Punkte | <15 % |
Velocity-Tracking
Sprint 1: 25 Punkte
Sprint 2: 28 Punkte
Sprint 3: 30 Punkte
Sprint 4: 32 Punkte
Sprint 5: 29 Punkte
------------------------
Durchschnitts-Velocity: 28,8 Punkte
Trend: Stabil
Planung: 24-26 Punkte zusagen
Definition of Done
Die Story ist abgeschlossen, wenn:
- Code vollständig und peer-reviewed
- Unit-Tests geschrieben und bestanden
- Abnahmekriterien verifiziert
- Dokumentation aktualisiert
- In der Staging-Umgebung bereitgestellt
- Vom Product Owner akzeptiert
- Keine kritischen Fehler mehr vorhanden
Verwandte Kompetenzen
- Scrum Master (
project-management/scrum-master/) — Velocity-Daten und Sprint-Zeremonien ergänzen das Backlog-Management - Product Manager Toolkit (
product-team/product-manager-toolkit/) — RICE-Priorisierung speist die Backlog-Reihenfolge