Scrum Guide
Der umfassende Leitfaden zu Scrum: Events, Rollen, Artefakte und Best Practices
Product Backlog Refinement
Product Backlog Refinement (früher "Grooming" genannt) ist der kontinuierliche Prozess, bei dem das Scrum Team das Product Backlog verfeinert, Details hinzufügt, Schätzungen aktualisiert und Items priorisiert. Es ist KEIN offizielles Scrum Event, sondern eine fortlaufende Aktivität während des Sprints.
💡 Wichtig zu verstehen
Refinement ist keine formelle Ceremony im Scrum Guide. Es ist eine fortlaufende Aktivität, die das Team nach Bedarf durchführt – typischerweise etwa 10% der Sprint-Kapazität.
Was ist Product Backlog Refinement?
Refinement ist der Prozess, bei dem:
- Product Backlog Items detailliert werden: Grobe Ideen werden zu umsetzbaren Stories
- Schätzungen aktualisiert werden: Team schätzt den Aufwand neu oder erstmals
- Anforderungen geklärt werden: Offene Fragen werden beantwortet
- Items aufgeteilt werden: Zu große Stories werden gesplittet
- Akzeptanzkriterien definiert werden: "Done" wird klarer
Wer nimmt teil?
Product Owner
Erklärt die Business Value und Priorität. Beantwortet Fragen zur Funktionalität. Entscheidet über Umfang und Akzeptanzkriterien.
Entwicklungsteam
Stellt technische Fragen. Schätzt den Aufwand. Identifiziert technische Abhängigkeiten und Risiken. Schlägt alternative Lösungsansätze vor.
Scrum Master
Facilitiert die Session. Stellt sicher, dass das Team produktiv arbeitet. Hilft bei der Klärung von Missverständnissen.
Stakeholder (optional)
Bei Bedarf für spezifische fachliche Fragen oder komplexe Anforderungen.
Wie oft findet Refinement statt?
Es gibt keine feste Regel, aber typische Muster sind:
Regelmäßige Sessions
- → 1-2x pro Woche, je 60-90 Minuten
- → Fester Termin im Team-Kalender
- → Ca. 10% der Sprint-Kapazität
- → Vorhersehbar und planbar
Nach Bedarf
- → Wenn Items unklar werden
- → Vor komplexen Features
- → Wenn Backlog "leer läuft"
- → Flexibel, aber weniger Routine
Empfehlung: Regelmäßige Sessions schaffen Routine und verhindern, dass Refinement vergessen wird. Teams, die kontinuierlich verfeinern, haben bessere Sprint Plannings.
Typischer Refinement-Ablauf
- 1. Vorbereitung (Product Owner):
PO wählt Items aus, die refinement-ready sind. Stellt sicher, dass grundlegende Informationen verfügbar sind.
- 2. Item vorstellen:
PO erklärt das Item: Was soll erreicht werden? Warum ist es wichtig? Wer ist betroffen?
- 3. Klärung & Diskussion:
Team stellt Fragen. Technische Machbarkeit wird diskutiert. Alternative Ansätze werden erwogen.
- 4. Akzeptanzkriterien definieren:
Was muss erfüllt sein, damit das Item "Done" ist? Konkrete, testbare Kriterien.
- 5. Aufteilen (falls nötig):
Zu große Items werden in kleinere, unabhängige Stories gesplittet.
- 6. Schätzen:
Team schätzt den Aufwand (z.B. mit Planning Poker). Hohe Schätzungen signalisieren oft Unsicherheit oder zu große Scope.
- 7. Markieren als "Ready":
Item erfüllt Definition of Ready und kann ins Sprint Planning.
Definition of Ready
Viele Teams nutzen eine "Definition of Ready" als Checkliste für refinement-fertige Items:
- ✓Klar formuliert: User Story oder Anforderung ist verständlich
- ✓Akzeptanzkriterien definiert: "Done" ist klar
- ✓Geschätzt: Team hat Aufwand grob eingeschätzt
- ✓Klein genug: Kann in einem Sprint fertiggestellt werden
- ✓Testbar: Team weiß, wie sie es testen werden
- ✓Abhängigkeiten geklärt: Externe Dependencies sind bekannt
Best Practices
- ✓Kontinuierlich verfeinern: Nicht nur kurz vor Sprint Planning, sondern regelmäßig
- ✓2-3 Sprints vorausschauen: Halte genügend Items "ready" für kommende Sprints
- ✓Timeboxing nutzen: 15 Minuten pro Item, sonst vertagen
- ✓Prototyping erwägen: Bei Unsicherheit einen Spike einplanen
- ✓Gesamtes Team einbeziehen: Verschiedene Perspektiven sind wertvoll
- ✓Visualisierung nutzen: Skizzen, Mockups, Diagramme helfen
- ✓Product Vision präsent halten: Items im Kontext der Vision diskutieren
Häufige Fehler
- ✗Refinement vernachlässigen: Führt zu chaotischen Sprint Plannings
- ✗Zu detailliert zu früh: Verschwendung, wenn sich Anforderungen ändern
- ✗Nur PO und einzelne Entwickler: Team-Input fehlt
- ✗Technische Details festlegen: Refinement ist für "Was" und "Warum", nicht "Wie"
- ✗Zu lange Sessions: Nach 90 Minuten sinkt die Produktivität
- ✗Keine Priorisierung: Team weiß nicht, welche Items wichtig sind
Refinement vs. Sprint Planning
Product Backlog Refinement
- → Wann: Kontinuierlich während Sprint
- → Ziel: Items vorbereiten & verfeinern
- → Output: "Ready" Items für zukünftige Sprints
- → Commitment: Kein Commitment, nur Vorbereitung
- → Dauer: ~10% Sprint-Kapazität
Sprint Planning
- → Wann: Zu Beginn jedes Sprints
- → Ziel: Sprint-Backlog erstellen & commiten
- → Output: Sprint-Backlog mit Sprint Goal
- → Commitment: Team committed sich auf Sprint-Ziel
- → Dauer: Max. 8h für 4-Wochen-Sprint
Wichtig: Refinement bereitet vor, Sprint Planning entscheidet und committed. Ohne gutes Refinement wird Sprint Planning chaotisch und ineffizient.
Techniken für effektives Refinement
Story Mapping
Visualisiert User Journey und identifiziert Lücken im Backlog. Besonders gut für neue Features oder komplexe Workflows.
Example Mapping
Konkrete Beispiele helfen, Anforderungen zu klären. "Wie würde das in Situation X aussehen?"
Spike Stories
Bei hoher Unsicherheit: Timeboxxed Research-Story erstellen, um Wissen zu gewinnen.
3 Cs (Card, Conversation, Confirmation)
User Story ist ein Versprechen für Konversation. Refinement ist diese Konversation, Akzeptanzkriterien sind die Confirmation.
Zusammenfassung
Product Backlog Refinement ist kein optionales "Nice-to-have", sondern essentiell für erfolgreiche Sprints. Teams, die kontinuierlich verfeinern, haben:
- ✓ Reibungslosere Sprint Plannings (kürzer, fokussierter)
- ✓ Weniger Überraschungen im Sprint
- ✓ Bessere Schätzungen und Velocity-Prognosen
- ✓ Höhere Qualität durch klare Akzeptanzkriterien
- ✓ Weniger "Wir haben das falsch verstanden"-Momente
Product Backlog & Refinement - Podcast-Episoden
#126: Wieviele Methoden sollte ein guter Scrum Master wie gut kennen
Ein guter Scrum Master braucht nicht unzählige Methoden. Erfahre, welche 5 Kompetenzen wirklich zählen, um Teams situativ und effektiv zu begleiten.
#139: Product Discovery und Scrum
Scrum allein reicht nicht für erfolgreiche Produkte. Lerne, warum Product Discovery essenziell ist, um die richtigen Features zu bauen und Blindflug zu vermeiden.
#55: Agile Coaching Kompetenzen - Nachlese
Agile Coaches verlieren sich oft in theoretischen Abgrenzungen. Erfahre, warum die Wirkung für den Klienten wichtiger ist als dogmatische Methodenreinheit.
Scrum-Training buchen
Lerne Scrum in der Praxis kennen. Unsere zertifizierten Trainings vermitteln dir das nötige Wissen, um Scrum erfolgreich in deinem Unternehmen einzuführen.
Zu den Trainings