Nein, das Backlog Refinement ist kein weiteres, wenig hilfreiches Treffen, das vom Scrum-Rahmenwerk vorgeschrieben wird - ganz im Gegenteil.
Obwohl es nicht offiziell im Scrum Guide als Zeremonie aufgeführt ist, setzt es sich immer mehr als wichtiges Treffen in agilen Teams durch, um die Planung und den Ablauf des kommenden Sprints gelassener anzugehen.
Was ist das Backlog Refinement und wie läuft es ab? Außerdem liefern wir Ihnen einige Tipps für ein effektives Backlog Refinement.
Was ist Backlog Refinement?
Definition
Um das Backlog Refinement richtig zu verstehen, müssen wir uns zunächst über den Begriff Backlog im Klaren sein.
Das Backlog ist eine Liste von Geschäftsanforderungen an ein Produkt oder ein Projekt, die in Form von User Stories übersetzt werden, die den Benutzerbedarf genau beschreiben. Es wird vom Product Owner erstellt und verwaltet, und das gesamte Team konsultiert es während der Sprintplanung, um die Stories und Funktionen auszuwählen, zu deren Entwicklung es sich während des Sprints verpflichtet.
Backlog Refinement oder Backlog Grooming ist die Verfeinerung des Backlogs in einem speziellen Meeting während des Sprints.
Die Verfeinerung des Backlogs besteht konkret darin, :
- das Verständnis der User Stories zu klären,
- den Aufwand für die Umsetzung schätzen (oder neu schätzen),
- den funktionalen Wert jeder US zu bestimmen, um die Arbeit der Priorisierung zu erleichtern,
- USs entfernen (falls erforderlich),
- US hinzufügen (falls erforderlich).
🇫🇷 Die Übersetzung von Backlog Refinement ins Deutsche ist die Verfeinerung des Backlogs.
Backlog refinement vs. Sprint planning
Was ist der Unterschied zwischen dem Backlog Refinement Meeting und der Sprintplanung (Sprint Planning )?
Die Sprintplanung findet am ersten Tag des Sprints statt und dient dazu, das Ziel des Sprints zu definieren sowie die User Stories auszuwählen, zu deren Lieferung sich das Team am Ende verpflichtet. Sie kann etwa 2 Stunden pro Sprintwoche dauern.
Das Backlog Refinement bietet sich als Zwischen- und Zusatztreffen zur Sprintplanung an. Während des Sprints kann es mehrere davon geben, und sie sollen den Boden für die Sprintplanung bereiten, die effizienter sein sollte.
Wer sind die Teilnehmer des Backlog Refinement?
Alle Mitglieder des Scrum-Teams müssen an diesem Treffen teilnehmen, wir sprechen von :
- der-die Product Owner,
- der-die Scrum Master,
- das Entwicklungsteam,
- alle anderen Personen, die Hilfe leisten können.
Aber die Rolle jedes Einzelnen endet nicht mit seiner Anwesenheit am Tisch (oder am Bildschirm, bei Teams mit Videokonferenzen).
Der Product Owner ist für die Vorbereitung, Organisation und Leitung des Backlog Refinement Meetings verantwortlich. Er/sie bringt die Vision des Produkts ein und klärt die Elemente des Backlogs. Er/sie präzisiert die Geschäftsanforderungen, priorisiert die PBIs und beantwortet Fragen, die die Arbeit des Teams blockieren könnten.
Der/die Scrum Master/in sorgt dafür, dass die Backlog-Sitzung flüssig und strukturiert bleibt. Er/sie achtet auch darauf, dass jeder zu Wort kommt und dass der Prozess den agilen Prinzipien folgt. Er/sie ist sozusagen der Dirigent des Refinements.
Die Mitglieder des Entwicklungsteams spielen eine Schlüsselrolle, denn sie sind es, die das Projekt einschätzen, aufteilen und die Fragen stellen, die das Projekt vorantreiben. Ihr technisches Fachwissen hilft dabei, Risiken zu antizipieren und Aufgaben vor dem nächsten Sprint zu klären.
Schließlich können auch andere Profile eingeladen werden, z. B. technische Experten, UX-Designer oder sogar Stakeholder. Wenn ihre Anwesenheit dazu beiträgt, einen unklaren Punkt zu klären, warum darauf verzichten?
Was sind die Ziele des Backlog Refinement?
Die regelmäßige Durchführung von Backlog Refinement hat viele Vorteile:
- Diese Vorarbeit bringt Gelassenheit in die Planung und den Ablauf des nächsten Sprints,
- verfeinert das Verständnis des Bedarfs,
- bereitet die Schätzung der User Stories vor,
- ermöglicht eine Halbzeitbilanz,
- kann die Dauer des Sprint-Meeting-Plans verkürzen.
Und das ist noch nicht alles! Dieses agile Meeting richtet das gesamte Scrum-Team auf die Prioritäten des Product Backlogs aus. Das Ergebnis: weniger unvorhergesehene Ereignisse, weniger Nacharbeit und mehr Wertschöpfung in jeder Iteration.
Sie spielt auch eine Schlüsselrolle bei der kontinuierlichen Verbesserung. Durch die Verfeinerung der Backlog-Elementelernt man, die Stories besser zu schreiben, die Aufgaben feiner zu unterteilen und Abhängigkeiten zu antizipieren.
Schließlich verringert Refinement die Grauzonen. Es ermöglicht dem Entwicklungsteam, dem Product Owner alle notwendigen Fragen zu stellen, noch bevor der Sprint beginnt.
Wie lange dauert er und wie oft wird er durchgeführt?
Das hängt von den Teams ab, aber man rechnet mindestens mit einem einstündigen Backlog Refinement Meeting pro Sprint.
Im Sinne einer permanenten Agilität ist es jedoch ratsam, mehrere solcher Meetings durchzuführen, selbst wenn die Dauer kürzer ist. Dies ermöglicht es dem Product Owner, vorausschauend zu planen und Zeit zu haben, die US vor dem Ende des Sprints zu überarbeiten.
Oft wird davon gesprochen, dass etwa 10 % der Entwicklungszeit dafür aufgewendet werden sollten. Bei einem zweiwöchigen Sprintist das also ein halber Tag, der auf mehrere Backlog-Sitzungen aufgeteilt wird.
Erfahrenere Teams ziehen es vor, das Refinement in 30-minütige Mikro-Sitzungen aufzuteilen. Das Ergebnis: mehr Konzentration, weniger endlose Besprechungen und ein laufendes Produkt-Backlog.
Das Wichtigste ist, den richtigen Rhythmus zu finden, damit das Product Backlog immer für den nächsten Sprint bereit ist. Nicht zu früh (es ist sinnlos, Backlog-Elemente vorzubereiten, die sich ändern werden) und nicht zu spät (Refinement in letzter Minute öffnet dem Chaos Tür und Tor!).
Welche Schritte sind vor der Durchführung der Backlog-Verfeinerung erforderlich?
Alles beginnt mit der Vorbereitung des produzierten Backlogs durch den Product Owner. Er oder sie wählt die Backlog-Elemente aus, die besprochen werden sollen:
- die mit der höchsten Priorität,
- die mit den meisten Unklarheiten,
- diejenigen, bei denen für den nächsten Sprint viel auf dem Spiel steht.
Jede User Story muss nach den INVEST-Kriterien (Independent, Negotiable, Valuable, Estimable, Sufficiently Small, Testable) verfasst werden . Andernfalls droht beim Verfeinern Verwirrung!
Der Product Owner kann auch bestimmte Informationen vorab ausfüllen: Akzeptanzkriterien, Geschäftsbedarf oder andere nützliche Daten, um die Schätzung flüssiger zu gestalten.
Schließlich muss das Team vorab informiert werden. Eine gemeinsame Tagesordnung, einige vorbereitende Dokumente und eine kleine Erinnerung im Terminkalender legen den Grundstein für eine effektive Backlog-Sitzung.
💡 Gut vorbereitet spart man während der Sitzung Zeit… und vermeidet, dass man auf der Stelle tritt.
Ablauf des Backlog Refinements
1. Vorstellung und Verständnis der User Stories.
Zur Erinnerung: Der Product Owner ist dafür verantwortlich, eine Benutzeranfrage oder ein Benutzerbedürfnis so detailliert und klar wie möglich in eine User Story umzusetzen.
Er/sie wird also dem Rest des Teams die US vorstellen, die er/sie fertiggestellt hat, oder zumindest die, die schon weit fortgeschritten sind.
Ziel ist es, sicherzustellen, dass die Mitglieder des Entwicklungsteams den Bedarf vollständig verstehen, Fragen stellen und sich über die US austauschen können. Der Product Owner kann sie dann aufgrund der Fragen und Diskussionen ändern oder erweitern .
Das Team kann die User Story dann freigeben und mit der Schätzung fortfahren.
👉 Wenn sich herausstellt, dass das Entwicklungsteam die Anfrage nicht versteht, sollte sich der Product Owner Zeit nehmen, um seine US zu überarbeiten und zu verdeutlichen, um sie in der nächsten Sitzung erneut vorzustellen.
2. Verfeinerung der Schätzung
Die logische Folge der Validierung der US ist ihre Schätzung durch die Entwickler.
Jedes Team hat seine eigenen Methoden und Werkzeuge, um die US zu schätzen, aber in der Praxis wird eine US eher in Aufwandspunkten als in Zeit geschätzt.
Zu den am häufigsten verwendeten Methoden gehören :
- Planungspoker,
- die T-Shirt-Größe,
- das Bucket-System.
Es liegt an Ihnen, herauszufinden, welche Methode für Ihr Team und Ihre Projekte am besten geeignet ist. Wenn sich herausstellt, dass eine User Story kompliziert abzuschätzen ist, ist es besser, sie in verschiedene kleinere US zu unterteilen, um mehr Klarheit zu schaffen.
💡 Gut zu wissen: Man schätzt (oder schätzt erneut) die User Stories des kommenden oder eventuell des übernächsten Sprints, vermeidet es aber, weiter zu schätzen.
3. Priorisierung der Backlog-Items
Das Wissen um die Schätzung einer User Story wird es dem Team ermöglichen, mit der Priorisierung zu beginnen.
Allerdings können auch andere Kriterien für die Priorisierung eine Rolle spielen, insbesondere der funktionale Wert, der von entscheidender Bedeutung ist. Daher ist es einfallsreich, Prioritätsstufen nach dem Verhältnis von Wert und Aufwand für die Umsetzung festzulegen:
- Priorität 1 (P1): hoher fachlicher Wert und leicht zu entwickeln,
- Priorität 2 (P2): hoher fachlicher Wert und schwer zu entwickeln,
- Priorität 3 (P3): geringer fachlicher Wert und leicht zu entwickeln,
- Priorität 4 (P4): geringer Geschäftswert und schwer zu entwickeln.
Das Team weist den US also Prioritäten zu, wobei es stets im Hinterkopf behält, dass das Hauptziel darin besteht, so schnell wie möglich einen möglichst hohen Wert zu liefern.
💡 Gut zu wissen: Die Priorisierung kann für das gesamte Backlog erfolgen, auch wenn die US nicht alle vollständig sind, da wir uns auf einer makroökonomischeren Sichtweise befinden.
Letzte Tipps für eine effektive Backlog-Verfeinerung
- Tipp 1: Bereiten Sie sich als Product Owner gründlich auf die Präsentation der US vor, indem Sie dem Team Ihre Überlegungen detailliert schildern, was sie Ihrer Meinung nach bewirken können etc. Je enthusiastischer und klarer Sie sind, desto größer ist die Wahrscheinlichkeit, dass das Team Ihre Produktvision unterstützt und die US genehmigt.
- Tipp 2: Begrüßen Sie Fragen, Anmerkungen und negative Rückmeldungen. Sie werden sicher etwas Konstruktives finden, das Ihre Überlegungen und damit die US bereichert.
- Tipp 3: Warten Sie mit dem Backlog Refinement nicht bis zum letzten Moment und bis Sie alle Ihre US abgeschlossen haben. Es ist besser, die abgeschlossenen Stories regelmäßig in schnellen Backlog Refinements zu präsentieren, um vorauszusehen, ob sie bearbeitet werden müssen, da sonst der nächste Sprint gefährdet wird. Vermeiden Sie den Tunneleffekt!
Fallbeispiel für die Anwendung von Backlog Refinement in Unternehmen.
Stellen Sie sich ein Entwicklungsteam in einem Tech-Startup vor, das gerade dabei ist, seine Website zu überarbeiten. Der Product Owner hat gerade eine Flut von Nutzerfeedback erhalten: unübersichtliche Navigation, langsame Geschwindigkeit auf Mobilgeräten, mangelnde Zugänglichkeit.
Anstatt all diese Backlog-Elemente in der Sprintplanung durcheinander zu werfen, organisiert das Team eine eigene Backlog-Sitzung.
Bei der Backlog Refinement wird jede User Story auseinandergenommen:
- “Verbessern der mobilen Ladezeit”,
- “Ein Menü hinzufügen, das mit der Tastatur bedient werden kann”,
- “Die Baumstruktur der Startseite überarbeiten”.
Die Entwickler stellen Fragen, die UX-Designer schlagen Lösungen vor, der Product Owner erläutert die Ziele und formuliert bestimmte Bedürfnisse neu. Gemeinsam schätzen sie die Komplexität der ein und ordnen die Liste nach dem Geschäftswert neu.
Das Ergebnis: ein klarer Produkt-Backlog, gut kalibrierte PBIs und ein reibungsloser Start des nächsten Sprints. Noch besser: Das Scrum-Team hat an Zusammenhalt gewonnen … und an Gelassenheit.
Die Kunst, vorzubereiten, um besser zu liefern
Das backlog refinement ist nicht nur ein weiteres Treffen im Kalender. Es ist ein Schlüsselmoment, um :
- Abstand zu gewinnen,
- die richtigen Fragen zu stellen,
- ein solides Product Backlog aufzubauen.
Wenn Sie Ihre User Stories regelmäßig verfeinern, wird Ihr nächster Sprint flüssiger, Ihr Entwicklungsteam gelassener und Ihre Lieferungen berechenbarer. Kurz gesagt: Sie gehen in den agilen Modus mit einem großen A über.
