Mit Best Practices für das Product Backlog Refinement sicher ans Ziel

Für die Beschreibung des Product Backlog in einem Scrum Prozess wird oftmals die Analogie eines Eisbergs herangezogen. Wie bei einem Eisberg ist das wahre Ausmaß oftmals nicht direkt oder nur sehr schwer ersichtlich, insbesondere zu Beginn eines agilen Projekts. Schätzungen des Umfangs des gesamten Backlogs und einzelner Einträge sind ungenau, Anforderungen nicht hinreichend konkretisiert, Einträge nicht priorisiert oder zu groß für einen Sprint. All diese Faktoren werden das Scrum Team auf dem Weg zum Ziel mindestens in sehr unruhiges Fahrwasser, wenn nicht sogar gänzlich zum Sinken bringen. Mit dem Product Backlog Refinement bietet Scrum das passende Werkzeug, um dem Eisberg "Product Backlog" sicher zu begegnen.

In diesem Beitrag wird über Backlog Refinement informiert, indem dessen Notwendigkeit hergeleitet und das Prinzip dahinter erklärt wird. Für alle Anwender:innen von Scrum, insbesondere jedoch für Scrum Master:innen, werden Best Practices beschrieben. 

Product Backlog Refinement im Scrum Guide

Das Product Backlog Refinement hat das Ziel, das Product Backlog bzw. die dort enthaltenen Product-Backlog-Einträge für deren Erledigung im Sprint vor- bzw. aufzubereiten. Doch wie genau läuft das Product Backlog Refinement ab? Welche Parameter sind für die Product Backlog Einträge zu definieren? Wie genau ist der Prozess des Backlog Refinements durchzuführen? Wer ist dafür verantwortlich und wer beteiligt? Warum ist Backlog Refinement überhaupt notwendig? Bevor man mit dem Backlog Refinement startet, sollten mindestens diese Fragen für alle Beteiligten geklärt sein. Ein Blick in den Scrum Guide hilft an dieser Stelle nur bedingt weiter: Das Product Backlog Refinement ist kein "offizielles" Scrum Event wie z.B. das Daily Scrum, Sprint Planning, Sprint Review oder die Sprint Retrospektive. Die Beschreibung des Backlog Refinement ist im Scrum Guide (2020) daher auch recht kurz und generisch gehalten.

Das Backlog Refinement wird beschrieben als eine kontinuierliche Aktivität in der Product Backlog Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden, indem u.a. Beschreibung, Reihenfolge und Größe ergänzt werden. Ziel ist dabei, dass die Product-Backlog-Einträge am Ende des Refinement-Prozesses innerhalb eines Sprints durch das Scrum Team erledigt werden können. Das Backlog Refinement wird von den Developer:innen mit Unterstützung durch den:die Product Owner:in und deren Verantwortung für das Product Backlog durchgeführt (vgl. Scrum Guide 2020).

Grundidee Backlog Refinement

Wenn der Eisberg das gesamte Product Backlog darstellt, so repräsentiert die Spitze des Eisbergs diejenigen Backlog Einträge, die hinsichtlich Anforderung, Aufwand, Priorität und Beschreibung schon recht genau definiert sind. Aufgrund der bereits bekannten Informationen kann das Team diese Backlog Einträge gut im nächsten Sprint erledigen. Das Backlog wird in der Regel aber auch noch weitere Einträge enthalten, die (noch) nicht hinreichend konkretisiert und deren Umfang somit nur schwer zu schätzen ist. Möglicherweise gibt es zusätzlich noch einen Teil des Eisbergs, dessen Existenz zum aktuellen Zeitpunkt gar nicht bekannt ist: Das Product Backlog ist in der Regel nicht fix, d.h. während des Projekts können weitere Einträge hinzugefügt, verändert oder entfernt werden.

Backlog Refinement beschreibt nun den Prozess, während jedes Sprints, ein Stück vom Eisberg über die Wasseroberfläche zu holen, indem die für die Bearbeitung im Sprint notwendigen Parameter der Backlog Einträge erhoben werden. Weiter gilt es, die Backlog Einträge auf die passende Größe herunterzubrechen, sodass jeder Eintrag (idealerweise von einer Person) innerhalb eines Sprints umgesetzt werden kann. Der Refinement Prozess für einen Backlog Eintrag ist erst dann abgeschlossen, wenn aus Sicht des Development Teams alle notwendigen Informationen vorliegen, um den entsprechenden Backlog Eintrag im Sprint bearbeiten (und natürlich abschließen) zu können. Eine zu Beginn komplexe und daher scheinbar unlösbare Problemstellung kann auf diese Art und Weise Stück für Stück bearbeitet und entsprechend aufgelöst werden.

Best-Practices für Backlog Refinement

In der Praxis hat sich folgende Umsetzung des Backlog Refinement als hilfreich erwiesen:

Frequenz

Das Backlog Refinement wird kontinuierlich während des Sprints durchgeführt. Als Faustregel gilt, dass das Backlog Refinement höchstens 10 Prozent der gesamten Arbeitszeit pro Sprint einnehmen sollte. Ein oder mehrere fixe Termine im Teamkalender stellen sicher, dass in jedem Sprint ausreichend Zeit für Backlog Refinement eingeplant wird. Zudem reduzieren in regelmäßigen Abständen zur selben Zeit am selben Ort stattfindende Termine den Planungsaufwand für alle Beteiligten (gilt für alle Scrum Events). Gerade zu Beginn eines agilen Projekts sollte für das Backlog Refinement etwas mehr Zeit eingeplant werden. Mit zunehmendem Projektfortschritt wird sich sowohl die Zusammenarbeit des Development Teams mit dem:der Product Owner:in als auch der Reifegrad der einzelnen Einträge im Backlog verbessern, sodass Frequenz und Umfang angepasst werden können. Das Backlog Refinement sollte jedoch weiterhin kontinuierlich im Sprint stattfinden, um einen stetigen Nachschub an für die Umsetzung bereiten Backlog Einträgen sicherzustellen. 

Moderation

Inhaltlich ist das Backlog Refinement ein Zusammenspiel aus Product Owner:in mit der Verantwortlichkeit für das Product Backlog und dem Development Team, welches die Einträge in Sprints umsetzt. Eine Moderation, z.B. durch eine:n Scrum Master:in ist jedoch insbesondere zu Beginn sehr hilfreich. Ein:e Moderator:in sorgt dafür, dass das Meeting effizient abläuft, Timeboxen eingehalten werden, die Teilnehmer:innen fokussiert bleiben und so das Ziel nicht aus den Augen verlieren. In der Rolle als Coach und Mentor:in für Product Owner:innen und Development Team und hilft der:die Scrum Master:in den Beteiligten aber auch zur Selbstorganisation, sodass eine Moderation langfristig nicht mehr nötig ist. 

Ablaufplan

Die ersten Termine sollten dafür genutzt werden, mit dem gesamten Scrum Team einen Ablaufplan für das Backlog Refinement Meeting zu erarbeiten. Dies bedeutet initial zwar zusätzlichen Aufwand, reduziert aber die Komplexität in zukünftigen Terminen. Zum besseren Verständnis und um das Commitment des Teams auf den erarbeiteten Prozess zu stärken, bietet es sich an, den erarbeiteten Prozess zu dokumentieren. Dazu eignet sich bspw. ein Prozessmodell oder einer Checkliste. Anhand dessen kann man später regelmäßig überprüfen, ob der initial erdachte Prozess tatsächlich gelebt wird. Dies bedeutet jedoch nicht, dass der Prozess in Stein gemeißelt ist. Ganz im Gegenteil: Kontinuierliche Verbesserung ist eines der Kernmerkmale des agilen Vorgehens. Die zum Ende des Sprints stattfindende Retrospektive ist ein geeigneter Ort für das Team, das Vorgehen beim Backlog Refinement regelmäßig kritisch zu hinterfragen und gegebenenfalls Verbesserungen zu identifizieren deren Umsetzung zu beschließen. 

Definition of Ready

Analog zur Definition of Done (Welche Anforderungen muss ein im Sprint erstelltes Inkrement erfüllen, um als "fertig" zu gelten?), ist es sinnvoll, das sich das Development Team und der:die Product Owner:in auf eine Definition of Ready einigen. Dies sind vorher festgelegte, allgemeingültige Parameter, die jeder Backlog-Eintrag erfüllen muss bevor er im Sprintplanning für einen Sprint eingeplant werden kann. Gleichzeitig wird durch eine Definition of Ready das Ziel des Backlog Refinements konkretisiert. Für die Beschreibung des Product Backlog wird häufig das Akronym DEEP genutzt:

• Detailed Appropriately - Einträge in das Product Backlog sind angemessen detailliert
• Estimated - Einträge in das Product Backlog wurden einer Aufwandsschätzung unterzogen
• Emergent - Einträge in das Product Backlog sind dynamisch und können sich entsprechend verändern
• Prioritised - Einträge in das Product Backlog sind (gegeneinander) priorisiert

In Anlehnung an die DEEP-Kriterien für Product Backlog Einträge sollte eine minimale Definition of Ready folgende Bestandteile enthalten:

• Der Aufwand ist geschätzt.
• Der Backlog Eintrag hat die richtige Größe bzw. ist klein genug geschnitten, d.h. Aufwand ist kleiner gleich Anzahl der von einer Person in einem Sprint umsetzbaren Story-Points.
• Die Anforderungen sind hinreichend konkret bzw. User-Story ist ausformuliert.
• Das User-Story-Format ist eingehalten.
• Die Akzeptanzkritierien sind definiert.
• Der Backlog Eintrag ist priorisiert.

Etwas detailliertere Anforderungen an ein Product Backlog Eintrag stellen die sogenannten INVEST-Kriterien. 

Inhalt

Um die Definition of Ready als Ziel des Backlog Refinements zu erreichen, kann das Backlog Refinement Meeting folgende Inhalte haben:

• Development Team: Schätzung des Aufwands der Product-Backlog-Einträge, z.B. mit Planning Poker
• Product Owner:in nach Rückfragen durch das Development Team: Inhaltliche Klärung und ggf. Detaillierung der Product Backlog Einträge bzw. der Anforderungen
• Product Owner:in mit Unterstützung des Development Teams: Product Backlog Einträge bei Bedarf kleiner schneiden
• Product Owner:in kann Backlog Einträge priorisieren, Aufgrund neuer Erkenntnisse bzw. nach Änderungen der Anforderungen kann die Priorisierung entsprechend angepasst werden oder Einträge neu hinzugefügt bzw. komplett entfernt werden

Sensibilisierung für die Notwendigkeit von Backlog Refinement

Backlog Einträge, die im Sprint bearbeitet werden und anschließend als fertiges Inkrement an den Kunden ausgeliefert werden, schaffen direkt und unmittelbar Nutzen beim Kunden. Der Nutzen des für Backlog Refinement betriebenen Aufwands ist hingegen nie unmittelbar, sondern immer indirekt, mit Verzögerung in nachgelagerten Sprints bemerkbar. Weiterhin ist dieser Nutzen nicht notwendigerweise dem Kunden gegenüber nach Außen hin sichtbar oder messbar, sondern oftmals lediglich intern für das Scrum Team. Hier gilt es bei allen, unmittelbar und mittelbar Beteiligten, eine Sensibilisierung für Notwendigkeit und den Nutzen von Backlog Refinement zu schaffen.

Scrum Master:innen wirken nicht nur nach innen auf das Team ein, sondern auch nach außen, indem sie Hindernisse für das Team beseitigen und bei Stakeholder:innen innerhalb der Organisation, wie z.B. dem Management, Verständnis für die Scrum-Theorie und die entsprechende Umsetzung schaffen. Im Zuge dieser Tätigkeiten gehört auch eine Sensibilisierung aller Stakeholder:innen für die Notwendigkeit von Backlog Refinement zu den Aufgaben des Scrum Masters bzw. der Scrum Masterin.

Fazit: Die Bedeutung des Backlog Refinement ist groß

Backlog Refinement wird, evtl. auch bedingt durch die weniger prominente Darstellung im Scrum  Guide, oftmals vernachlässigt und in seiner Relevanz für einen effektiven Gesamtprozess unterschätzt. Wird es korrekt umgesetzt, führt es zu einem Product Backlog, welches hinsichtlich Inhalt, Aufwandsschätzung und Priorisierung immer aktuell ist und allen aufgezeigten Vorteilen, die damit einhergehen. Die Gefahr durch den Eisberg "Product Backlog" wird gebannt, indem dieser Stück für Stück, Sprint für Sprint aufgelöst und somit für das Scrum Team ein großes Hindernis auf dem Weg zum Projekterfolg beseitigt wird.

Unsere Lösungen und Angebote im Bereich Agilität & Scrum finden sie im Bereich Agile Methoden.