Product Backlog

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. Die Schätzung erfolgt im Estimation Meeting

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 im Laufe das Projektes immer fein granularer beschrieben. 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. Ich setze heute oft den TFS oder VSTS (Visual Studio Online) ein, da es den gesamten ALM-Prozess vom erstellen der Anforderungen, über die Entwicklung, das Testing bis hin zum Build- und Release-Management unterstützt. Dennoch habe ich auch sehr gute Erfahrungen mit Karteikarten gemacht. Wenn man die Backlog-Items oder auch die Aufgaben selbst auf Karteikarten wirklich in die Hand nehmen kann, dann ist die Verbindlichkeit, die Eigenverantwortung und Motivation meiner Meinung nach höher, als wenn die Aufgaben „virtuell“ verwaltet werden.

Eine solche Tabelle/Karteikarten könnte folgende Attribute enthalten:

  • Bezeichnung
  • Priorität (sollte eine eindeutige Zahl sein, um eine Rangfolge zu enthalten. Ansonsten kommt es dazu, dass 80% der Anforderungen die Prio „high“ haben.)
  • Thema (Kategorie / Feature / Epic)
  • Beschreibung
  • Akzeptanzkriterien
  • Aufwand im besten Fall in Story Points

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 (Story Points) 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 Backlog & Product Backlog werden getrennt vorgehalten.

Detaillierungsgrad des Product Backlog

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, Performanz, Skalierbarkeit, Benutzbarkeit, etc. zu betrachten.

Wichtige Anforderungen sollten entsprechend dem Fachwissen des Teams detaillierter beschreiben werden als unwichtigere.

Arbeitsschritte für das Füllen eines Product Backlogs (PB)

  1. 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)
  2. Product Owner gruppiert die Anforderungen zu Themen. (PB-Status: gefüllt und nach Themen gruppiert)
  3. 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)
  4. 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)
  5. Mittels Anforderungsworkshops werden existierende Anforderungen regelmäßig aktualisiert, verfeinert oder entfernt. Neue Anforderungen und Themen werden ggf. aufgenommen.
Product Backlog Process
Product Backlog Process

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.

Veröffentlicht in SCRUM

Schreibe einen Kommentar