Es ist immer wieder faszinierend, auf welch unterschiedliche Product Backlogs man bei verschiedenen Kunden trifft. Scrum macht hier keine Vorgaben, so dass jeder frei ist, sein Backlog nach Lust und Laune zu gestalten. Ich stelle allerdings oft fest, dass Anspruch und Umsetzung weit auseinanderlaufen. Der größte Knaller war, dass ein Product Owner einem Team, das bereits seit mehreren Wochen mit einer (sehr mäßigen) Liste sprintete, ein paar Tage vor Ende des Sprints ein vierzigseitiges (40!) Dokument mit dem Titel “Product Backlog Sprint 1″ vorlegte. Die Argumentation für dieses Dokument war die, dass der Kunde sehr konventionell veranlagt sei, diese Art der Dokumentation für das Review (~ Lenkungsausschusssitzung) erwarte und mit einer Listendarstellung nichts anfangen könne. Das Team solle doch bitte dieses Dokument durchlesen und bestätigen, dass genau der beschriebene Inhalt im Review gezeigt würde. Muss ich erwähnen, dass der Inhalt des Dokuments von dem Selected Product Backlog abwich, das vor ungefähr fünf Wochen committed wurde?

Ich betrachte das Product Backlog als den Heiligen Gral eines Scrum Projektes. Es gibt nur einen Hüter des Grals (PO), er verspricht Glückseligkeit (Projektziel) und ist umgeben von einer Gemeinschaft, die Mangel leidet (sonst gäbe es ja kein Projekt).

Neben der inhaltlichen Komponente (wie sind die User Stories geschnitten, wie groß sind sie, folgen sie dem INVEST-Prinzip, …) erachte ich die Struktur des Product Backlogs als einen wichtigen Erfolgsfaktor. In der Vergangenheit habe ich sehr verschieden aufgebaute Product Backlogs angetroffen. Im Folgenden möchte ich eine Version vorstellen, die quasi ein best-of-breed aus meinen Erfahrungen darstellt und die ich als generische Grundstruktur für am besten halte. Sie soll lediglich eine Startstruktur bieten, man kann natürlich die eine oder andere Spalte weglassen oder hinzufügen, falls das Projekt es erfordert. Ich habe die Überschriften englisch gelassen, weil diese feststehenden Begriffe häufig auch in deutschsprachigen Projekten benutzt werden.

Definitionen und Beispiele der folgenden Aufstellung habe ich dem Buch “Scrum mit User Stories” von Ralf Wirdemann entnommen, das ich sehr empfehlen kann.

• ID
  Eindeutige Identifizierung, z.B. eine laufende Nummer (#4711) oder eine Kombination (TM-1904).

• Size
  Komplexität des Backlog Items (vgl. Artikel “Team Estimation Game“), die vom Team geschätzte Größe.

• [Epic]
  Wenn es sich um ein größeres Projekt handelt, kann es Sinn machen auch die Epics mit im Product Backlog aufzuführen. Epics sind große User Stories, die weder vernünftig geschätzt noch innerhalb eines Sprints entwickelt werden können (z.B. “Projektsuche”, “Benutzerverwaltung”, “Rechnungsstellung”).

• [Theme]
  Themes sind eine Menge zusammengehöriger User Stories, die sich um ein bestimmtes funktionales Thema herum gruppieren. Themes werden manchmal auch Cluster, Feature Group oder ähnlich genannt. Eine gleichzeitiges Vorkommen von Epics und Themes in einem Projekt habe ich bisher allerdings noch nicht erlebt, in der Regel arbeitet man mit dem einen oder anderen Begriff.

• User Story
  Dies ist die eigentliche User Story, die der Struktur “Als … möchte ich … um zu …” folgt. Die User Story ist das Herz des Product Backlog, bei der Erstellung sollte man besondere Sorgfalt walten lassen.

• Acceptance criteria (How to demo)
  Akzeptanzkriterien helfen dem Team a) testgetrieben zu entwickeln, b) genau das zu liefern, was der Kunde haben will und c) sich frühzeitig auf das Review vorzubereiten. Leider werden sie häufig erst kurz vor dem Review geliefert (wenn überhaupt), was ihre Effektivität immens mindert.

• Required by
  Wer hat das Item ins Backlog gebracht? Diese Person kann ggf. weiterführende Informationen liefern, falls der Product Owner dies nicht kann.

• Notes
  Dieses Feld dient zur Aufnahme aller Informationen, die in den vorherigen Feldern nicht enthalten sind. Hier können z.B. Links zu detaillierteren Anforderungen stehen, Besonderheiten für den Test etc. Natürlich kann man auch neue Spalten für jeden Informationstyp kreieren, aber dann wird das Product Backlog schnell unübersichtlich.

Spätestens zu Beginn eines Sprints müssen diese Informationen für alle sprint-relevanten Backlog Items komplett vorliegen, um nicht in die anfangs skizzierte Situation zu geraten.

Außer Inhalt und Struktur ist auch der Ablageort des Product Backlogs sehr wichtig. Die Diskussion über dieses Thema würde den Artikel sprengen, daher möchte ich gern alle Leser einladen, ihre postiven oder negativen Erfahrungen mit Excel, Wikis, Tools etc. als Kommentar zu hinterlassen. Unabhängig vom gewählten Medium ist für mich ein Faktor sehr wichtig: Das Product Backlog muss “highly visible” sein. Jeder, der sich für das Product Backlog interessiert, muss intuitiv und zügig an das Product Backlog gelangen können. Wie kriegt Ihr das hin?

Über den Autor

Sven Röpstorff arbeitet freiberuflich als agiler Projektmanager und Coach mit über 16 Jahren Berufserfahrung. Mit seinen Teams probiert er gern neue Wege und Methoden, um sich und sein Umfeld stets weiter zu verbessern. In seinen Vorträgen und Workshops bringt er den Menschen agile Vorgehensweisen auf interessante und spielerische Weise nahe und macht sie somit sichtbar, fühlbar, erlebbar.