14.07.2017  Verfasst von Christopher Walg in Agile Blog  

Haltet euer Product Backlog sauber!

Ein hierarchisches Backlog bringt Struktur in die Anforderungsflut.

Folgt die Produktentwicklung einem wirklich agilen Vorgehen, dann ist das Product Backlog nicht nur zentrales Werkzeug des Product Owners, sondern auch das lebhafteste Artefakt im Prozess. Dank Software-Tools wie JIRA ist die dynamische Verwaltung zwar einfacher geworden, aber die Herausforderung bleibt, in einer Vielfalt von Backlog Items den Gesamtüberlick zu behalten. Nicht selten stoße ich in meiner Praxis auf Backlogs, die vom jeweiligen Product Owner derart individualisiert wurden, dass sie ein Außenstehender kaum mehr verstehen kann. Dies widerspricht jeglicher Absicht, die ein Product Backlog verfolgt. Unter dem vorzufindenden Chaos leidet nicht nur die Transparenz, auch die Mitarbeit durch das Team wird erschwert, obwohl diese essentiell ist, um ein erfolgreiches Produkt zu schöpfen.

Um das Product Backlog übersichtlich zu halten und größtmögliche Mitwirkung durch Stakeholder und Team zu ermöglichen, hat sich in meiner Praxis ein hierarchischer Ansatz über mehrere Ebenen bewährt. Das eigentliche Product Backlog muss einem klaren Qualitätsanspruch folgen, jedes Item sollte immer möglichst nah an der Definition of Ready sein, um es in der Produktentwicklung jederzeit zur Umsetzung zu bringen. Ideen und unausgereifte User Stories gehören in ein separates Backlog, das ich in meinem Kontext auch Ideen Backlog nenne. Je nach Größe der Produktentwicklung kann dazwischen eine weitere Ebene helfen, um die Analysephase zwischen Ideen Backlog und Product Backlog zu strukturieren.

Das Ideen Backlog
Ein Backlog, das vom eigentlich Product Backlog vollständig separiert wird und grundsätzlich mit möglichst wenig Regeln auskommt. Hier werden neue Anforderungen aus Dokumenten gesammelt, Workshop-Ergebnisse direkt in User Stories oder Epics dokumentiert oder einfach die Wünsche aus den Sprint Reviews und Feedback-Runden mit Usern festgehalten. Refinements finden hier hauptsächlich mit Stakeholdern statt. Es kann, aber es muss keine Beschränkung auf Item Typen geben, denn ein kontrolliertes Chaos kann hier schlussendlich auch die Kreativität fördern. In Umfeldern mit Erwartungshaltungen aus dem klassischen Projektmanagement kann hier eine grobe Schätzung und Planung abgebildet werden, ohne die agilen Teams mit unreifen Vorhaben zu bremsen.

Das Product Backlog
Das zentrale Backlog, wenn es mit der Umsetzung von Anforderungen konkreter werden darf und die agilen Teams der Produktentwicklung vollständig eingebunden werden. Was hier landet, geht ins Refinement mit den Teams und endet als User Story, die alle Kriterien der Definition of Ready erfüllt. Selbstverständlich bleibt es ein lebhaftes Artefakt und befindet sich in einem ständigen Veränderungsprozess. Neues Feedback der Anwender oder die Lerneffekte der Teams werden direkt im Product Backlog eingearbeitet. Sind die Auswirkungen besonders groß, können die Items auch den Rückweg ins Ideen Backlog nehmen.

Das/Die Sprint Backlog(s)
Das Backlog für den Sprint gehört dem Team und enthält auch nur die User Stories, auf die sich der Product Owner und das Team im Planning auf Basis des Product Backlogs „committen“.

Gerade in großen Organisationen oder bei Dienstleistern, die gleichzeitig für mehrere Kunden und Projekte entwickeln, bietet die Abbildung über mehrere Ebenen einen weiteren Vorteil. Rollen und Rechte können sinnvoller verteilt werden, ohne auf die Transparenz zu verzichten. Während im Product Backlog nur der Product Owner und das Team schreibend agieren, kann ein Ideen Backlog für alle offen gestaltet werden. Maximale Kollaboration auf dem Ideen Backlog fördert die Kreativität und das Zusammenspiel der Stakeholder, ohne Gefahr zu laufen, dass Unkenntnis negative Auswirkungen auf die Produktentwicklung hat.

In meiner eigenen Erfahrung hat sich die Einführung einer solchen Hierarchie in einer Produktentwicklung mit 2-3 Teams für ein (überwiegend) ausgereiftes Produkt bewährt. Allerdings gilt hier, wie so oft in der agilen Produktentwicklung, es gibt keine absolute Wahrheit. Gerade bei Neuentwicklungen wird es förderlich sein, mit nur einem Backlog zu starten und erst in der Reifephase über eine Hierarchie nachzudenken. Schaut euch euer Backlog an, fragt eure Teams und entscheidet gemeinsam, ob Handlungsbedarf besteht.