Backlog Refinement

Backlog Refinement ist ein kontinuierlicher Prozess zur Detaillierung, Schätzung und Priorisierung von Product Backlog Items, um sie für kommende Sprints vorzubereiten. Product Owner, Entwicklungsteam und Scrum Master klären Anforderungen, teilen Epics in User Stories auf und prüfen die Definition of Ready.

Kategorie:Agile Methoden

Backlog Refinement (früher auch Backlog Grooming genannt) ist ein fortlaufender Prozess in agilen Projekten, bei dem das Product Backlog überprüft, analysiert und optimiert wird. Ziel ist es, sicherzustellen, dass der Backlog die aktuellen Bedürfnisse des Produkts widerspiegelt und die hochprioritären Items ausreichend detailliert sind, um in kommenden Sprints umgesetzt werden zu können.

Zweck und Bedeutung

Backlog Refinement dient mehreren wichtigen Zwecken im agilen Entwicklungsprozess:

  • Vorbereitung auf Sprint Planning: Sicherstellen, dass hochprioritäre Backlog Items ausreichend verstanden und detailliert sind, um im nächsten Sprint umgesetzt werden zu können
  • Gemeinsames Verständnis: Schaffung einer einheitlichen Vorstellung im Team über Anforderungen und Lösungsansätze
  • Optimierung der Teameffizienz: Reduzierung von Unklarheiten und Verzögerungen während des Sprints
  • Dynamische Produktentwicklung: Kontinuierliche Anpassung an neue Erkenntnisse, Feedback und Marktveränderungen
  • Priorisierungsunterstützung: Lieferung notwendiger Informationen für fundierte Priorisierungsentscheidungen
  • Risikominimierung: Frühzeitige Identifikation technischer Risiken und Abhängigkeiten

Teilnehmer und Rollen

Am Backlog Refinement sind typischerweise folgende Rollen beteiligt:

Product Owner

  • Hauptverantwortlich für den Inhalt und die Priorisierung des Product Backlogs
  • Erläutert Geschäftsziele und Anforderungen hinter den Backlog Items
  • Trifft finale Entscheidungen zur Priorisierung und zum Scope
  • Sammelt und integriert Feedback von Stakeholdern

Entwicklungsteam

  • Liefert technisches Feedback und Machbarkeitseinschätzungen
  • Identifiziert technische Abhängigkeiten und Risiken
  • Schätzt den Aufwand für die Umsetzung von Backlog Items
  • Hilft bei der Aufschlüsselung größerer Items in kleinere, umsetzbare Einheiten

Scrum Master

  • Facilitiert den Refinement-Prozess
  • Sorgt für effiziente Diskussionen und Einhaltung von Timeboxes
  • Unterstützt beim Umgang mit Blockaden und Unklarheiten
  • Fördert die Einhaltung von Scrum-Werten und agilen Prinzipien

Weitere Teilnehmer (bei Bedarf)

  • Subject Matter Experts: Bieten Fachwissen zu spezifischen Domänen oder Technologien
  • Stakeholder: Geben direktes Feedback zu Anforderungen aus Business-Perspektive
  • UX/UI-Designer: Unterstützen bei der Definition von Nutzererfahrungsaspekten
  • Architekten: Beratung bei architektonischen Entscheidungen und systemischen Auswirkungen

Aktivitäten und Prozesse

Das Backlog Refinement umfasst verschiedene Aktivitäten, die je nach Bedarf und Kontext durchgeführt werden:

1. Detaillierung von Backlog Items

  • Hinzufügen spezifischer Beschreibungen und Kontextinformationen
  • Definition klarer Akzeptanzkriterien
  • Erstellung von Mockups, Wireframes oder anderen visuellen Hilfsmitteln
  • Klärung offener Fragen und Annahmen
  • Dokumentation technischer Anforderungen und Einschränkungen

2. Aufschlüsselung (Splitting)

  • Zerlegung großer Epics oder Features in kleinere, umsetzbare User Stories
  • Aufteilen von Stories, die zu groß für einen Sprint sind
  • Identifikation von Minimal Viable Product (MVP) Komponenten
  • Sicherstellung, dass jede Story einen eigenständigen Wert liefert

3. Schätzung

  • Bewertung des relativen Aufwands für Backlog Items (z.B. in Story Points)
  • Anwendung von Techniken wie Planning Poker oder Team Estimation Game
  • Diskussion unterschiedlicher Einschätzungen zur Förderung des gemeinsamen Verständnisses
  • Kalibrierung von Schätzungen im Vergleich zu bereits umgesetzten Items

4. Priorisierung

  • Bewertung des Business Value und der strategischen Bedeutung
  • Berücksichtigung von Risiken, Abhängigkeiten und zeitlichen Faktoren
  • Anwendung von Priorisierungstechniken wie WSJF (Weighted Shortest Job First) oder Kano-Modell
  • Anpassung der Backlog-Reihenfolge entsprechend der Priorisierung

5. Entfernung obsoleter Items

  • Identifikation und Archivierung nicht mehr relevanter Backlog Items
  • Bereinigung von doppelten oder redundanten Einträgen
  • Aktualisierung oder Entfernung überholter Anforderungen

6. Definition of Ready

  • Überprüfung, ob hochprioritäre Items die "Definition of Ready" erfüllen
  • Sicherstellung, dass alle notwendigen Informationen für die Implementierung vorhanden sind
  • Identifikation und Schließung von Informationslücken

Formate und Zeitplanung

Backlog Refinement kann in verschiedenen Formaten durchgeführt werden, je nach Teamgröße, Produktkomplexität und organisatorischem Kontext:

Dedizierte Refinement-Meetings

  • Regelmäßige, festgelegte Meetings mit dem gesamten Team
  • Typischerweise 1-2 Stunden, alle 1-2 Wochen
  • Fokus auf die nächsten 2-3 Sprints im Backlog
  • Empfohlener Zeitaufwand: 5-10% der gesamten Sprint-Kapazität

Just-in-time Refinement

  • Kleinere, bedarfsorientierte Sessions
  • Teilnahme nur der direkt betroffenen Teammitglieder
  • Fokus auf spezifische Backlog Items oder Themenbereiche
  • Flexible Terminierung nach Bedarf

Kontinuierliches Refinement

  • Integration in den täglichen Arbeitsablauf
  • Laufende Verfeinerung durch Product Owner und einzelne Teammitglieder
  • Ergänzung durch gelegentliche Team-Synchronisationen
  • Besonders effektiv für erfahrene, eingespielte Teams

Thematische Refinement-Workshops

  • Längere Workshops (halber oder ganzer Tag) zu spezifischen Themenkomplexen
  • Tiefgehende Auseinandersetzung mit komplexen Features oder Epics
  • Einbeziehung relevanter Stakeholder und Experten
  • Weniger häufig, aber intensiver als reguläre Refinement-Meetings

Definition of Ready

Die "Definition of Ready" (DoR) ist ein wichtiges Konzept im Zusammenhang mit Backlog Refinement und definiert, wann ein Backlog Item ausreichend vorbereitet ist, um in einen Sprint aufgenommen zu werden.

Eine typische Definition of Ready umfasst folgende Kriterien:

  • Wert: Der Business Value ist klar beschrieben und verstanden
  • Beschreibung: Die User Story ist klar und verständlich formuliert
  • Akzeptanzkriterien: Eindeutige, testbare Kriterien sind definiert
  • Abhängigkeiten: Alle externen Abhängigkeiten sind identifiziert
  • Schätzung: Das Team hat den Aufwand geschätzt
  • Kleinheit: Die Story ist klein genug, um innerhalb eines Sprints abgeschlossen zu werden
  • Testbarkeit: Es ist klar, wie die Story getestet werden kann
  • Machbarkeit: Technische Umsetzbarkeit wurde geprüft
  • Designaspekte: UI/UX-Elemente sind bei Bedarf skizziert
  • Konsens: Das Team hat ein gemeinsames Verständnis der Anforderungen

Die DoR sollte vom Team selbst definiert und regelmäßig überprüft werden, um den spezifischen Projektanforderungen gerecht zu werden.

Schätzungstechniken

Für die Aufwandsschätzung im Rahmen des Backlog Refinements werden verschiedene Techniken eingesetzt:

Planning Poker

  • Jedes Teammitglied erhält einen Satz Karten mit Werten (meist Fibonacci-Folge)
  • Nach Diskussion einer Story wählt jeder verdeckt einen Wert
  • Alle decken gleichzeitig auf; bei großen Unterschieden folgt weitere Diskussion
  • Prozess wird wiederholt, bis Konsens oder Annäherung erreicht ist
  • Fördert gleichberechtigte Beteiligung und verhindert Ankerbias

Team Estimation Game

  • Stories werden auf Karten geschrieben und in einer Reihe angeordnet
  • Team sortiert Karten nach relativem Aufwand von links (klein) nach rechts (groß)
  • Nach Einigung über die Reihenfolge werden konkrete Story-Point-Werte zugeordnet
  • Betont den relativen Charakter von Schätzungen

T-Shirt-Größen

  • Einfache Kategorisierung in XS, S, M, L, XL, XXL
  • Schnelle, intuitive Einordnung ohne detaillierte Diskussion
  • Kann später in numerische Werte übersetzt werden
  • Geeignet für frühe Projektphasen und grobe Einschätzungen

Silent Grouping

  • Stories werden ohne Diskussion von Teammitgliedern in Gruppen ähnlicher Größe sortiert
  • Reduziert Gruppendenken und soziale Einflüsse
  • Besonders nützlich für große Mengen an Backlog Items
  • Kann als Vorstufe für detailliertere Schätzungen dienen

Backlog Refinement in verschiedenen agilen Frameworks

Backlog Refinement in Scrum

In Scrum ist Backlog Refinement kein formales Event wie Sprint Planning oder Sprint Review, sondern ein kontinuierlicher Prozess. Es wird empfohlen, nicht mehr als 10% der Teamkapazität für Refinement-Aktivitäten zu verwenden. Der Scrum Guide betont die Bedeutung des Refinements für die Vorbereitung des Sprint Plannings, überlässt jedoch die konkrete Ausgestaltung dem Team.

Backlog Refinement in Kanban

In Kanban-Systemen erfolgt das Refinement typischerweise kontinuierlich als Teil des Workflows. Oft werden Backlog Items durch verschiedene Refinement-Stufen bewegt, bevor sie für die Implementierung bereit sind. Der Fokus liegt auf der Aufrechterhaltung eines stetigen Flusses von gut definierten Arbeitspaketen, die den Pull-Mechanismus unterstützen.

Backlog Refinement in SAFe

Im Scaled Agile Framework (SAFe) erfolgt Backlog Refinement auf mehreren Ebenen. Auf Team-Ebene ähnelt es dem Scrum-Ansatz. Darüber hinaus gibt es Program Backlog Refinement für den Programm Backlog und Portfolio Backlog Refinement für Epics auf Portfolio-Ebene. SAFe integriert das Refinement in den Kontext von PI (Program Increment) Planning und betont die Bedeutung für die mehrschichtige Planung.

Herausforderungen und Best Practices

Herausforderung: Zu viel oder zu wenig Detaillierung

Best Practices:

  • Progressive Elaboration: Details entsprechend der Priorität und zeitlichen Nähe
  • Just-enough-Prinzip: Nur so viel Detail wie nötig für fundierte Entscheidungen
  • Klare Definition of Ready als Orientierungsrahmen
  • Fokus auf die nächsten 2-3 Sprints, weniger Detail für spätere Items

Herausforderung: Ineffiziente oder zu lange Meetings

Best Practices:

  • Klare Agenda und Vorbereitung der zu besprechenden Items
  • Timebox für jedes Item festlegen und einhalten
  • Parking Lot für tiefergehende Diskussionen außerhalb des Meetings
  • Aufteilung in kleinere, fokussierte Sessions statt eines langen Meetings
  • Rotierendes Teilnehmermodell für spezifische Themen

Herausforderung: Mangelndes Engagement oder ungleiche Beteiligung

Best Practices:

  • Interaktive Formate und Techniken wie Planning Poker
  • Gezielte Einbeziehung stillerer Teammitglieder
  • Abwechslung in der Moderation und Präsentation von Backlog Items
  • Präsenzkultur ohne Laptops und Smartphones
  • Wechselnde Refinement-Formate zur Vermeidung von Monotonie

Herausforderung: Backlog Inflation und mangelnder Fokus

Best Practices:

  • Regelmäßiges "Backlog Pruning" zur Entfernung obsoleter Items
  • Strikte Priorisierung mit klarer Unterscheidung von "Jetzt", "Später", "Vielleicht"
  • Begrenzung der aktiven Backlog-Größe
  • Explicit Parking Lot oder "Ideen-Backlog" für nicht prioritäre Items
  • Value-based Backlog Management mit regelmäßiger Neubewertung des Business Value

Remote und hybrides Backlog Refinement

Für verteilte und hybride Teams sind spezifische Anpassungen hilfreich:

  • Digitale Kollaborationstools: Nutzung von Jira, Trello, Miro oder anderen visuellen Tools
  • Asynchrone Vorbereitung: Vorab-Sharing von Informationen und Fragen
  • Strukturierte Videokonferenzen: Klare Agenda, Redezeiten und Moderationsregeln
  • Digitale Schätzungswerkzeuge: Online Planning Poker oder andere digitale Schätzungsmethoden
  • Häufigere, kürzere Sessions: Aufteilung in kompakte Meetings zur Erhaltung der Konzentration
  • Dokumentierte Ergebnisse: Sorgfältige Dokumentation der Diskussionen und Entscheidungen
  • Check-ins und Energizer: Aktivierende Elemente zur Förderung der Beteiligung

Metriken und Erfolgsfaktoren

Die Effektivität des Backlog Refinements kann durch verschiedene Metriken und Indikatoren bewertet werden:

  • Sprint Planning Effizienz: Dauer und Reibungslosigkeit des Sprint Plannings
  • Sprint-Erfolgrate: Prozentsatz der erfolgreich umgesetzten Stories pro Sprint
  • Schätzungsgenauigkeit: Übereinstimmung zwischen Schätzungen und tatsächlichem Aufwand
  • Scope-Änderungen während des Sprints: Häufigkeit und Umfang von Änderungen nach Sprint-Start
  • Refinement-Durchsatz: Anzahl der pro Session verfeinerten Backlog Items
  • Team-Zufriedenheit: Wahrgenommener Wert und Effizienz des Refinement-Prozesses
  • Definition of Ready Compliance: Prozentsatz der Backlog Items, die die DoR erfüllen

Kontinuierliche Verbesserung des Refinement-Prozesses

Wie alle agilen Praktiken sollte auch das Backlog Refinement kontinuierlich optimiert werden:

  • Regelmäßige Retrospektiven: Spezifischer Fokus auf den Refinement-Prozess
  • Experimentieren mit Formaten: Testweise Anpassung von Dauer, Häufigkeit und Teilnehmerkreis
  • Anpassung an Teamreife: Entwicklung des Prozesses parallel zur Team-Evolution
  • Benchmark mit anderen Teams: Austausch von Best Practices und Lessons Learned
  • Feedback von Stakeholdern: Einbeziehung von Perspektiven außerhalb des Teams
  • Automatisierung von Routineaspekten: Nutzung von Tools zur Effizienzsteigerung

Backlog Refinement ist kein isoliertes Event, sondern ein integraler Bestandteil des agilen Entwicklungszyklus. Ein gut durchgeführtes Refinement schafft die Grundlage für erfolgreiche Sprints, minimiert Unsicherheiten während der Implementierung und ermöglicht es Teams, sich auf die Wertschöpfung zu konzentrieren. Durch kontinuierliche Verbesserung des Refinement-Prozesses können Teams ihre Effizienz steigern, die Planungssicherheit erhöhen und letztendlich bessere Produkte entwickeln, die den Bedürfnissen ihrer Nutzer entsprechen.