Das Backlog Refinement Meeting gehört zu einem der wichtigsten Meetings im Scrum Framework, ist gleichzeitig aber auch eines der unterschätztesten.
Warum ist das so? Weil es gleichzeitig eines der anstrengendsten Meetings für alle Beteiligten ist.
Wie kannst du als Product Owner oder Scrum Master dieses Meeting also zu deinem Vorteil nutzen? Das erfährst du in diesem Artikel.
Was ist ein Backlog Refinement Meeting?
Das Backlog Refinement, auch als Backlog Grooming bezeichnet, ist eine gemeinsame Tätigkeit von Product Owner und Entwicklungsteam .
Es dient dazu, Items aus dem Backlog, z.B. User Stories, Bugs oder Funktionale Anforderungen, auszuformulieren, zu ergänzen, zusammenzufassen oder auch zu entfernen.
Ziel ist es, ein gemeinsames Verständnis von dem umzusetzenden Item zu erhalten. Das bedeutet, dass jedem Teilnehmer klar ist:
Eine gängige Empfehlung ist es, nicht mehr als 10% der verfügbaren Sprintzeit für das Refinement einzusetzen. Im Scrum Guide wurde die 10% Regel inzwischen entfernt.
Hier kommt es natürlich auf die Rahmenbedingungen an. Ist das Thema oder das Team noch neu, dann werdet ihr sicherlich mehr Zeit einplanen müssen.
Kommt Routine in die Umsetzung und ist der fachliche Rahmen klar, kann es schneller gehen und es wird weniger Zeit benötigt.
Vorbereitung des Backlog Refinement Meetings
Damit das Meeting ein Erfolg wird, muss es gut vorbereitet werden. Dabei haben sowohl der Product Owner als auch das Team ihren Anteil.
Die wichtigste Aufgabe des Product Owners in Hinblick auf das Refinement Meeting, ist ein aufgeräumtes und priorisiertes Backlog.
Denn nur die wichtigsten und am höchsten Priorisierten Backlog Items sollten ins Refinement.
Warum? Weil diese in der Regel als nächstes umgesetzt werden. Und da wir in einer volatilen und schnelllebigen Welt agieren, ist eine Beschäftigung mit Themen, die morgen nicht mehr aktuell sind, Zeitverschwendung. Und da Zeit gleich Geld ist, kann damit auch jede Menge Geld verschwendet werden.
Jetzt geht es also ans aufräumen, auswählen und priorisieren.
Aufräumen des Backlogs
Bei einem Backlog verhält es sich wie mit einem Kleiderschrank. Nur in einem gut sortierten Schrank findest du die Sachen, die du willst. Es kommen ständig neue Sachen dazu. Es gibt Sachen, die du gern anziehst und die ganz oben liegen. Sachen gehen kaputt und fliegen aus dem Schrank raus.
Es gibt aber auch jede Menge Sachen, die aktuell nicht mehr passen, und welche du trotzdem behältst.
Warum? Weil du glaubst, dass du sie irgendwann wieder brauchen und tragen kannst.
Mit dem Backlog ist es genauso.
Es kommen viele Anforderungen von allen möglichen Seiten rein. Sie erscheinen am Anfang alle wichtig und umsetzungswürdig. Und sie müllen irgendwann das Backlog einfach zu.
Der große Unterschied zwischen Schrank und Backlog ist nämlich, dass der Schrank irgendwann voll ist. Ein digitales Backlog ist das nie.
Deshalb gilt es, regelmäßig auszumisten und die Menge der Backlog Items zu reduzieren.
Denn nur mit einem aufgeräumten und übersichtlichen Backlog kannst du effizient arbeiten.
Auswahl der Backlog Items
Nun gilt es eine Auswahl zu treffen, welche Backlog Einträge für das Refinement Meeting relevant sind. Hier kommt es immer auf den Kontext des Meetings an. Willst du genug Items für die nächsten 2 Sprints haben oder dir einen Gesamtüberblick über einen kompletten Release machen.
Um die richtigen Items auszuwählen, gibt es mehrere Methoden, die du einsetzen kannst.
#### MuSCoW – Must have, Should have , Could have, Won’t have
Die MuSCow Methode hat sich sowohl im agilen als auch im klassischen Projektmanagement etabliert. Diese Priorisierungsmethode kann gut in einer strategischen Priorisierung eingesetzt werden.
Sie untergliedert Anforderungen in 4 Bereiche:
Damit lässt sich eine einfach verständliche Einordnung der Backlog Items relativ einfach durchführen.
#### Thema-Methode
Die Thema Methode ist vor allem für die operative Vorauswahl anwendbar. Vor der eigentlichen Auswahl muss sich mit den Stakeholdern auf ein Thema, welches die nächsten X Wochen relevant ist, geeinigt werden.
Beispiel:
„Die Zeit, welcher ein Kunde durchschnittlich für unseren Onboarding Prozess benötigt, soll in den nächsten 6 Wochen halbiert werden.“
Alle Backlog Items, welche nun für den gesetzten Zeitraum ausgewählt werden, müssen auf dieses Thema einzahlen.
Priorisierung des Backlogs
Ein priorisiertes Backlog sorgt dafür, dass die wichtigsten und wertschöpfendsten Dinge zuerst oder als nächstes angegangen werden.
Über die Vorauswahl ist jetzt eine überschaubare Anzahl Backlog Items herauskristalisiert, welche es zu priorisieren gilt. Eine händelbare Anzahl liegt dabei zwischen 30 und 50 Items. Bei mehr Items wird es schwieriger, in der Priorisierung den Überblick zu behalten.
Folgende Methodiken können dich dabei unterstützen:
#### Business Value – Buy a feature
Die Buy-a-feature Methode ist eine einfach verständliche Priorisierungsmethode, welche gemeinsam mit den Stakeholdern, dem Management und dem Entwicklerteam durchgeführt werden kann.
Wichtig: Es muss im Vorfeld bereits eine erste Aufwandsschätzung durchgeführt werden, da jedes Item einen Preis hat. Hier bietet sich als schnelles Verfahren Magic Estimation an.
Das Vorgehen ist wie folgt:
Als Rahmenbedingungen für die Auswahl an Geldmenge und Backlog Items kannst du z.B. folgendes vorgeben:
#### Kriterienbasiert – Plus-Minus-Null- Liste
Plus-Minus Priorisierungsmethode
Die Plus-Minus-Priorisierung ist etwas aufwändiger in der Vorbereitung als auch Durchführung.
Im Vorfeld müssen sich Kriterien überlegt werden, welche relevant für eine Bewertung bzw. Priorisierung sind.
Beispiele:
Während der Priorisierung müssen alle zu priorisierenden Backlog Items dann bewertet werden.
Am Ende können dann alle Punkte zusammengerechnet werden. Danach kannst du an Hand der Gesamtbewertung eine Reihenfolge bestimmen.
#### Relatives Gewicht – Vorteil, Strafe, Risiko, Kosten
Bei der Relativen Gewichtungsmethode werden die Backlog Items in 4 Kategorieren bewertet
Die Bewertung erfolgt jeweils auf einer Skala von 1 bis 9.
Als Product Owner musst du die Backlog Items mit zwei Zielgruppen besprechen. Die Kategorien Vorteile und Strafe besprichst du mit den Stakeholdern oder Kunden, die Kategorien Risiko und Kosten mit dem Entwicklungsteam.
Danach werden die Punkte gegeneinander gewichtet.
Die Formel lautet
Gewichtung = ( Vorteil + Strafe ) / ( Risiko + Kosten)
#### Anwenderzentriert – Das Kano Modell
Das Kano Modell ist ein anwenderzentriertes Priorisierungsmodell. Es unterscheidet grundsätzlich in 5 Merkmale von Produkten:
1) Basismerkmale
Diese Merkmale sind Grundlage des Produkts und muss umgesetzt werden. Ohne diese Merkmale kann das Produkt nicht funktionieren.
Der Anwender merkt in der Regel erst bei Nichtvorhandensein, dass es ein grundlegendes Merkmal ist.
Werden diese Merkmale erfüllt, dann erzeugt mit damit keinen zusätzlichen Kundennutzen. Fehlen im Gegensatz dazu aber diese Merkmale, erhöht dies die Unzufriedenheit des Anwenders enorm.
2) Leistungsmerkmale
Leistungsmerkmale sind Produktmerkmale, welche der Kunde bewusst wahrnimmt. Entweder reduzieren sie seine Unzufriedenheit oder erhöhen seine Zufriedenheit. Dies ist abhängig vom Umfang der Erfüllung des Leistungsmerkmals.
3) Begeisterungsmerkmale
Begeisterungsmerkmale sind Merkmale, mit denen der Anwender nicht gerechnet hat. Sie fügen einen großen Mehrwert zum Gesamtprodukt hinzu und dienen zur Unterscheidung von der Konkurrenz. Fehlen diese Merkmale, so wirkt sich dies nicht negativ auf die Anwenderzufriedenheit aus.
4) Unerhebliche Merkmale
Diese Merkmale haben keinerlei Einfluss auf die Zufriedenheit des Anwenders.
5) Rückweisungsmerkmale
Das Vorhandensein dieser Merkmale führt zu einer Unzufriedenheit bis hin zur Ablehnung durch den Anwender. Sind diese Merkmale nicht vorhanden, führt dies dann eher zur Zufriedenheit.
Die Einschätzung der Backlog Items in die 5 Merkmale wird durch eine Befragung der Stakeholder erreicht. Du musst dabei aber beachten, dass diese Einschätzung sehr subjektiv sein kann.
Es gibt hierfür auch eine Online Variante, welche bei der Befragung unterstützt.
Für die Priorisierung bedeutet dies folgendes:
Ablauf des Backlog Refinement Meetings
Nachdem alle Voraussetzungen geschaffen sind – ein sortiertes und priorisiertes Backlog – kann das Refinement Meeting beginnen.
Aus meiner Erfahrung heraus kann ich ein wöchentlich bis zweiwöchentlich stattfindendes Meeting empfehlen. Es sollten maximal 2h anberaumt werden. Da diese Art Meeting für alle Teilnehmer sehr anstrengend ist, führen längere Meetings eher zu schlechteren Resultaten.
Zu Beginn des Meetings sollte der Product Owner die Zielstellung des Meetings klären.
Geht es beim Refinement um:
Je nach Zielstellung kann die Vorgehensweise und auch die angewendete Schätzmethode varieren.
Beispiel-Agenda
Folgende Agenda kann für ein Refinement genutzt werden:
Je Backlog Item – 15 min
Gesamtzeit: Maximal 2h
Der Scrum Master sollte in diesem Meeting sehr stark auf das Timeboxing achten. Sind die initialen 15min vorbei, dann sollte das Team gefragt werden, ob weiterdiskutiert werden soll oder nicht. Falls nicht, ist es die Aufforderung an den Product Owner, das entsprechende Backlog Item weiter aufzubereiten.
Schätzverfahren
Es gibt eine reihe verschiedener Schätzverfahren, welche auf die unterschiedlichsten Situationen passen. An dieser Stelle möchte ich die 2 verbreitetsten Verfahren vorstellen.
Als Schätzmaße können dabei:
genutzt werden.
Magic Estimation
Das Magic Estimation Verfahren ist ein ideale Methode, um eine schnelle Schätzung des Backlogs durchzuführen.
Die Methode eignet sich besonders für:
Die Technik ist auch deshalb so schnell, weil während des Schätzens nicht gesprochen werden darf. Somit kommt im ersten Teil keine zeitaufwändige Diskussion zustande.
Vorgehensweise
Das Vorgehen ist dabei wie folgt :
(es wird ein Präsenzworkshop beschrieben, die Online Variante kann davon aber einfach abgeleitet werden)
Phase 1 – Initiales Platzieren der Backlog Items – keine verbale Kommunikation zwischen den Teammitgliedern
Phase 2 – Diskussion zu den uneindeutigen Backlog Items
Zeitlicher Aufwand
Magic Estimation spielt seine Vorteile bei der ersten Schätzung einer großen Anzahl von Backlog Items aus. Deshalb sollten ca. 2h für das Meeting eingeplant werden.
Eine detaillierte Beschreibung der Methode kannst du in diesem Artikel finden.
Planning Poker
Beim Planning Poker geht es darum, den Aufwand einzelner Backlog Items detailliert zu schätzen. Es eignet sich vor allem bei der Schätzung des kommenden Sprints oder für eine eingeschränkte Anzahl an Stories.
Vorgehensweise
Das Vorgehen ist dabei wie folgt:
Zeitlicher Aufwand
Das Planning Poker Verfahren ist eine aufwendige Methodik. Vor allem das Vorstellen des Backlog Items und die mögliche Diskussion bei abweichenden Schätzungen erhöhen den Zeitaufwand.
Deshalb sollte der Scrum Master hier sehr stark auf das Timeboxing achten. Es bietet sich an, pro Backlog Item initial nicht mehr als 15min anzusetzen.
Tools und Hilfsmittel
Für das Planning Poker in einem Vor-Ort Meeting bieten sich Planning Poker Karten an. Diese kann jeder verdeckt vor sich haben und in Ruhe aussuchen.
Die Vergleichstabelle konnte nicht ausgegeben werden.
Für Online Meetings kann man diese ebenfalls nutzen, dann sollten alle Teilnehmer ihre Kamera aktiviert haben.
Ein nützliches Online Planning Poker kannst du auf scrumpoker-online.org finden. Hier kannst du kostenlos einen Raum erstellen und ein gemeinsames Planning Poker durchführen.
Nachbereitung des Meetings
Die Nachbereitung des Meetings ist in der Regel Sache des Product Owners.
Folgende Aufgaben gilt es im Nachhinein zu bearbeiten:
Wichtig ist, dass der Product Owner die Aufgaben zeitnahe wahrnimmt.
Änderungen im Release und in der Reihenfolge müssen ggf. mit den Stakeholdern besprochen werden.
Die Fragen und Einwände des Teams sollten ebenfalls bis zum folgenden Refinement geklärt werden.
Tipps für ein gutes Backlog Refinement
Zum Weiterlesen: