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.
Mehr über die Creative-Commons-Lizenz erfahren