Ich habe in den letzten 7 Jahren mit vielen Scrum Teams gearbeitet und bei keinem Team war das Refinement gleich.
In jedem Team haben sich die Refinement-Praktiken, die funktioniert haben, mit der Zeit gewandelt. Mich hat diese Erfahrung gelehrt, dass es viele Möglichkeiten gibt, wie Scrum Teams das Product Backlog transparent machen können und das nicht die eine Praktik gibt, wie Teams erfolgreich das Product Backlog verfeinern können.
Im Folgenden findest du die 4 wichtigsten Lektionen:
Lektion #1: Refinement ist mehr als nur ein wöchentliches Meeting
Das Product Backlog Refinement immer zu einem regelmäßigen Termin, z.B. mittwochs von 14:00 bis 15:00 Uhr durchzuführen, ist eine gängige Praxis.
Allerdings führt das aber nur in den wenigsten Fällen zu einem Product Backlog, das für alle transparent ist. Dass ein Artefakt – wie das Product Backlog – in Scrum transparent ist, bedeutet, dass der aktuelle Zustand für jeden überprüfbar und bekannt sein muss.
Refinement sollte deshalb kein lästiger Pflichttermin sein.
Es umfasst vielmehr jede Aktivität, die den Zustand des Product Backlogs verändert. Um die Komplexität in der Zusammenarbeit der Teammitglieder zu reduzieren, kann ein Regeltermin ein guter Startpunkt sein. Allerdings sollte es nicht der einzige Zeitpunkt sein, an dem das Team Einträge des Product Backlogs aufteilt, Details und Größenschätzungen hinzufügt oder das Product Backlog ordnet. Neben einem Regeltermin hat sich auch folgendes Vorgehen bewährt:
- Das Scrum Team trifft sich spontan nach dem Daily Scrum, um am Product Backlog zu arbeiten.
- Es werden regelmäßig Themenworkshops zu Architektur, Security oder Skalierbarkeit abgehalten und in diesen werden auch Product-Backlog-Einträge mit passenden Akzeptanzkriterien versehen.
- Im Sprint Review werden neue Ideen gleich im Product Backlog festgehalten und bestehende Einträge angepasst oder neu geordnet.
Die Lektion, die ich daraus gelernt habe, lautet: Wir sollten uns stets fragen, wie häufig wir das Product Backlog verfeinern müssen, damit jeder im Team den aktuellen Zustand des Product Backlog kennt. Die Sprint Retrospektive bietet eine vielversprechende Möglichkeit, diese Frage regelmäßig zu beantworten.
Lektion #2: User Storys in Jira einzutragen führt nicht plötzlich zu mehr Verständnis
Leidvolle Erfahrungen bestätigen mir: Solange der Product Owner am Rechner sitzt und die Story eintippt und alle Entwickler gespannt auf den Beamer starren, wird das nicht plötzlich zu einem gemeinsamen Verständnis der Arbeit führen.
Sondern eher zu Aussagen wie: „Geliefert, wie bestellt!“
Dabei verhält es sich genauso wie beim Einkaufen: Wenn mich meine Frau bittet, zum Einkaufen zu gehen, steigt die Wahrscheinlichkeit, dass ich das Richtige mitbringe, wenn ich mir eigenständig eine Einkaufsliste schreibe. Beim Aufschreiben ergeben sich Fragen, welche sie mir erst beantworten muss, bevor ich losgehe. Insgesamt bringe ich damit nicht nur die richtigen Lebensmittel mit nach Hause, sondern übernehme auch mehr Verantwortung für den Einkauf, da ich nicht sagen kann: „Du hast etwas anderes aufgeschrieben!“ Deshalb sollte nach meiner Erfahrung auch nicht der Product Owner derjenige sein, der die Einträge im Product Backlog festhält, sondern die Entwickler. Erst wenn das ganze Scrum Team die Verantwortung dafür übernimmt, welche Einträge sich im Product Backlog befinden, kann ein gemeinsames Verständnis für die Zukunft des Produkts entstehen.
Wie kann dies gelingen?
Die Entwickler im Team könnten etwa den Product Owner interviewen, was ein lohnendes Ziel für das Produkt ist und welche Anforderungen für die Nutzer erfüllt sein müssen, damit dieses Ziel erreicht wird. Das Scrum Team kann auch gemeinsam einen Story-Mapping-Workshop durchführen. Während der Product Owner die Verwendung des Produkts aus den Augen eines Nutzers erzählt, schreiben die anderen Teammitglieder die Elemente der Map. Gute Erfahrungen habe ich auch damit gemacht, dass der Product Owner die Entwickler zum Kundenbesuch mitnimmt. So sehen sie aus erster Hand, wie Nutzer ihr Produkt verwenden und welche Probleme bei der Verwendung auftreten. Die Notizen, die sie dabei anfertigen, können die Grundlage für die nächsten Einträge im Product Backlog bilden.
Die Lehre, die ich aus diesen Erfahrungen ziehe, ist, dass wir uns stets fragen sollten, wie wir ein gemeinsames Verständnis für das Product Backlog herstellen können.
Lektion #3: Refinement ist kein Workshop zur Lösungskonzeption
Warum gibt es in Scrum keine Definition of Ready?
Damit Teams nicht erst eine vollständige Konzeption der Lösung erstellen – mit UX-Wireframes, überarbeiteten Architekturschaubildern, Schnittstellendefinition und vollständiger Testspezifikation – bevor sie den Eintrag als „Bereit für den Sprint“ markieren. Eine Definition of Ready kann das Refinement zu einer Hürde verkommen lassen, noch bevor die Arbeit überhaupt in den Sprint gelangen kann. Da man die Zukunft bei komplexer Arbeit nicht perfekt vorhersagen kann, egal wie viele Analysen man anstellt, gehen erfolgreiche Scrum Teams empirisch vor:
Sie lernen, was nötig ist, während sie die Arbeit erledigen.
Falls die Entwickler Bedenken bei der Verwendung von Algorithmen, der Skalierbarkeit oder der Verwendung von Fremdsystemen haben, sollten sie diese nicht durch umfangreiche Analysen ausräumen, sondern durch technische Spikes. Ein Spike bezeichnet dabei einen festen Zeitraum, welchen sich die Entwickler setzen, um eine Machbarkeitsstudie in Form eines Prototyps oder Wegwerf-Codes zu erstellen. Das Ziel ist es, mehr über die Lösung des Problems zu lernen.
Nach meiner Erfahrung kann dies eine hilfreiche Refinement-Aktivität sein, diese sollte aber niemals mehr als 10 % der Arbeitszeit der Entwickler in Anspruch nehmen.
Lektion #4: Die Visualisierung von Abhängigkeiten beseitigt diese nicht auf magische Weise
Wenn im Product Backlog zwei Einträge voneinander abhängen, reduziert dies die Anzahl der Möglichkeiten, das Product Backlog anzuordnen, um 50 %.
Aus Abhängigkeiten werden also schnell Hindernisse. Hindernisse für Product Owner, um den Wert des Produkts zu maximieren, indem sie das Product Backlog so ordnen, dass die wertstiftenden Einträge immer oben stehen. Abhängigkeiten zwischen Einträgen im Product Backlog zu visualisieren ist ein erster Schritt. Er reicht aber nicht aus, da diese Abhängigkeiten dadurch nicht verschwinden. Scrum Teams müssen aktiv daran arbeiten, diese Abhängigkeiten zu eliminieren, indem sie:
- Product-Backlog-Einträge zerkleinern, zusammenfassen oder neu anordnen.
- Frühzeitig fehlendes Wissen erarbeiten, um Abhängigkeiten zu externen Wissensträgern zu reduzieren.
- Nach neuen technischen Lösungswegen suchen, um etwa ohne die Einbindung von Fremdsystemen auszukommen.
- Über Teamgrenzen hinweg zusammenarbeiten, um Abhängigkeiten von anderen Teams aufzulösen.
Über die Jahre habe ich gelernt, dass die Visualisierung von Abhängigkeiten im Product Backlog nicht das Erste, sondern das Letzte sein sollte, was Scrum Teams im Refinement machen sollten. Dies sollte nur dann geschehen, wenn alle anderen Versuche, die Abhängigkeiten aufzulösen, fehlgeschlagen sind. Wir sollten uns also immer fragen: Wie häufig müssen wir wegen Abhängigkeiten das Product Backlog neu ordnen?
Möchtest du mehr erfahren?
Hoffentlich war dieser Artikel nützlich für Dich. Wie du 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.