6 Tips to improve your Product Backlog refinement

Wenn es um erfolgreiche Produktentwicklung geht, gibt es einen Bereich, der besonders hervorsticht: die Erstellung und Verfeinerung der Einträge, die umgesetzt werden müssen, um echten Mehrwert zu liefern. Im Scrum wird dies als Product Backlog Refinement bezeichnet, und es ist ein echter Gamechanger. Man kann es als den Prozess betrachten, in dem große Ideen in klare, umsetzbare Aufgaben geformt werden, die innerhalb eines Sprints bearbeitet werden können. Laut dem Scrum Guide ist das Refinement „der Vorgang, durch den Product-Backlog-Einträge in kleinere, präzisere Elemente zerlegt und weiter definiert werden“. Dies ist kein einmaliges Ereignis – es ist eine fortlaufende Praxis, die während des Sprints stattfindet. Das Ziel? Sicherzustellen, dass man immer in die richtige Richtung geht. Aber Refinement bedeutet mehr als nur das Zerlegen von Aufgaben. Es geht darum, genug Details hinzuzufügen, damit, wenn die Arbeit abgeschlossen ist, sie auch tatsächlich abgeschlossen ist. Dazu gehört die Festlegung von Akzeptanzkriterien, die Schätzung des Aufwands und manchmal sogar die Priorisierung der nächsten Schritte. Es geht darum, das Team Schritt für Schritt auf Erfolg auszurichten.

‍

Als Agile Coach fällt mir bei den meisten Teams, denen ich beitrete, ein gemeinsames Muster bei den Product Backlog Refinements auf:

Der Product Owner (PO) beginnt in der Regel mit der Begrüßung des Teams – einer vielfältigen Gruppe von Produktentwicklern – und gibt manchmal einen kurzen Überblick über die Punkte auf der Tagesordnung.
Dann öffnet sie ein Product Backlog-Management-Tool wie Jira oder Azure DevOps und geht die von ihr erstellten Elemente durch. Manchmal hat sie diese Einträge alleine erstellt, manchmal hat auch der Business Analyst oder ein Designer mitgewirkt.
Nach der Vorstellung jedes Eintrags gibt es Raum für das Team, Fragen zu stellen und Unklarheiten zu klären. Einige Teammitglieder melden sich zu Wort, stellen ihre Fragen, und die Antworten werden im Product Backlog-Tool dokumentiert.
Nach Abschluss der Diskussion bittet der PO das Team, die Größe der Einträge zu schätzen – in der Regel in Story Points oder einer ähnlichen Schätzungsmethode. Wenn die Schätzungen stark variieren, taucht das Team tiefer ein, fügt mehr Klarheit hinzu oder passt den Umfang an, bis alle mit der Schätzung übereinstimmen.
Manchmal wird eine „Definition of Ready“-Checkliste konsultiert, um sicherzustellen, dass nichts Wichtiges – wie Akzeptanzkriterien oder zusätzliche Aufgaben – übersehen wurde, bevor zum nächsten Punkt übergegangen wird.
Nachdem alle vorbereiteten Punkte behandelt wurden, endet die Sitzung.

Auf den ersten Blick scheint dieser Prozess effizient zu sein. Das Product Backlog wird aktualisiert, und das Team verlässt die Sitzung mit einer Liste von Elementen, die für die nächste Sprint-Planung vorbereit sind. Ich bin jedoch der Meinung, dass dieser Ansatz oft wichtige Chancen für ein wirklich effektives Product Backlog Refinement verpasst. In diesem Artikel teile ich einige Strategien, die Ihre Refinement auf ein höheres Niveau heben und sicherstellen, dass Sie das volle Potenzial dieser wichtigen Aktivität ausschöpfen:

Machen Sie das Product Backlog Refinement zu einem formalen Ereignis, das einmal oder mehrmals pro Sprint stattfindet.
Der Product Owner übernimmt die Planung und Leitung der Sitzung, um den Fokus zu wahren.
Nutzen Sie die Erkenntnisse aus dem letzten Sprint Review, um sich auf das Wesentliche zu konzentrieren.
Beteiligen Sie echte Benutzer am Refinement-Prozess, um sicherzustellen, dass Sie die passenden Lösungen umsetzen.
Nutzen Sie wiederholte Phasen des Auseinander- und Zusammenführens, um die Produktentwickler aktiv in die Diskussionen und Verfeinerungen einzubeziehen.
Unterstützen Sie Entwickler dabei, fortgeschrittene Methoden des Backlog-Refinements zu erlernen, um die Qualität der Ergebnisse zu verbessern.

Schauen wir uns jedes dieser Vorschläge im Detail an, um zu sehen, wie sie Ihr Product Backlog Refinement effizienter gestalten können:

‍

1. Machen Sie das Product Backlog Refinement zu einem formalen Ereignis, das einmal oder mehrmals pro Sprint stattfindet

Dieser Ansatz ist besonders effektiv, wenn mehrere Teams am selben Produkt arbeiten. Wenn das Refinement informell während des Sprints durchgeführt wird, neigen Teams dazu, sich nur auf Punkte zu konzentrieren, die mit ihrer aktuellen Arbeit zusammenhängen und die sie wahrscheinlich für den nächsten Sprint auswählen werden. Obwohl dies effizient erscheinen mag, schränkt es den Wissensaustausch zwischen den Teams ein und reduziert die Flexibilität, Arbeit bei Bedarf neu zu verteilen. In agilen Organisationen ist Anpassungsfähigkeit entscheidend. Teams sollten sich gegenseitig unterstützen und Aufgaben übernehmen können, die nicht mit ihrer Arbeit im vorherigen Sprint verbunden sind, aber wertvoller oder höher im Product Backlog priorisiert sind.

Damit verschiedene Teams die wertvollsten Elemente auswählen können, ist es wichtig, dass alle Teams mit diesen Elementen vertraut sind. Deshalb empfehlen Frameworks wie LeSS (Large-Scale Scrum), das Product Backlog Refinement als ein teamübergreifendes Ereignis durchzuführen. Es fördert das gemeinsame Lernen und eröffnet Koordinationsmöglichkeiten zwischen den Teams. Eine praktische Möglichkeit, sicherzustellen, dass die Teams ein breites Verständnis der wichtigsten Backlog-Elemente haben, besteht darin, gemischte Gruppen von Entwicklern aus verschiedenen Teams zu bilden, um die Elemente gemeinsam zu verfeinern.

Ein weiterer wichtiger Grund, das Product Backlog Refinement als formales Ereignis anzusetzen, wie es LeSS vorschlägt, besteht darin, nicht sprintbezogene Arbeit in einer zeitlich begrenzten Sitzung zu konsolidieren. Dadurch wird den Entwicklern der restliche Sprint freigehalten, um sich ausschließlich auf sprintbezogene Aufgaben zu konzentrieren. Der Schlüssel hierbei ist, dass die Sitzung strikt zeitlich begrenzt sein sollte – in der Regel nicht mehr als 10 % der Sprint-Dauer, was etwa einem Tag in einem zweiwöchigen Sprint entspricht. Wichtig ist auch, dass das Refinement nur durchgeführt werden muss, wenn es nicht genügend detaillierte Backlog-Elemente gibt, um die nächsten zwei oder drei Sprints abzudecken.

‍

2. Der Product Owner übernimmt die Planung und Leitung der Sitzung

Wie bereits erwähnt, sind die Hauptziele des Product Backlog Refinement zweifach: (1) sicherzustellen, dass genügend verfeinerte Elemente im Backlog vorhanden sind, damit die Teams die Sprint-Planung schnell durchlaufen können, indem sie die wichtigsten Aufgaben aus dem oberen Teil des Backlogs auswählen, ohne dass weitere Klärungen erforderlich sind, und (2) die Verteilung der wichtigsten Arbeiten auf alle Teams, die am Produkt arbeiten, zu gewährleisten. Indem Sie das Product Backlog Refinement als gemeinsames Ereignis für alle Teams organisieren, wie in Tipp 1 hervorgehoben, fördern Sie bereits den Wissensaustausch zwischen den Teams. Da der Product Owner für die Maximierung des Return on Investment des Produkts verantwortlich ist, ist sie die beste Person, um zu bestimmen, welche Elemente für den nächsten Sprint priorisiert werden sollten und ob es notwendig ist, dass alle Teams an einem Thema arbeiten oder parallel an verschiedenen Themen voranschreiten.

Im Allgemeinen empfehle ich, dass der Agile Coach oder Scrum Master mit dem PO zusammenarbeitet, um das Product Backlog Refinement im Voraus vorzubereiten, indem sie den aktuellen Stand des Backlogs überprüfen, die Ergebnisse des letzten Sprint Reviews berücksichtigen (mehr dazu in der nächsten Idee) und zusätzliche Geschäfts- oder Benutzerprobleme und -anforderungen identifizieren, die besprochen werden sollten. Es kann auch von Vorteil sein, einige Produktentwickler in die Vorbereitungsphase einzubeziehen, um technische Aspekte anzusprechen, die der PO möglicherweise übersieht. Die Vorbereitung sollte in einer klaren Agenda mit Themen und Zeitrahmen für die Sitzung resultieren. Ein Agendapunkt könnte das Sammeln und Hinzufügen neuer Themen (wie Probleme oder Anfragen) zur Liste der zu verfeinernden Elemente sein, aber die Verantwortung für die Leitung der Sitzung sollte beim PO bleiben, mit Unterstützung des Scrum Masters oder Agile Coaches.

‍

3. Nutzen Sie die Erkenntnisse aus dem letzten Sprint Review

Agile Produktentwicklung wird häufig mit iterativen und inkrementellen Arbeit gleichgesetzt. Wenn wir jedoch lediglich eine große Anforderung oder ein Projekt einmal in kleinere Teile zerlegen und diese Teile iterativ und inkrementell umsetzen, verpassen wir den wahren Nutzen der agilen Produktentwicklung. In einem solchen Szenario hätten wir genauso gut das traditionelle Wasserfallmodell verwenden können und möglicherweise eine noch größere Effizienz erreicht. Die wahre Stärke von Agilität liegt in der Fähigkeit, mit der Unsicherheit umzugehen, die der komplexen Produktentwicklung innewohnt, bei der sich unser Verständnis dessen, was geliefert werden muss, im Laufe der Zeit entwickeln kann.

Tim Harford verweist in seinem Buch Adapt auf den russischen Ingenieur Peter Palchinsky, der drei unvorhersehbare Dimensionen – lokale, zeitliche und menschliche Faktoren – betonte, die dazu führen können, dass wir missverstehen, was die Kunden wirklich wollen. Indem wir Prinzipien wie Variation (neue Ideen erforschen und testen), Überlebensfähigkeit (in einem Umfang arbeiten, in dem Misserfolge handhabbar sind) und Selektion (Feedback sammeln und daraus lernen) anwenden, können wir kleine Schritte unternehmen, um zu iterieren und festzustellen, ob wir in die richtige Richtung gehen.

Wie ich in einem früheren Artikel erwähnte, ist eine effektive Methode, um zu beurteilen, ob wir das richtige Produkt liefern, das Sprint Review im Scrum. Es ist jedoch entscheidend, einen erheblichen Teil des Sprint Reviews darauf zu verwenden, wichtiges Feedback zu sammeln, das unsere nächsten Schritte informiert. Sofern wir die für das Sprint Review vorgesehene Zeit nicht verlängern, um das gesamte Feedback detailliert zu sortieren, zu filtern und zu bewerten, müssen wir diese wichtige Aufgabe verschieben. Ich bin der Meinung, dass der ideale Zeitpunkt hierfür während des Product Backlog Refinement Events ist, wo wir gezielt über die Arbeit sprechen können, die für zukünftige Sprints geplant ist. Diese Veranstaltung bietet eine wertvolle Gelegenheit für das Team, Kundenfeedback zu bewerten, die Bedürfnisse der Kunden zu verstehen und den Zweck des Produkts zu klären.

‍

4. Beteiligen Sie echte Benutzer am Refinement-Prozess

Wer könnte besser die echten Probleme und Bedürfnisse erklären, die ein Produkt lösen sollte, als die tatsächlichen Nutzer? Wenn Sie ein internes Tool entwickeln, beispielsweise eine Marketing- oder Vertriebsplattform, sind die Personen, die das Produkt nutzen werden, am besten geeignet, um die funktionalen Anforderungen zu klären und, noch wichtiger, den zugrundeliegenden Zweck dieser Funktionen zu erörtern. Diese Personen in Ihre Product Backlog Refinement (PBR)-Sitzungen einzubeziehen, könnte einer der wirkungsvollsten Schritte sein, um das Verständnis der Entwickler für die tatsächlichen Anforderungen des Produkts zu verbessern.

Bei der Entwicklung eines Massenmarktprodukts ist der direkte Zugang zu Nutzern möglicherweise nicht so einfach. In einigen Fällen gehören Ihre Produktentwickler zur Zielgruppe, was es ermöglicht, ihre Perspektiven auf natürliche Weise einzubringen. Indem Sie während des PBR gemischte Gruppen von Entwicklern aus verschiedenen Teams bilden, können Sie unterschiedliche Endnutzerperspektiven in den Refinement-Prozess einfließen lassen. Wenn jedoch bei Massenmarktprodukten die Entwickler möglicherweise nicht vollständig die wichtigsten Zielgruppen repräsentieren, haben Sie mehrere Alternativen:

Erstellen Sie eine Kundengruppe, die Ihre Zielpersonen genau repräsentiert, und laden Sie unterschiedliche Mitglieder dieser Gruppe ein, an den PBR-Sitzungen teilzunehmen.
Integrieren Sie die Marketing- oder Business-Teams, die über fundierte Kenntnisse der Kundenbedürfnisse verfügen und als Stellvertreter für wichtige Personas agieren können. Dazu könnten auch Mitarbeiter des Kundensupports gehören, die an vorderster Front Kundenfeedback und -anfragen erhalten.
Binden Sie die UX-Experten innerhalb Ihrer Produktentwicklungsteams, die die Wünsche und Erwartungen Ihrer wichtigsten Nutzer repräsentieren können.

Obwohl das Einbeziehen realer Nutzer in PBR wertvolle Rückmeldungen und Feature-Vorschläge liefern kann, können dabei auch widersprüchliche Meinungen aufkommen. In diesen Fällen ist es wichtig, dass der Product Owner (PO) in den Entscheidungsprozess eingebunden bleibt, da sie letztendlich dafür verantwortlich ist, den Return on Investment (ROI) des Produkts zu maximieren.

Darüber hinaus ist es entscheidend, dass die gesamte Diskussion während der PBR-Events in der Sprache des Kunden geführt wird. Wenn Sie bemerken, dass das Gespräch zu technisch wird und Fachjargon verwendet wird, den der Kunde nicht verstehen würde, ist dies ein Warnsignal. Dies könnte darauf hindeuten, dass Sie mit Komponenten-Teams arbeiten, anstatt mit echten End-to-End- oder Feature-Teams, die eigenständig in der Lage sind, tatsächliche Kundenanforderungen zu liefern. In solchen Situationen kann der Wert eines echten Product Backlog Refinements, wie hier beschrieben, beeinträchtigt werden, und eine organisatorische Veränderung könnte notwendig sein, bevor Sie die volle Wirkung der hier vorgestellten Ansätze und Ideen ausschöpfen können.

‍

5. Nutzen Sie wiederholte Phasen des Auseinander- und Zusammenführens

Wie bereits erwähnt, besteht das Hauptziel des Product Backlog Refinements darin, eine Liste von Arbeitspaketen für das Team oder die Teams zusammenzustellen, die in der nächsten Iteration bearbeitet werden sollen, um maximalen Wert zu liefern oder herauszufinden, was geliefert werden muss, um diesen Wert zu schaffen. Diese Elemente müssen detailliert und klar genug sein, damit die Entwickler, die sie umsetzen, verstehen, was getan werden muss und wie lange es voraussichtlich dauert, die Arbeit im kommenden Sprint abzuschließen. Einige nennen dies "bereit für den nächsten Sprint”. Aus meiner Sicht ist das Erreichen dieser Bereitschaft eine echte Kunst! Es geht darum, das richtige Gleichgewicht zwischen zu viel und zu wenig Diskussion zu finden. Übermäßige Verfeinerung kann zu Verschwendung führen, wenn der Product Owner (PO) entscheidet, dass das Team nicht mehr an diesem Eintrag arbeiten soll (was immer möglich ist). Andererseits kann eine unzureichende Verfeinerung dazu führen, dass Zeit verschwendet wird, weil das Falsche gebaut wird oder die Umsetzung länger dauert als ursprünglich geplant und somit nicht genug Zeit für andere Aufgaben bleibt.

Um echtes Verständnis zu gewährleisten, reicht es nicht aus, nur zu lesen oder zuzuhören – der Schlüssel liegt in einer tiefgehenden Diskussion mit anderen. Eine sehr effektive Technik zum Refinement von Items ist „Specification by Example“ von Gojko Adzic. Hierbei werden klare Beispiele formuliert, wie man weiß, dass das, was man baut, genau das ist, was gebraucht wird. Diese Methode kann mit der Gherkin-Syntax durchgeführt werden, indem man das „Give-When-Then“-Format verwendet, oder durch Tabellen, die den Start- und Endzustand sowie die auszuführende Aktion dokumentieren. Durch die Bildung kleiner, funktionsübergreifender Gruppen von Entwicklern mit unterschiedlichen Fähigkeiten (z. B. Testing, Frontend-, Backend-Entwicklung, Business-Analyse und Design), die gemeinsam Beispiele diskutieren und dokumentieren, wird sichergestellt, dass eine Vielzahl von Perspektiven erfasst wird. Zusätzlich verstärkt dieser Ansatz das Verständnis aller Beteiligten dafür, warum das Item überhaupt implementiert wird.

Ich empfehle, mehrere kleinere Gruppen (jeweils 4–6 Personen) zu bilden, die am Refinement der Einträge arbeiten. Auf diese Weise (1) werden unterschiedliche Fähigkeiten, Standpunkte und Erkenntnisse in die Diskussionen eingebracht, und (2) wird vermieden, dass Gruppen zu groß werden, sodass jeder aktiv teilnehmen kann. Wenn mehrere Teams am selben Produkt arbeiten, ist es noch vorteilhafter, Teammitglieder aus verschiedenen Teams zu mischen (wie in Punkt 2 beschrieben). Dieser teamübergreifende Wissensaustausch ermöglicht es mehreren Teams, die Einträge während der Sprint-Planung selbstbewusst aufzugreifen, da in jedem Team Entwickler sind, die bereits mit ihnen vertraut sind.

In einigen Fällen kann es hilfreich sein, dass verschiedene Gruppen dasselbe Eintrag für einen zeitlich begrenzten Zeitraum von 30 bis 40 Minuten verfeinern, gefolgt von einer Sitzung, in der jede Gruppe ihre Ergebnisse teilt. Dieser Prozess kann unterschiedliche Herangehensweisen aufzeigen, das Lernen fördern und zu einem besseren Verständnis sowohl des zu lösenden Problems als auch der besten Lösungsmethode führen. Das Teilen von Erkenntnissen kann dadurch geschehen, dass ein Vertreter jeder Gruppe dem gesamten Team präsentiert, oder durch Gruppenrotationen, bei denen eine Person an jeder „Station“ bleibt, um die Ergebnisse der Gruppe den anderen zu erklären.

Durch die Schaffung kleiner, diverser Gruppen von Produktentwicklern, die Einträge in zeitlich begrenzten Abschnitten verfeinern und anschließend ihre Erkenntnisse teilen, stellen Sie sicher, dass die Entwickler während des gesamten Refinement-Prozesses voll engagiert bleiben. Dies fördert ein tieferes Verständnis dafür, was entwickelt werden muss und warum, und richtet das Team auf das übergeordnete Ziel aus, die Kundenbedürfnisse zu erfüllen – der wahre Zweck des Refinements.

‍

6. Unterstützen Sie Entwickler dabei, fortgeschrittene Methoden des Backlog-Refinements zu erlernen

Dies ist zweifellos ein großes und wichtiges Thema. Wenn Ihr Product Backlog Refinement nicht effektiv durchgeführt wird, verschwenden Sie möglicherweise wertvolle Zeit, anstatt diese zu nutzen, um den Erfolg Ihrer Produktentwicklungsaktivitäten voranzutreiben. Es ist unerlässlich, dass alle am Produktentwicklungsprozess Beteiligten in fortgeschrittenen Techniken geschult werden. Dies geht über das einfache Zerlegen großer Anforderungen in Kleinere hinaus und umfasst das Definieren klarer Akzeptanzkriterien, das richtige Schätzen und Priorisieren von Einträgen, sowie das Beherrschen von Techniken zur Product-Discovery – all dies ist entscheidend für den Erfolg.

Folgende Ressourcen kann ich hierfür sehr empfehlen: Untrapping Product Teams von David Pereira, Inspired von Marty Cagen, Impact Mapping von Gojko Adzic, die Product Backlog und Product Backlog Verfeinerung Leitfäden aus Large-Scale Scrum von Craig Larman & Bas Vodde, und natürlich das bereits erwähnte Specification by Example von Gojko Adzic.

‍

Abschließende Worte

Sie haben vielleicht bemerkt, dass die hier besprochenen Ansätze nicht unbedingt die Arbeitseffizienz während des Refinements priorisieren. Es gibt sicherlich effizientere Wege, wie Entwickler Anforderungen schneller erfassen – z. B. indem diese vom Product Owner (PO) oder einer anderen Person im Detail vorbereitet und erklärt werden. Wenn der PO Zeit damit verbringt, die Benutzerprobleme zu verstehen und klare Anforderungen zu schreiben, könnte es tatsächlich schneller für Entwickler sein, diese ohne längere Diskussionen umzusetzen. Ich glaube jedoch fest daran, dass dies zwar anfänglich Zeit sparen könnte, aber oft später zu einer größeren Zeitverschwendung führt, indem Funktionen implementiert werden, die vom Kunden nicht wirklich benötigt werden, oder die Gelegenheiten verpasst wird, eine bessere Lösung zu liefern.

Indem Sie Produktentwickler dazu ermutigen, mehr Zeit damit zu verbringen, die Probleme und Bedürfnisse der Kunden gründlich zu verstehen, bin ich überzeugt, dass Sie die Gesamteffektivität steigern werden, indem Sie die richtigen Dinge auf die richtige Weise liefern.

Ich freue mich darauf, Ihre Gedanken dazu zu hören und weitere Vorschläge zu erhalten, wie Sie die Product Backlog Verfeinerung verbessern können.

‍