Das Product Backlog enthält die Features des zu entwickelnden Produkts. Es beinhaltet alle Funktionalitäten, die der Kunde wünscht, zuzüglich technischer Abhängigkeiten. Vor jedem Sprint werden die Elemente des Product Backlogs neu bewertet und priorisiert, dabei können bestehende Elemente entfernt sowie neue hinzugefügt werden. Hoch priorisierte Features werden von den Entwicklern im Aufwand geschätzt und in den Sprint Backlog übernommen. [Wikipedia2008]
Anforderungen werden im Product Backlog zentral gespeichert und vom Product Owner in Zusammenarbeit mit dem Team und anderen Interessensgruppen zusammengestellt.
Das Product Backlog wird vom Product Owner erstellt, gepflegt und verfeinert. Es enthält nur Funktionen und Artefakte aber keine Aktivitäten. Über diese entscheidet das Team, um die einzelnen „Logs“ zu bearbeiten. Zu Beginn des Projektes sind die Anforderungen nur grob beschrieben. Sie werden immer feingranularer beschrieben im Laufe das Projektes. Am Projektende erhält man eine detaillierte Dokumentation.
Während des Projektes gibt es also kein Change-Verfahren, dennoch ist eine Versionierung des Backlogs sinnvoll, um später Änderungen nachvollziehen zu können
Als Product Backlog können Karteikarten oder auch jede Art von Tabellen genutzt werden.
Eine solche Tabelle könnte folgende Spalten erhalten:
- Bezeichnung
- Priorität
- Thema
- Beschreibung
- Akzeptanzkriterien
- Aufwand
Je nach Anforderung können hier entsprechend im Laufe des Projektes weitere Spalten ergänzt werden. Die Gruppierung der inhaltlich ähnlicher Anforderungen zu einem Thema erleichtert den Überblick zu behalten, freigaben zu koordinieren und Prioritäten zu vergeben.
Eigenschaften eines Product Backlog
- Wird vom Product Owner erstellt
- Ist Basis für Releaseplan und liefert das Input für den jeweiligen Sprint
- Anforderungen werden während der Entwicklungsphase detailliert besprochen und geplant, nicht allein im Vorfeld
- Enthält keine Aktivitäten aber dennoch weitreichende Artefakte wie Entwicklungsumgebung, Tests, Funktionalität, Bugs, etc.
- Priorisierung nach Nutzen, Risiko, Kosten, (bspw. nach dem Kano Modell, Wert-Risiko Matrix) (Team unterstützt bei der Einschätzung technischer Risiken)
- Jeder Eintrag im Product Backlog enthält Schätzpunkte für den Aufwand, so können Kosten und Nutzen betrachtet werden (dies sollte vor einer Sprint Planungssitzung erfolgen, um Anforderungen besser priorisieren zu können, Aufwände für den nächsten Sprint zu vergleichen und fehlende Klarheit in den Anforderungen aufzudecken).
Anmerkung: Sprint & Product Backlog werden getrennt vorgehalten.
Detaillierungsgrad
Der Detaillierungsgrad eines Product Backlogs sollte das folgende Motto beherzigen:
So kurz und knapp wie möglich, so umfangreich und detailliert wie nötig.
Zu Beginn sollten in dem Product Backlog die wesentlichen Anforderungen genannt werden und für zwei bis drei Sprints ausreichen, um dem Team einen blick in die nächsten Schritte zu ermöglichen. Hierbei sind auch nicht-funktionelle Anforderungen wie user interface, performance, skalierbarkeit, benutzerbarkeit, etc.
Wichtige Anforderungen sollten entsprechend dem Fachwissen des Teams detaillierter beschreiben werden als unwichtigere.
Arbeitsschritte für das Füllen eines Product Backlogs (PB)
- Product Owner füllt das Backlog (bewusst grobgranular) mit den im Produktkonzept aufgeführten Eigenschaften, sowie (funktionalen als auch nicht-funktionalen) Anforderungen, die durch weitere Kundeninterviews und Workshops etc. ermittelt wurden. (PB-Status: initial befüllt)
- Product Owner gruppiert die Anforderungen zu Themen. (PB-Status: gefüllt und nach Themen gruppiert)
- Product Owner priorisiert in Zusammenarbeit mit dem Team die Themen (einzelne Anforderungen auch über Themngrenzen hinweg)(PD-Status: gefüllt, nach Themen gruppiert und priorisiert)
- Product Owner verfeinert die hochprioren Anforderungen mit Hilfe von Workshops und mit Hilfe des Teams. (PB-Status: ausreichend gefüllt, priorisiert und ausreichend detailliert um Sprint zu starten)
- Mittels Anforderungsworkshops werden existierende Anforderungen regelmäßig aktualisiert, verfeinert oder entfernt. Neue Anforderungen und Themen werden ggf. aufgenommen.
Risiken sollen frühzeitig angesprochen und dann als hochprior in das Product Backlog aufgenommen werden. Dies verhindert das späte aufkommen eines Krisenherdes, bei dem es dann schwer wird angemessene Entscheidungen und Gegenmaßnahmen treffen zu können. Bspw. Know-How Lücken, Kundenanforderungen unklar, etc.
