Scrum: Welche Eigenschaften sollte ein gutes Product Backlog haben?

In der agilen Software-Entwicklung ist das sog. Product Backlog ein wichtiges Artefakt. Es enthält alle Arbeiten, die für die Erstellung einer erfolgreichen Software-Anwendung erforderlich sind, also Funktionen, Fehler (Bugs) usw. Die Güte eines Product Backlogs hat erheblichen Einfluss darauf, wie gut das Entwicklungsteam es abarbeiten kann. Je besser der Kunde und das Team ein solches Backlog also aufbereiten und aktuell halten, desto produktiver und schneller erfolgt die Umsetzung.

Daraus ergibt sich die Fragestellung, wie die Güte eines Product Backlogs eingeschätzt werden kann. Anhaltspunkte dafür bieten die “DEEP-Eigenschaften”, die ein Product Backlog aufweisen sollte. DEEP steht für:

  • Detailed appropriately
  • Emergent
  • Estimated
  • Prioritised

Sehen wir uns diese Eigenschaften einmal genauer an.

Detailed appropriately: Angemessen detailliert

Die Grundregel hierbei heißt: Je näher die Umsetzung eines Backlog-Items (also eines Elements aus dem Product Backlog) rückt, desto granularer sollte es aufbereitet sein:

  • Items, die innerhalb der nächsten Tage und wenigen Wochen umzusetzen sind, werden in detaillierter Form vorgehalten, etwa als kleine User-Stories.
  • Items, die erst in mehreren Wochen umgesetzt werden sollen, kann das Team als mitteldetaillierte große User-Stories vorhalten.
  • Noch weiter von einer Umsetzung entfernte Items können die Form grober Epics haben.

Das zeigt, dass in einem optimalen Product Backlog keinesfalls alle Anforderungen bis ins kleinste Detail ausformuliert sind. Die feine Bestimmung von Items erfolgt immer erst in den Wochen vor der Umsetzung. Denn: In der agilen Software-Entwicklung gehen wir davon aus, dass sich das Umfeld und wir selbst (mit unseren Erfahrungen und Erkenntnissen) ständig weiterentwickeln. Demnach ist heute noch nicht fixiert, was in ein paar Monaten auf welche Weise umgesetzt wird.

Emergent: Sich entwickelnd

Ein Product Backlog ist nicht in Stein gemeißelt, sondern wird ständig gemeinsam von Product Owner und Team und mit Unterstützung des Kunden, der Anwender und weiterer Stakeholder weiterentwickelt. Dies erfolgt z.B. im Rahmen von sog. Backlog-Grooming-Workshops, in denen alle Beteiligten zusammen am Product Backlog arbeiten und diesen für die nächste Zeit aufbereiten.

Estimated: Beschätzt

Das Product Backlog sollte beschätzt sein. Für die Beschätzung gibt es zahlreiche erprobte Verfahren, etwa den Planning Poker oder das Estimation Game. Im Rahmen expliziter Schätz-Meetings oder auch bei der Durchführung von Backlog-Grooming-Workshops kann man sicherstellen, dass eine Beschätzung durch das Team für alle Backlog-Einträge vorliegt. Für Backlog-Items, die noch weit von einer Umsetzung entfernt sind, wird eine ganz grobe Schätzung vorgenommen.

Prioritised: Priorisiert

Die geplanten Aufgaben sollten stets priorisiert sein. Diese Priorisierung des Product Backlogs wird vom Product Owner vorgenommen und sichergestellt. Dabei steht er in enger Abstimmung mit den Stakeholdern und verschafft sich einen tiefen Einblick in die Marktentwicklung.

Diese grundlegenden Eigenschaften eines guten Product Backlogs geben eine erste Orientierung. Wichtig ist, dass das Backlog gemeinsam mit dem Kunden und dem Team erarbeitet und weiterentwickelt wird. So lässt sich sicherstellen, dass die Software den maximalen Nutzen für Kunden und Anwender generiert. Das Product Backlog sollte außerdem gut sichtbar und einfach zugänglich sein, ein Product Backlog Board kann hierbei eine große Hilfe sein.

Dieser Artikel wurde in ähnlicher Form am 20. Dezember 2011 im Blog Produktmanager-Internet.de unter dem Titel Was kennzeichnet ein gutes Product Backlog? von Paul Herwarth von Bittenfeld veröffentlicht. Paul Herwarth von Bittenfeld arbeitet seit 2003 bei //SEIBERT/MEDIA und für die Tochtergesellschaften Gartentechnik.com, TwentyFeet und naturkostaktiv. Weitere Fachartikel des Autors finden Sie in unserem Special Produktmanagement.

Hinterlassen Sie eine Antwort

Kommentare