So verbessern Sie Ihr Product Backlog Refinement

Bei der Entwicklung von Produkten gibt es einige Schlüsseltechniken, die für den Erfolg entscheidend sind. Eine davon ist die Definition der Elemente, an denen Sie arbeiten müssen, um einen Mehrwert zu schaffen – das sogenannte Product Backlog Refinement. Der Scrum Guide definiert es als “den Vorgang, durch den Product-Backlog-Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden.” [1]

In Scrum ist das Refinement eine fortlaufende Aktivität, die einmal oder mehrmals pro Sprint oder sogar täglich durchgeführt werden kann. Das Ziel besteht darin, kleinere Arbeitseinheiten zu erstellen, an denen innerhalb einer Iteration (Sprint) gearbeitet wird. Neben der Detaillierung der Items hilft das Refinement auch dabei, zu wissen, wie Sie sie überprüfen können, wann sie fertig sind, und dass Sie in die richtige Richtung arbeiten. Hier kommen üblicherweise Akzeptanzkriterien, die Definition des Umfangs und die Festlegung einer Reihenfolge der Items zum Tragen.

Wenn ich als Agile Coach neue Teams begleite, sehe ich bei den Product Backlog Refinements oft ein wiederkehrendes Muster:

• Der Product Owner (PO) begrüßt eine Gruppe von Entwicklern und gibt meist eine allgemeine Zusammenfassung der zu besprechenden Punkte.
• Dann öffnet er oder sie ein Produkt-Backlog-Management-Tool (z. B. Jira, Azure DevOps usw.) und beginnt mit der Präsentation definierter Items. In vielen Fällen wurden die Items alleine erstellt, in manchen Fällen haben einige andere Mitglieder (z. B. ein Business Analyst oder die Designer) an der Erstellung mitgewirkt.
• Nach der Präsentation der Items haben die Entwickler die Möglichkeit, Fragen zu stellen und Unklarheiten zu besprechen. Einige Personen nutzen diese Gelegenheit und die Antworten werden vom PO oder einer anderen Person im Product-Backlog-Management-Tool dokumentiert.
• Sobald alle Fragen beantwortet sind, bittet der Product Owner das Team, die Größe des Items zu schätzen, in der Regel in Story Points. Weichen die Schätzungen voneinander ab, wird entweder die Beschreibung des Items präzisiert oder das Item im Umfang reduziert bis alle mit der Schätzung einverstanden sind.
• Manchmal kommt auch eine “Definition von Done” zum Einsatz; mit ihrer Hilfe wird überprüft, ob die Aspekte, die über Umfang und Akzeptanzkriterien hinausgehen, ebenfalls berücksichtigt wurden.
• Und wenn alle relevanten Items besprochen wurden, endet die Besprechung.

Obwohl sich dieser Prozess effizient anfühlt und das Ergebnis oft ein aktualisiertes Product Backlog ist, das genügend Input für das nächste Sprint-Planungsmeeting bietet, glaube ich, dass ein solches Vorgehen einige der Schlüsselaspekte übersieht, die für ein effektives Refinement entscheidend sind. In diesem Artikel möchte ich einige Ideen vorstellen, wie Sie die Verfeinerung Ihres Backlogs verbessern können, um das Beste für Ihre Produktentwicklung herauszuholen:

1. Führen Sie das Refinement als Event durch, einmal oder mehrmals pro Sprint.
2. Der Product Owner definiert die Struktur des Events und moderiert es.
3. Integrieren Sie die Erkenntnisse aus dem letzten Sprint Review.
4. Beziehen Sie reale Benutzer in das Product Backlog Refinement ein.
5. Führen Sie mehrere Zyklen zur Aufteilung und zum Zusammenfügen durch, bei denen die Entwickler vollständig in die Verfeinerungsaktivitäten eingebunden sind.
6. Stellen Sie sicher, dass die Entwickler in guten Refinement-Techniken geschult sind.

Hier finden Sie Details zu den verschiedenen Ideen:

Führen Sie das Refinement als Event durch, einmal oder mehrmals pro Sprint

Diese Idee ist besonders nützlich, wenn mehrere Teams an demselben Produkt arbeiten. Wenn Sie die Verfeinerung des Product Backlogs als Aktivität während des Sprints durchführen, ist es wahrscheinlich, dass jedes Team Elemente verfeinert, die mit der Arbeit zusammenhängen, die es bereits im aktuellen Sprint erledigt, und die es bei der nächsten Sprintplanung auswählen kann. Dadurch ist das Wissen darüber, welche Teams welche Elemente kennen, begrenzt, und Sie sind nicht flexibel genug, um Arbeit zwischen den Teams zu verschieben.

In anpassungsfähigen (agilen) Organisationen können sich Teams gegenseitig helfen und sogar Aufgaben auswählen, die nicht unbedingt mit der Arbeit im letzten Sprint zusammenhängen, wenn sie wertvoller sind und im Backlog eine höhrer Priorisierung haben als die Aufgaben, die mit ihrer vorherigen Arbeit zusammenhängen.

Damit verschiedene Teams die wichtigsten Elemente im Backlog auswählen können, ist es hilfreich, wenn alle Teams mit den wichtigsten Elementen vertraut sind. Aus diesem Grund schlägt LeSS (Large-Scale Scrum) vor, das Product Backlog Refinement als Event durchzuführen, “vorzugsweise mit mehreren Teams, um das gemeinsame Lernen zu fördern und Koordinierungsmöglichkeiten zu nutzen”. [2] Eine effektive Möglichkeit, um sicherzustellen, dass das Wissen über die Elemente des Produt Backlogs auf die Teams verteilt wird, besteht darin, die Elemente in gemischten Gruppen von Personen aus verschiedenen Teams zu verfeinern.

Ein weiterer wichtiger Grund, das Refinement als Event durchzuführen, wie es LeSS vorgeschlägt, liegt darin, alle nicht sprintbezogenen Arbeiten in diesem zeitlich limtierten Event zusammenzufassen und den Entwicklern die Zeit zu geben, sich für den Rest des Sprints ausschließlich auf die sprintbezogenen Arbeiten zu konzentrieren. Ein wichtiger Aspekt für mich ist hier, dass das Event zwar zeitlich begrenzt sein sollte (also nicht länger als eine definierte Timebox – in der Regel 10 Prozent des Sprints, also ein Tag in einem zweiwöchigen Sprint), aber das Refinement nur dann durchgeführt werden muss, wenn es nicht genügend verfeinerte Elemente im Product Backlog gibt, die die Teams in den nächsten zwei oder drei Sprints übernehmen können.

Der Product Owner definiert die Struktur des Events und moderiert es

Wie bereits erwähnt, besteht einer der Hauptzwecke des Product Backlog Refinements (PBR) darin,

1. genügend verfeinerte Elemente im Product Backlog zu haben, damit die Teams die Sprintplanung relativ schnell durchlaufen und die wichtigsten Arbeiten aus dem oberen Teil des Backlogs auswählen können, ohne die Elemente weiter verfeinern zu müssen, und
2. die wichtigsten Arbeiten auf die verschiedenen Teams, die an dem Produkt arbeiten, verteilen zu können.

Indem Sie die Verfeinerung als gemeinsames Event für alle Teams durchführen, können Sie das Wissen bereits auf mehrere Teams verteilen. Da der Product Owner für die Kapitalrendite des Produkts verantwortlich ist, sollte er oder sie auch entscheiden, welche Punkte im nächsten Sprint am wichtigsten sind und ob es seiner oder ihrer Meinung nach entscheidend ist, dass alle Teams in den nächsten Sprints an einem bestimmten Thema oder parallel an mehreren Themen arbeiten. Im ersten Fall kann er oder sie die Verfeinerung koordinieren, sodass gemischte Gruppen von Teammitgliedern aus jedem Team das spezifische Thema in mehrere kleinere Elemente aufteilen, die später von allen Teams aufgegriffen werden können. Im zweiten Fall kann er oder sie das Refinement koordinieren, sodass eine gemischte Gruppe von Mitgliedern aus einigen Teams ein Thema verfeinert, während eine gemischte Gruppe von Mitgliedern aus anderen Teams ein anderes Thema verfeinert.

Generell würde ich vorschlagen, dass der PO gemeinsam mit dem Agile Coach oder dem Scrum Master das Refinement vorbereitet, indem er oder sie den aktuellen Stand des Product Backlogs überprüft, das Ergebnis des letzten Sprint Reviews berücksichtigt (mehr dazu im nächsten Punkt) und prüft, welche zusätzlichen geschäftlichen oder benutzerspezifischen Probleme und Anforderungen im PBR besprochen werden sollten.

Darüber hinaus kann nützlich sein, einige Entwickler in die Vorbereitungssitzung einzubeziehen, um Input zu technischen Fragen zu erhalten, die dem PO möglicherweise fehlen. Die Vorbereitung sollte zu einer klaren Tagesordnung mit Themen und Zeitplänen für das Event führen. Ein Tagesordnungspunkt könnte darin bestehen, zusätzliche Punkte (z. B. Probleme und Anforderungen) zu sammeln und der Liste der zu verfeinernden Punkte hinzuzufügen.

Integrieren Sie die Erkenntnisse aus dem letzten Sprint Review

Agile Produktentwicklung wird oft mit iterativer und inkrementeller Entwicklung gleichgesetzt. Wenn wir jedoch eine große Anforderung oder ein großes Projekt haben, hat die Aufteilung in kleinere Teile und die iterative und inkrementelle Umsetzung dieser Teile erst einmal nichts mit agiler Produktentwicklung zu tun. Solche Tätigkeiten lassen sich gff. auch im traditionellen Wasserfallmodell erledigen, vielleicht sogar effizienter. Die Stärke der agilen Produktentwicklung liegt darin, dass wir bei der Entwicklung komplexer Produkte nicht genau wissen, was wir liefern müssen. Tim Harford verweist in seinem Buch “Adapt” [3] auf den russischen Ingenieur Peter Palchinsky, der zu Beginn des 20. Jahrhunderts erwähnte, dass es drei unvorhersehbare Dimensionen (lokal, zeitlich und menschlich) gibt, die dazu führen können, dass das, was wir für die Wünsche eines Kunden halten, nicht unbedingt der Fall ist. Durch die Anwendung der Prinzipien der

• Variation (neue Ideen suchen und ausprobieren),
• Überlebensfähigkeit (in einem Maßstab arbeiten, in dem ein Scheitern überlebt werden kann) und
• Auswahl (Feedback einholen und daraus lernen)

können wir in kleinen Schritten iterieren und herausfinden, ob wir auf dem richtigen Weg sind oder nicht.

Wie in einem anderen Artikel beschrieben, bietet das Sprint Review eine gute Möglichkeit herauszufinden, ob Sie das Richtige liefern oder nicht. Die meiste Zeit im Sprint Review sollte jedoch für das Sammeln des kritischen Feedbacks verwendet werden, um die nächsten Schritte anzupassen. Wenn Sie also die Zeit im Sprint Review nicht verlängern, um genügend Zeit zu haben, das gesamte Feedback im Detail zu sortieren, zu filtern und zu bewerten, müssen Sie dies zu einem späteren Zeitpunkt tun. Der perfekte Zeitpunkt ist für mich das Refinement Event, bei dem Sie gezielt über die Arbeit sprechen, die in zukünftigen Sprints erledigt werden soll. Dies ist Ihre Chance als Team, das Kundenfeedback auszuwerten, die Kundenbedürfnisse zu verstehen und den Zweck des Produkts zu ermitteln.

Beziehen Sie reale Benutzer in das Product Backlog Refinement ein

Wer könnte die tatsächlichen Probleme und Bedürfnisse, die das Produkt lösen soll, besser erklären als die tatsächlichen Benutzer?

Wenn Sie ein internes Produkt entwickeln, das von einer internen Abteilung verwendet wird – beispielsweise ein Marketing- oder Verkaufstool –, sind die Personen, die das Tool verwenden, am besten geeignet, um offene Fragen zur benötigten Funktionalität zu klären und, was noch wichtiger ist, um den Zweck der Funktionalität des Produkts zu besprechen. Daher ist es möglicherweise das Beste, diese Personen in das Refinement des Product Backlogs einzubeziehen, um das Verständnis der Entwickler für die Bedürfnisse hinter dem Produkt zu verbessern.

Wenn Sie ein Produkt für den Massenmarkt entwickeln, ist es möglicherweise nicht so einfach, Zugang zu den tatsächlichen Nutzern zu erhalten. In einigen Fällen (vielleicht sogar in den meisten) sind die Produktentwickler auch die Nutzer des Produkts. In diesem Fall können Sie durch die Bildung gemischter Gruppen von Entwicklern aus verschiedenen Teams während des PBR verschiedene Endnutzerperspektiven in den Verfeinerungsprozess einbringen. In einigen Fällen, wenn Sie ein öffentlich zugängliches Massenprodukt entwickeln, repräsentieren Ihre Produktentwickler möglicherweise nicht die wichtigen Personengruppen, für die das Produkt bestimmt ist. Hier haben Sie mehrere Möglichkeiten:

1. Bilden Sie eine Gruppe echter Kunden, die den Personas recht gut entsprechen, und beziehen Sie verschiedene Personen aus dieser Gruppe in die Verfeinerung ein.
2. Beziehen Sie Personen aus Ihrer Marketing- oder Geschäftsabteilung in Ihr PBR ein, die die Bedürfnisse der Key User sehr gut kennen und vertreten können. Dazu könnten auch Ihre Kundendienstmitarbeiter gehören, die auf Kundenbewertungen oder -anfragen reagieren.
3. Lassen Sie Ihre Entwickler für Benutzererfahrung (UX) die Bedürfnisse und Wünsche der Schlüsselpersonen vertreten.

Wenn Sie echte Benutzer des Produkts in Refinement einbeziehen, erhalten Sie natürlich sehr genaues Feedback und Vorschläge zu Ihren Funktionen, aber möglicherweise auch sehr unterschiedliche Meinungen. Es ist wichtig, dass Ihr Product Owner bei wichtigen Entscheidungen konsultiert wird, da er oder sie für die Rendite des Produkts verantwortlich ist.

Es versteht sich hoffentlich von selbst, dass Sie die gesamte Diskussion in Ihrem Refinement Event in der Sprache des Kunden führen sollten. Wenn Sie feststellen, dass Sie eine sehr technische Sprache verwenden, die Ihr Kunde nicht versteht, sollte dies ein sehr deutliches Warnsignal dafür sein, dass Sie es möglicherweise nicht mit kundenorientierten End-to-End-Teams (oder Feature-Teams) zu tun haben, sondern mit Komponententeams, die den Kunden allein keinen End-to-End-Wert bieten können. In diesem Fall ergibt der hier beschriebene Sinn eines echten Product Backlog Refinements möglicherweise überhaupt keinen Sinn, und Sie müssen ggf. zunächst eine organisatorische Änderung vornehmen, um von einem echten Backlog Refinement und den hier vorgestellten Ideen zu profitieren.

Führen Sie mehrere Zyklen zur Aufteilung und zum Zusammenfügen durch

Wie bereits erwähnt, besteht das Ziel des Product Backlog Refinements darin, eine Liste von Items zu erstellen, an denen das Team während der nächsten Iteration arbeiten wird, und die für Kunden den höchsten Wert liefern. Dazu müssen die Punkte detailliert und klar genug sein, damit die Entwickler wissen, was sie tun müssen und wie lange es dauern wird. Manche nennen das “die Items sind bereit (für den nächsten Sprint)”. Aus meiner Sicht ist das eine Kunst! Es geht darum, die richtige Balance zu finden zwischen zu viel Diskussion und zu viel Detailarbeit und einem unzureichenden Verständnis dafür, was getan werden muss. Ersteres würde zu viel Verschwendung führen, wenn der PO feststellt, dass er oder sie nicht möchte, dass das Team daran arbeitet (und das ist immer möglich). Letzteres würde auch zu Verschwendung führen, wenn das Falsche gebaut wird oder während des Sprints viel mehr Zeit aufgewendet wird als ursprünglich geplant und so nicht genug Zeit für andere Arbeiten bleibt.

Der ideale Weg, etwas zu verstehen, besteht nicht darin, es zu lesen oder anzuhören, sondern es mit anderen zu besprechen. Eine der besten Techniken beim Refinement, die ich je kennengelernt habe, ist “Specification by Example” von Gojko Adzic [4]. Adzic beschreibt in dem Buch, wie man klare Beispiele diskutiert und aufschreibt, und so erkennt, dass das, was man implementiert, genau das ist, was man braucht. Sie können dies bspw. mit der Gherkin-Syntax von „Given-When-Then“ oder mit Tabellen tun, in die man den Anfangs- und Endzustand und die dazwischen liegende Aktion einträgt, die ausgeführt werden soll. Wenn Sie zudem kleine Gruppen von Produktentwicklern mit unterschiedlichen Fähigkeiten (Testen, Frontend-Entwicklung, Backend-Entwicklung, Geschäftsanalyse, Design) bilden, die gemeinsam diskutieren und Beispiele schreiben, stellen Sie darüber hinaus sicher, dass Sie unterschiedliche Ansichten zu Ihren Test- oder Akzeptanzkriterien erhalten und dass sich auch jeder an den Zweck der Implementierung des Elements erinnert. Ich schlage vor, mehrere kleinere Gruppen (von 4 bis 6 Personen) zu bilden, um die Elemente zu verfeinern, damit

1. Sie viele verschiedene Fähigkeiten, Ansichten und Erkenntnisse in Ihre Diskussionen einbeziehen und
2. die Gruppe nicht zu groß ist, damit sich alle an den Diskussionen beteiligen können.

Arbeiten Sie mit mehreren Teams an einem Produkt, empfiehlt es sich übrigens, die Gruppen mit Personen aus verschiedenen Teams zu mischen (wie in Idee Nr. 2 erwähnt), sodass bei der Sprintplanung mehrere Teams Elemente auswählen können, weil ihre Entwickler ein gutes Verständnis für die Elemente haben.

Manchmal ist es sogar sinnvoll, dieselben Elemente in verschiedenen Gruppen für einen Zeitraum von 30 bis 40 Minuten zu verfeinern und dann die Ergebnisse mit jeder Gruppe zu teilen. Dies könnte zu unterschiedlichen Ansätzen führen, die das Lernen fördern und zu einem besseren Verständnis des zu lösenden Problems und der besten Vorgehensweise führen. Die Ergebnisse der Gruppenarbeit können entweder von einem Mitglied mit allen geteilt werden oder indem die Gruppen zum nächsten Stand rotieren und eine Person zurückbleibt und den anderen die Ergebnisse erklärt.

Durch die Bildung gemischter Kleingruppen aus Entwicklern mit unterschiedlichen Fähigkeiten und durch zeitlich begrenzte Phasen, in denen die Gruppen ihre Erkenntnisse verfeinern und dann mit anderen teilen, können sich die Entwickler außerdem voll und ganz auf den Verfeinerungsprozess konzentrieren und besser verstehen, warum und was entwickelt werden muss, um die Kundenbedürfnisse zu erfüllen – der Hauptzweck des Refinements.

Stellen Sie sicher, dass die Entwickler in guten Refinement-Techniken geschult sind

Dies ist natürlich ein sehr großes Thema für sich. Wenn Sie nicht auf sinnvolle Weise verfeinern, verschwenden Sie möglicherweise Ihre Zeit damit, das Product Backlog zu verfeinern, anstatt es für eine erfolgreiche Produktentwicklung zu nutzen. Es ist für den Erfolg entscheidend, alle an der Produktentwicklung zu beteiligen, alle in fortgeschrittenen Techniken zu schulen (nicht nur große Anforderungen in kleinere zu unterteilen), Akzeptanzkriterien zu definieren und diese zu dimensionieren und zu bewerten sowie eine gute Produktfindung zu gewährleisten.

Ich empfehle Ihnen dringend, sich Bücher wie “Inspired” von Marty Cagen [5], “Impact Mapping” von Gojko Adzic [6], die Leitfäden für Product Backlogs und Product Backlog Refinement aus “Large-Scale Scrum” von Craig Larman & Bas Vodde [7] und das bereits erwähnte “Specification by Example” von Gojko Adzic genauer anzusehen.

Finale Gedanken

Sie haben vielleicht bemerkt, dass die genannten Ideen nicht auf Arbeitseffizienz optimiert sind, da es effizientere Möglichkeiten gibt, die Zeit zu optimieren, die ein einzelner Entwickler damit verbringt, eine Anforderung zu verstehen, als sie mit mehreren Gruppen von Entwicklern zu besprechen oder verschiedene Ideen zur Lösung eines Kundenproblems zu bewerten und kleine Experimente dafür zu erstellen.

Es ist definitiv zeiteffizienter für alle Beteiligten, wenn jemand (z. B. der PO) Zeit darauf verwendet, die Probleme der Benutzer zu verstehen und Anforderungen zu formulieren, die die Produktentwickler nur noch verstehen und umsetzen müssen. Ich bin jedoch davon überzeugt, dass die Zeitersparnis durch die Konzentration auf effizientere Wege beim Product Backlog Refinemende dazu führt, dass mehr Zeit für die Umsetzung von Dingen verschwendet wird, die der Kunde nicht braucht oder die viel besser hätten gemacht werden können. Wenn Entwickler mehr Zeit damit verbringen, die Probleme und Bedürfnisse der Kunden besser zu verstehen, bin ich sicher, dass Sie die Effektivität steigern können, indem Sie die richtigen Dinge auf die richtige Weise umsetzen.

Hinweise:

Robert Briese ist gespannt auf Ihre Meinung und würde sich über weitere Vorschläge zur Verbesserung der Produkt-Backlog-Verfeinerung freuen. Wenn Sie an weiteren Erkenntnissen von ihm interessiert sind, melden Sie sich für den Lean Sherpas LeSSons Learned newsletter.

[1] Scrum Guide
[2] LeSS Rules
[3] Adapt: Why Success Always Starts with Failure
[4] Specification by Example: How Successful Teams Deliver the Right Software
[5] Inspired: How to Create Tech Products Customers Love
[6] Impact Mapping: Making a bigt impact with software products and projects
[7] Large-Scale Scrum: More with LeSS

Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk.

Robert Briese hat im t2informatik Blog zwei weitere Beiträge veröffentlicht:

t2informatik entwickelt und modernisiert Software als Dienstleister. Ein Klick hier und Sie erfahren mehr.