Lass uns heute über das Refinement des Product-Backlogs sprechen.
Seit 10 Jahren arbeite ich mit Scrum Teams. Ich glaube, ich übertreibe nicht, wenn ich dir sage, dass ich schon fast alle Arten von Refinement gesehen habe – von: „Es findet gar kein Refinement statt“, bis hin zu: „Wir verfeinern jede Story so lange, bis sich wirklich alle 16 Einträge der Definition of Ready erfüllen.“
Die Konsequenzen?
Sprint-Plannings haben mehr als acht Stunden gedauert. Die Einträge konnten im Sprint nicht abgeschlossen werden, da nicht klar war, was zu tun ist. Stakeholder mussten ewig auf die Lieferungen warten, weil das Team erst mit der Arbeit begann, wenn der Test-Manager sein Einverständnis gab, – dieser aber auf unbestimmte Zeit im Urlaub war.
Hier habe ich dir die 3 größten Probleme im Refinement aufgelistet:
Problem #1: Das Refinement dient der Definition von Lösungen
Was ist eigentlich der Zweck des Refinements?
Lass uns gemeinsam einen Blick in den Scrum Guide werfen:
„Product-Backlog-Einträge, die durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint-Planning-Event. Diesen Transparenzgrad erlangen sie in der Regel durch Refinement-Aktivitäten.“
Hierbei sind zwei Punkte besonders wichtig:
- Refinement beschreibt die Arbeit an den Einträgen des Product-Backlogs, die vor dem Sprint-Planning passiert.
- „Bereit“ bedeutet: Die Entwickler im Scrum Team verstehen, welches Problem sie im Sprint lösen wollen.
Ich betone hier das Wort „Problem“.
Product-Backlog-Einträge in Scrum beschreiben Probleme der Nutzer oder Verbesserungen, die am Produkt vorgenommen werden sollen, um den Wert für die Kunden zu erhöhen. Zusammengefasst beschreiben sie, „was“ getan werden soll – nicht „wie“ das „Was“ getan werden soll.
Dafür gibt es das Sprint-Backlog:
„Das Sprint-Backlog besteht aus dem Sprint-Ziel (Wofür), den für den Sprint ausgewählten Product-Backlog-Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Inkrements (Wie).“
Der Scrum Guide empfiehlt Teams, zwischen dem „Was“ und „Wie“ zu trennen.
Diese Trennung zeigt sich an mehreren Stellen:
- Die unterschiedlichen Backlogs
- Die Aufteilung der Verantwortlichkeiten zwischen Entwicklern, Scrum Master und Product-Owner
- Die Unterscheidung zwischen Product-Backlog-Refinement und der restlichen Zeit im Sprint
Hierzu schreibt der Scrum Guide:
„Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden.“
Im Sprint werden also Ideen zur Lösung der Probleme gefunden. Es wird die technische Umsetzung eines neuen Features geplant und realisiert.
Das Double-Diamond-Modell erklärt diesen Ablauf gut.
Ursprünglich wurde es von der britischen Regierung entwickelt und besteht aus vier Phasen:
- Entdeckung des Problems
- Validierung des Problems
- Entdeckung von Lösungen
- Validierung der Lösungen
Die ersten beiden Phasen gehören zum Refinement. Die letzten beiden Phasen umfassen die Arbeit im Sprint. Einträge im Product-Backlog sind „bereit“, wenn die Definition des Problems abgeschlossen ist.
Warum ist es ein Problem, im Refinement bereits an der Lösung zu arbeiten?
Die Arbeit am „Wie“ sollte im Sprint stattfinden, um Risiken zu kontrollieren. Sprints dienen dazu, die Kosten für die Erstellung der Lösung zu begrenzen. Wird im Refinement zu sehr am „Wie“ gearbeitet, wird dieser Mechanismus zur Kontrolle der Investitionen ausgehebelt. Ich sage nicht, dass im Refinement keine Lösungsansätze diskutiert werden dürfen. Aber wenn sich das Refinement nur noch um die Lösung des Problems dreht und nicht mehr um die Entdeckung des Problems, wird es problematisch.
Das finanzielle Risiko ist dann nicht mehr auf einen Sprint begrenzt.
Problem #2: Im Refinement sind die falschen Stakeholder zur falschen Zeit dabei
Sollen alle Entwickler am Refinement teilnehmen?
Der Scrum Guide gibt dazu keine klare Vorgabe. Das teilt die Scrum Community in zwei Lager:
- Einige sind überzeugt, dass es keine echte Transparenz gibt, wenn nicht jeder im Team die Einträge im Product-Backlog kennt. Transparenz ist schließlich mehr als Sichtbarkeit – sie bedeutet gemeinsames Verständnis.
- Andere sehen das pragmatisch. Ist es überhaupt sinnvoll, dass jeder Entwickler am Refinement teilnimmt? Vor allem, wenn das Team groß ist oder mehrere Teams an einem Produkt arbeiten?
Ich denke, beide Lager haben gute Argumente. Lassen sich diese nicht vereinen?
Doch – mit einem Vorgehen von Dr. Charles Suscheck:
Es gibt eine einfache Anleitung, mit wem und wann das Refinement stattfinden sollte:
- Wenn das Problem noch vage beschrieben ist, sollte ein Refinement mit den Kunden und Stakeholdern stattfinden. Ziel: Das Problem besser entdecken und validieren, ob es sich lohnt, dieses Problem zu lösen.
- Wenn das Problem konkreter ist, sollten Fachexperten einbezogen werden, um es noch besser zu beschreiben und zu verstehen.
- Bereit für das Sprint-Planning sollte der Eintrag dann ausschließlich mit den Entwicklern des Scrum Teams gemacht werden.
Je länger ich mit Scrum Teams arbeite, desto mehr bin ich überzeugt: Teams sollten gute Gründe haben, wenn sie von diesem Vorgehen abweichen.
Denn entscheidet sich ein Team für eines der beiden Lager, führt das schnell zu verschwendeter Arbeitszeit:
- Wurden etwa UX-Experten zu spät hinzugezogen, musste häufig alles noch einmal überdacht werden.
- Wurden Software-Architekten zu früh einbezogen, führte das zu unnötigen Diskussionen in einer frühen Refinement-Phase.
Beides ist problematisch.
Problem #3: Die Diskussionen im Refinement drehen sich im Kreis
Was versprechen sich Unternehmen von Scrum?
Hoffentlich mehr Agilität. Doch was dabei oft übersehen wird:
Agilität braucht Entscheidungen.
Was meine ich damit? Nicht zu entscheiden, ist das Gegenteil von Agilität. Es geht nicht darum, möglichst gut zu entscheiden – denn ob eine Entscheidung gut war oder nicht, wissen Scrum Teams erst später. Wäre Feature A oder Feature B besser? Das kann nur der Markt beantworten. Aber dazu muss das Team sich erst entscheiden, welches Feature es umsetzen wird.
Agilität lebt von Entscheidungen.
Doch wenn keine Entscheidungen getroffen werden, lähmt das die Agilität eines Unternehmens.
Diese Entscheidungsblockade lässt sich oft im Refinement beobachten. Theoretisch durchläuft jedes Refinement-Meeting zwei Phasen:
Den Raum öffnen:
- Alternativen werden gefunden.
- Die Diskussion ist offen und fließt frei.
- Perspektiven werden gesammelt.
- Auf Bewertung und vorschnelle Urteile wird verzichtet.
Den Raum schließen:
- Alternativen werden bewertet.
- Ideen werden sortiert und kategorisiert.
- Die wichtigsten Punkte werden zusammengefasst.
- Lösungen werden beurteilt.
In der Praxis passiert das leider oft nicht. Viele Teams bleiben in der Mitte stecken – die Diskussionen drehen sich im Kreis. Es knirscht. Deshalb heißt diese Phase auch „Groan Zone“.
Dann ist die Zeit des Meetings abgelaufen und Team und Stakeholder trennen sich.
Warum ist das ein Problem?
Es wurde keine Entscheidung getroffen.
Suchst du Techniken und Methoden, wie du deinem Team helfen kannst, sich der Entdeckung des Problems zu widmen? Sich also im Refinement auf das „Was“ zu konzentrieren?
Dann wirf einen Blick auf das „Professional Product Discovery and Validation“-Training. Dort widmen Boris Steiner und ich diesem wichtigen Thema, welches in den meisten Scrum Trainings keine Beachtung findet, einen ganzen Tag.