Das Backlog Refinement Meeting effizient durchführen

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:

• was umgesetzt werden soll,
• was nicht umgesetzt werden soll,
• was die Rahmenbedinungen und
• was die Akzeptanzkriterien sind

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.

• Lösche Einträge, die längere Zeit (z.B. 6-12 Monate) nicht mehr betrachtet wurden. Ist die Anforderung relevant, kommt sie irgendwann wieder neu rein
• Fasse Einträge zusammen, die Inhaltlich ähnliche Dinge tun. Du kannst sie später immer noch aufteilen.
• Finde Dopplungen und lösche die Kopie
• Finde widersprüchliche Anforderungen und entscheide dich für eine Variante. Lösche die andere Variante.

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:

• Must have
• Should have
• Could have und
• Won’t have

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:

• jeder Teilnehmer erhält einen fiktiven Geldbetrag (z.B. 1000 Euro)
• jedes Backlog Item hat einen Preis
• es darf auch gemeinsam auf Backlog Items eingezahlt werden
• wurde der Preis für ein Item erreicht, gilt es als gekauft

Als Rahmenbedingungen für die Auswahl an Geldmenge und Backlog Items kannst du z.B. folgendes vorgeben:

• die Geldmenge entspricht der durchschnittlichen Storiepoints eines Sprints im Team
• die Anzahl der Backlog Items ist etwa doppelt so groß wie die durchschnittliche Zahl der in vorangegangenen Sprints umgesetzten Stories
• es gibt Stories, die nicht von einer Person allein gekauft werden können.

Kriterienbasiert – Plus-Minus-Null- Liste

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:

• Umsetzungskomplexität
• Wettbewerbsvorteil
• Wettbewerberfeature
• Klarheit der Anforderung
• Mehrwert für den Kunden

Während der Priorisierung müssen alle zu priorisierenden Backlog Items dann bewertet werden.

• Positiv – das Item hat einen positiven Effekt auf das Kriterium
• Negativ – das Item hat einen negativen Effekt auf das Kriterium
• 0 – das Item hat keinen Effekt auf das Kriterium

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

• Vorteil: Wie hoch ist der Wert, wenn das Item in der Anwendung existiert
• Strafe: Wie hoch ist der Nachteil, wenn das Item nicht in der Anwendung existiert
• Risiko: Wie hoch sind die technischen Risiken und Abhängigkeiten einer Umsetzung
• Kosten: Wie hoch ist der Aufwand in der Umsetzung dieses Items

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:

• Basismerkmale haben die höchste Priorität
• Leistungs und Begeisterungsmerkmale sollten an Hand ihres Aufwandes als nächstes Priorisiert werden
• Backlogitems, welche als unerheblich oder Rückweisend eingestuft werden, sollten möglichst entfernt werden

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:

• die Backlog Items des kommenden Sprints
• die initiale Aufwandschätzung eines Projekts oder
• das herunterbrechen eines Features oder Epics?

Je nach Zielstellung kann die Vorgehensweise und auch die angewendete Schätzmethode varieren.

Beispiel-Agenda

Folgende Agenda kann für ein Refinement genutzt werden:

1. Vorstellung des Ziels des Refinements – 5-10min
2. Je Backlog Item – 15 min
   1. Vorstellung des Backlog Items durch den Product Owner – 3 min
   2. Rückfragen des Teams – 10min
   3. Schätzung des Team – 2min
3. Maßnahmen und Folgeaufgaben abgleichen – 5min

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:

• T-Shirt Größen (XS, S, M, L, XL , XXL),
• Fibonacci Zahlen (1, 2, 3, 5, 8, 13, 20, 40, 100) oder
• Gummibärchen oder
• Anzahl Finger

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:

• Initialschätzungen von Projekten oder
• die Schätzung einer großen Anzahl von Backlog Items

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)

1. An einer Wand oder einer Metaplan-Wand werden die Maßeinheiten für die Schätzung von links nach rechts aufgehängt
2. Der Product Owner stellt alle zu schätzenden Backlog Items kurz vor (in der Regel Titel und User Story)
3. Phase 1 – Initiales Platzieren der Backlog Items – keine verbale Kommunikation zwischen den Teammitgliedern
   1. Jedes Teammitglied kann sich ein Backlog Item nehmen und es unter eines der Maße hängen
   2. Ist ein Teammitglied nicht mit der Schätzung einverstanden, kann es diese umhängen
   3. Wird ein Backlog Item umgehangen, dann macht der Moderator (oder Scrum Master) einen Punkt auf die Karte
   4. Sind alle Karten aufgehangen und es gibt keine/kaum Bewegung mehr, dann wird in Phase 2 übergegangen
4. Phase 2 – Diskussion zu den uneindeutigen Backlog Items
   1. Der Moderator (oder Scrum Master) nimmt alle Backlog Items, welche sich häufig bewegt haben
   2. Die Person mit der niedrigsten und der höchsten Schätzung diskutieren ihre Standpunkte. Kommt es zu einer Einigung, so wird die Karte an der entsprechenden Stelle aufgehangen. Kommt es zu keiner Einigung, muss die Karte detailliert und später geschätzt werden.

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:

1. Der Product Owner stellt das Backlog Item vor. Das Team kann Rückfragen zum Inhalt, Umfang und Akzeptanzkriterien stellen. Antworten auf die Fragen können in dieser Phase im Backlog dokumentiert werden.
2. Jeder Entwickler schätzt für sich selbst, wie Aufwändig die Umsetzung des Backlog Items ist. Es sollten alle Punkte beachtet werden, welche in der Definition of Done festgelegt sind. Wichtig: Der Product Owner schätzt nicht mit!
3. Hat jeder eine Schätzung, dann werden die Ergebnisse gleichzeitig aufgedeckt. Das kann entweder über eigene Karten oder durch Handzeichen passieren.
4. Kommt es zu großen Abweichungen, dann diskutieren die Person mit der höchsten und die mit der niedrigsten Schätzung miteinander. Ziel ist es zu klären, was bei der Schätzung entweder vergessen oder zuviel bedacht wurde. Danach wird Schritt 3 solange wiederholt, bis es zu einer Einigung kommt.

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.

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:

• Aktualisierung der Releaseplanung an Hand der aktualisierten Schätzungen
• Klärung aller Fragen und Einwände, welche von Teamseiten aufgebracht und nicht beantwortet werden konnten
• ggf. eine Umpriorisierung der Backlog Einträge durch veränderte Schätzungen

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

1. Versuche das Refinement Meeting am Vormittag stattfinden zu lassen. Zu dem Zeitpunkt sind alle Teilnehmer noch frisch und erholt.
2. Setze das Refinement an einem Wochentag an, an welchem keine weiteren langen Meetings stattfinden. Damit beugst du der Meeting Müdigkeit vor.
3. Mache nach einer Stunde eine kurze Pause!
4. Nutze Timeboxing konsequent. Wenn zu lange an einem Backlog Item diskutiert wird, dann sollte der Product Owner dieses außerhalb des Meetings noch einmal aufbereiten.
5. Ein Backlog Item sollte keine Schätzung erhalten, wenn es noch ungeklärte Fragestellungen hat. Hinweise wie: „Die Information wird zur Umsetzung noch nachgeliefert“ bergen ein sehr großes Risiko in sich.
6. Der Product Owner darf Schätzungen hinterfragen. Aber nur in der Form, dass er sich die Gründe für die Schätzung erklären lässt. Der Product Owner kann keine Schätzung vorgeben.
7. Wenn ein Backlog Item bereits geschätzt war (in früherem Meeting) und es erneut in die Schätzung geht, lösche vorher die Schätzung. Ansonsten ist die Wahrscheinlichkeit hoch, dass die neue Schätzung ähnlich der alten sein wird.
8. Das Backlog Refinement ist ein Miteinander von Product Owner und Entwicklerteam. Es ist kein Product Owner vs. Entwicklerteam!
9. Wenn Backlog Items aufgeteilt werden, dann sollten sie möglichst unabhängig voneinander geschnitten werden.
10. Führe eine Definition of Done für die Backlog Items ein. So weißt dass Team auch, wann eine Item fertig umgesetzt ist und wieviel es dafür schätzen muss.

---

Zum Weiterlesen:

• Daily Scrum – effiziente Standup Meetings gestalten
• SCRUM Retrospektiven souverän moderieren und erfolgreich durchführen
• Timeboxing – effektives Zeitmanagement in Meetings
• 28 Tipps für effiziente Meetings und Besprechungen
• 13 Tipps zur Moderation von effizienten Online Meetings
• Magic Estimation

Letzte Aktualisierung am 26.04.2024 / Affiliate Links / Bilder von der Amazon Product Advertising API

This product presentation was made with AAWP plugin.