Was ist Product Backlog Refinement?
Scrum Teams machen es ständig. Es passiert im Sprint Review, nach dem Daily Scrum, im Sprint Planning und als Teil der Entwicklung. Sie diskutieren über die bevorstehende Arbeit, um sie zu präzisieren. Präzisieren umfasst:
- die Ergebnisse und Inhalte ihrer Arbeit klären
- die Arbeit zerkleinern und aufteilen, sodass die Einzelstücke nach Fertigstellung noch Wert für den Nutzer liefern
- die Arbeit im Backlog anordnen, sodass die Ziele des Scrum Teams und der Organisation bestmöglich erreicht werden
- neue Arbeiten, die am Produkt getan werden müssen, zum Backlog hinzufügen und überflüssige Arbeiten entfernen
- mögliche Abhängigkeiten zu anderen Teams oder innerhalb der Arbeit auflösen
- die Arbeit in ihrem Umfang und Wert schätzen
- technische Fragen zur Umsetzbarkeit der Arbeit untersuchen
- die Arbeit als Vermutungen begreifen
Es dreht sich also alles um zukünftige Arbeiten im Product Backlog, ausgedrückt als Product-Backlog-Einträge. Diese Einträge bezeichnet Barry Overeem als Erinnerungen an Gespräche, die in der Zukunft noch geführt werden müssen. Das Refinement ist einfach die fortlaufende Aktivität, diese Gespräche zu führen, und somit eine essentielle Product-Management-Aktivität.
Wozu ist das Product Backlog Refinement wichtig?
In Gesprächen werden Product-Backlog-Einträge präzisiert und zerkleinert, bis sich ein gemeinsames Verständnis für die Arbeit einstellt. Dies geschieht so lange, bis sich das Scrum Team ziemlich sicher ist, dass sie die anfallende Arbeit innerhalb eines Sprints abschließen kann. Dadurch erreicht das Product Backlog einen Transparenzgrad, welcher das Risiko verringert, am Ende des Sprints mit der Arbeit nicht fertig zu werden. Wird ein Product-Backlog-Eintrag nicht fertig, verschenkt ein Scrum Team die Möglichkeit, neuen Wert für die Organisation zu generieren. Deshalb ist das Refinement eine essentielle Product Management Aktivität, welche erfolgreiche Scrum Teams beherrschen.
Beim Refinement werden die Element im Product Backlog betrachtet, die weiter nach oben wandern. Scrum Teams wissen, dass es effizient ist, nur die oberen Elemente im Product Backlog zu präzisieren. Sie werden zwangsläufig Dinge lernen, die ihre Ansichten über Elemente weiter unten ändern oder überflüssig machen. Um das nicht aus den Augen zu verlieren, hilft die Daumenregel, dass jeder Developer nur 10 % ihrer Zeit dafür verwenden sollten.
5 Konkrete Strategien für Product Backlog Refinement
Obwohl Refinement eine essentielle Product-Management-Aktivität ist, verwenden laut dem Scrum Zombie Guide 43 % der Scrum Teams im aktuellen Sprint keine Zeit, um die Arbeit für kommende Sprints zu verfeinern. Deshalb werden im Folgenden 5 konkrete Strategien für Product Backlog Refinement vorgestellt:
- Gewinnen neuer Erkenntnisse
- Ordnen des Product Backlogs
- Schätzen von Product-Backlog-Einträgen
- Zerkleinern von Product-Backlog-Einträgen
- Auflösen von Abhängigkeiten
Diese helfen Scrum Teams und dessen Stakeholder, Gespräche zu führen und damit die Einträge im Product Backlog zu präzisieren.
Strategie 1: Gewinnen neuer Erkenntnisse
Scrum Teams erlangen ein Verständnis der Arbeit, wenn sie gemeinsam mit ihren Stakeholdern neue Erkenntnisse darüber gewinnen.
Hypothesen-Canvas
In der Produktentwicklung ist mehr unbekannt als bekannt. Kunden ändern ihre Meinung und Technologien ändern sich. Die Gewohnheit, diese Komplexität mit festen Vorhersagen und detaillierten Plänen beherrschen zu wollen, existiert leider noch in vielen Organisationen, sogar in denen, die Scrum verwenden. Wenn Scrum Teams Produktbedürfnisse, Kundenverhalten und Produkt-Markt-Fit erraten sollen, sind sie oft zum Scheitern verurteilt.
Der Schlüssel zum umdenken ist, Scrum Teams als Problemlösungs-Teams zu sehen und nicht als Feature-Lieferfabriken. Erfolgreiche Scrum Teams beginnen nicht damit, Features und Funktionen zu implementieren, sondern damit, über die Probleme des Kunden nachzudenken und Vermutungen über Lösungen aufzustellen. Das Hypothesen-Canvas, basierend auf dem Lean UX Canvas von Jeff Gothelf ermöglicht das und ermutigt Scrum Teams zur kreativen Erkundung von Problemstellungen.
Wir glauben, dass wir Fortschritt bei der Erreichung des [Produkt-Ziels] machen, wenn [Benutzer] mit [Funktion] das [Ergebnis] erzielen.
Die Idee ist, dass Scrum Teams und deren Stakeholder ihre Ideen nicht als Anforderungen begreifen, sondern als ihre besten Vermutungen darüber, wie sie Wert liefern können. Mit klaren Erfolgskriterien, welche ihnen sagen, welches Ergebnis der Benutzer durch die Verwendung der zu implementierenden Funktion erreicht und welche Auswirkung das auf die Erreichung des Produkt-Ziel hat.
Im Refinement erarbeiten Scrum Teams gemeinsam mit ihren Stakeholdern diese Hypothesen und halten sie als Einträge im Product Backlog fest.
UX Fishbowl
Ein User Experience (UX) Fishbowl ist eine Liberating Structure, welche es ermöglicht, zu erforschen, wie die Umsetzung von Product-Backlog-Einträgen aus der Perspektive der Stakeholder aussehen würde und was diese für sie ermöglicht. Ein UX Fishbowl besteht aus zwei Gruppen und zwei Schritten, eine Gruppe bilden die Stakeholder und eine das Scrum Team. Die Schritte können nacheinander beliebig oft ausgeführt werden.
- Die Stakeholder werden eingeladen, folgende Fragen zu diskutieren. "Stellen Sie sich vor, diese Funktionalität wäre bereits Teil des Produkts. Wie, wann und warum würden Sie sie verwenden? Welche Schritte sind damit verbunden? Was macht es für Sie nützlich? Was könnte Sie abschrecken?" Das Scrum Team hört aufmerksam zu und notiert wichtige Einsichten.
- Das Scrum Team kommt zusammen und formuliert weiterführende Fragen, basierend auf dem, was sie gehört haben. Diese Fragen dienen als Fragen für die nächste Runde.
Dieser UX Fishbowl eröffnet Scrum Teams Möglichkeiten, große Product-Backlog-Einträge in kleinere zu zerlegen, welche noch wertvoll für Stakeholder sind.
Strategie 2: Ordnen des Product Backlogs
Product Owner wissen, dass das Ordnen des Product Backlogs nichts ist, was sie allein tun sollten. Wenn Scrum Teams die Ordnung gemeinsam mit den Stakeholder herstellen, gewinnen sie neue Einsichten, was wertvoll für das Produkt sein kann.
Buy a Feature
Um herauszufinden, welche Produkt-Backlog-Einträge wichtig sind, ist es hilfreich, die Stakeholder, die von der Umsetzung profitieren, miteinzubeziehen. Buy a Feature von Innovation Games ermöglicht das folgendermaßen:
- Die Product-Backlog-Einträge, die zum Kauf bereitstehen, werden mit einem Preis versehen und zu einer Liste zusammengefasst.
- Das Geld wird gleichmäßig unter den Stakeholdern aufgeteilt.
- Die Stakeholder kaufen die Product-Backlog-Einträge, welche am wichtigsten für sie sind. Jeder Eintrag kann einmal gekauft werden. Die Stakeholder können beim Kauf ihr Geld zusammenlegen.
- Wenn das Geld ausgeben ist, spiegeln die gekauften Einträge der Liste wider, welche Product-Backlog-Einträge den Stakeholdern gemeinschaftlich wichtig sind.
Damit die Stakeholder kollaborieren müssen, sollten die Stakeholder insgesamt nur so viel Geld bekommen, dass sie nur die Hälfte der Product-Backlog-Einträge kaufen können und einige Einträge sollten so teuer sein, dass kein Stakeholder sie allein erstehen kann.
20/20 Vision
Eine 20/20 Vision zu haben, bedeutet, perfekt zu sehen, ohne eine Brille oder Kontaktlinsen tragen zu müssen. Scrum Teams hilft diese Fähigkeit, die Ordnung des Product Backlogs perfekt aus den Augen ihrer Stakeholder zu sehen. Sie gehen dazu wie folgt vor:
- Jeder Eintrag des Product Backlogs ist eine eigene Karte.
- Die Karten werden gemischt und ein verdeckter Stapel gebildet.
- Die oberste Karte dient als Referenz und wird umgedreht neben dem Stapel platziert.
- Wenn die nächste Karte aufgedeckt wird, entscheiden die Stakeholder, ob sie ihnen wichtiger oder weniger wichtiger ist, und platzieren sie entsprechend oberhalb oder unterhalb der Referenzkarte.
- Das Eingruppieren der verbleibenden Karten in die neue Liste wird bis zur letzten Karte des Stapels wiederholt. Es entsteht eine 20/20 Vision der Ordnung des Product Backlogs, welche zeigt, was den Stakeholdern wichtig ist.
Strategie 3: Schätzen von Product-Backlog-Einträgen
Ziel beim Schätzen ist es, ein gemeinsames Verständnis über die Arbeit im Product Backlog zu erlangen und nicht absolute Sicherheit über den anfallenden Umsetzungsaufwand. Scrum Teams schätzen die Product-Backlog-Einträge, indem die Developer ihnen eine Größenwert zu ordnen. Die Größe drückt dabei nicht die absolute Größe des Product-Backlog-Eintrags aus, sondern die Größe in Relation zu den anderen Einträgen. Scrum Teams bedienen sich relativer Größen, da Menschen Relationen leichter bestimmen können.
Magic Estimation
Durch Magic Estimation ist es Scrum Teams möglich, eine Product Backlog in so kurzer Zeit zu schätzen, dass es wie Magie erscheint. Folgende Schritte sind dazu nötig:
- Die Zahlen 1,2,3,5,8,13,21,? der Fibonaccireihe bis 21, ergänzt durch ein Fragezeichen, bilden mögliche Größenwerte.
- Ein Product-Backlog-Eintrag wird gemeinschaftlich einer Größe zugeordnet und dient als Referenz für die Zuordnung der restlichen Einträge.
- Die verbleibenden Product-Backlog-Einträge werden unter den Developern verteilt.
- Die Developer ordnen jedem ihrer Product-Backlog-Einträge eine entsprechende Größe in Relation zum Referenzeintrag zu. Verstehen sie einen Eintrag nicht, wird ihm das Fragezeichen zugeordnet. Während des Zuordnens sprechen sie sich nicht mit den anderen Beteiligten ab.
- Nachdem alle Product-Backlog-Einträge zugeordnet wurden, schauen sie sich die Zuordnungen der anderen an und ordnen ihnen eine neue Größe zu, falls sie bei der Wahl der zugeordneten Größe nicht übereinstimmen.
- Lässt sich einem Product-Backlog-Eintrag keine eindeutiger Größenwert zuordnen, wird ihm der größere der beiden Werten zugeordnet. Wurde einem Eintrag ein Fragezeichen zugeordnet, bedarf es weiterer Klärung unter Hinzunahme des Product Owners, bis ihm eine eindeutige Größe zugeordnet werden kann.
Das Result ist ein in Relation zum Referenzeintrag geschätzter Product Backlog.
Planning Poker
Planning Poker, welches auf James Glenning zurückgeht, hilft Scrum Teams, Product-Backlog-Einträge zu verstehen und ein gemeinsames Verständnis über dessen Größe zu erlangen. Das Vorbild ist eine Pokerrunde. Konkret wird wie folgt vorgegangen:
- Der Product Owner nennt den zu schätzenden Eintrag im Product Backlog und erklärt diesen bei Bedarf.
- Jeder Developer schätzt individuell den Eintrag, indem er ihm eine Größe zuordnet. Seine Wahl bleibt so lange verdeckt, bis alle geschätzt haben. Danach zeigen alle beteiligten Developer gleichzeitig ihre Wahl.
- Gibt es keine Übereinstimmung in der Größe für den Product-Backlog-Eintrag, so diskutieren Developer mit den höchsten und niedrigsten Schätzungen ihre Wahlen. Danach wird dieser Eintrag nochmals von allen geschätzt (Schritt 2). Dieser Schritt wird so lange wiederholt, bis eine Einigung erzielt wird. Diese Einigung spiegelt das gemeinsames Verständnis über den Product-Backlog-Eintrag wider.
Als Größen eignen sich Finger, Gummibärchen, T-Shirtgrößen oder halt die ersten Zahlen Fibonacchi-Reihe.
Strategie 4: Zerkleinern von Product-Backlog-Einträgen
Scrum Team zerkleinern Product-Backlog-Einträge, sodass die Umsetzung jedes Eintrags eigenständig nutzbar ist und Wert für den Nutzer stiften kann. Die Arbeit wird vertikal zur Wertschöpfung aufgeteilt. Eine horizontale Zerkleinerung findet erst im Sprint Planning statt, wenn Developer den Plan erstellen, wie ein Product-Backlog-Eintrag umgesetzt wird.
Product-Backlog-Einträge nach Workflowschritten zerkleinern
Beinhalten Product-Backlog-Einträge einen Arbeitsablauf, können diese in einzelne Schritte zerlegt werden.
Der Eintrag, welcher beschreibt, dass ein Kunde die Waren in seinem Warenkorb bezahlen kann, lässt sich in folgenden Einträge aufteilen:
- Als Kunde kann ich mich mit meinem Konto anmelden.
- Als Kunde kann ich meine Bestellung bezahlen.
- Als Kunde erhalte ich eine Bestätigungs-E-Mail mit meiner Bestellung.
Product-Backlog-Einträge nach Happy- und Unhappy-Pfad zerkleinern
Funktionalität beinhaltet häufig einen Happy-Pfad und einen oder mehrere Unhappy-Pfade. Der Happy-Pfad beschreibt, wie sich die Funktionalität verhält, wenn alles wie gewünscht verläuft. Gibt es Abweichungen, Ausnahmen oder andere Probleme, wird der Unhappy-Pfad aufgerufen.
Der Product-Backlog-Eintrag, welcher beschreibt, dass sich der Kunde mit seinem Konto anmelden kann, kann so in zwei Teile aufgeteilt werden.
- Als Kunde kann ich mich mit meinem Konto anmelden. Dies beschreibt der Happy-Pfad.
- Als Kunde kann ich mein Passwort zurücksetzten, wenn die Anmeldung fehlschlägt. Dies beschreibt der Unhappy-Pfad.
Weitere Möglichkeiten sind hier übersichtlich dargestellt.
Strategie 5: Auflösen von Abhängigkeiten
Obwohl Scrum Teams interdisziplinär sind, arbeiten sie doch in einem komplexen Umfeld, welches dazu führt, dass unbekannte Abhängigkeiten auftreten. Abhängigkeiten behindern Product Owner, das Product Backlog nach maximalem Wert zu ordnen, erhöhen das Risiko von Verzögerungen und können dazu führen, das Scrum Teams am Ende des Sprints kein nutzbares Inkrement erzeugen.
Es gibt eine Vielzahl von Abhängigkeiten:
Interne Abhängigkeiten: Product-Backlog-Einträge hängen voneinander ab. Beispielsweise, wenn Workflowschritte aufeinander aufbauen, wenn bestimmte Product-Backlog-Einträge Bestandteile eines Release sein müssen, oder wenn Product-Backlog-Einträge zusammenhängend einen größeren Nutzen liefern.
Externe Abhängigkeiten: Product-Backlog-Einträge hängen von externen Faktoren ab. Die Einträge können von Geschäftsprozessen wie Freigabeprozessen oder Einkaufsprozessen abhängen. Sie können von Fremdsystemen abhängen, wenn die Arbeit technische Änderungen in einem Bereich des Systems erfordert, der außerhalb der Kontrolle des Scrum Teams liegt. Oder es wird die Expertise oder Unterstützung einer Person mit spezifischem Wissen benötigt.
Scrum Teams machen Abhängigkeiten im Product Backlog frühzeitig sichtbar, um sie aufzulösen. Sie gehen dabei wie folgt vor.
Nach Identifikation der Abhängigkeiten werden die Product-Backlog-Einträge mit Pfeilen so markiert, dass ersichtlich wird, wie die Einträge voneinander oder von externen Faktoren abhängen. Nachdem alle Abhängigkeiten im Product Backlog sichtbar gemacht sind, ergibt sich ein Graph, welcher Einsichten in die mögliche Abarbeitungsreihenfolge liefert. Diese Einsichten ermöglichen dem Scrum Team, Abhängigkeiten aufzulösen, indem sie Product-Backlog-Einträge zerkleinern, neue technische Lösungswege suchen, die ohne Fremdsystem auskommen, oder sich im Team fehlendes Wissen aneignen.
Product Backlog Refinement ist essenziell
Neue Erkenntnisse für die anstehende Arbeit zu gewinnen, diese im Backlog anzuordnen, zu schätzen, zu zerkleinern und bestehende Abhängigkeiten aufzulösen, hilft Scrum Teams und deren Stakeholdern fortlaufend, die Arbeit zu präzisieren, um ein gemeinsames Verständnis herzustellen. In Scrum wird diese Product-Management-Aktivität als Product Backlog Refinement bezeichnet. Sie ist essenziell, denn sie verringert das Risiko, am Ende des Sprint mit der Arbeit nicht fertig zu werden.
Möchtest Du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für Dich. Wie man das Refinement durchführt, ist eines der vielen interessanten Themen, die in meinen Professional Scrum Trainings behandelt werden.
Wenn du keinen neuen Beitrag mehr verpassen willst, dann abonniere meinen Newsletter, dort wirst du als Erster über neue Beiträge informiert.
👉 Hier geht zur Anmeldung.