Das Product Backlog ist eine geordnete, priorisierte Liste von Einträgen. Sie dient dazu, die einzelnen Schritte abzuleiten, die zur Erstellung des Produktes notwendig sind. Dieser Artikel bietet eine Übersicht zu den Eigenschaften und klärt die Rolle des Product Owners.
Was steht im Product Backlog?
Es gibt unterschiedliche Arten von Einträgen, die so genannten Product Backlog Items. Darunter fallen:
- Funktionale Anforderungen
- Qualitätsanforderungen
- Epics, grob gefasste User Stories, die später in mehrere detaillierte User Stories verfeinert werden
- User Stories, die aus der Sicht des Nutzers darüber aufklären, was dieser mit dem Produkt gern erreichen möchte und aus welchem Grund
- Bugs, also Fehler
- Verbesserungen
- Aktivitäten zum Know-how-Aufbau
Die Rolle des Product Owners
Der Product Owner verantwortet das Product Backlog und nutzt es als zentrales Instrument, um die Arbeit des Development Teams, also des umsetzenden Teams, zu steuern. Die Qualität des Product Backlogs hat maßgeblichen Einfluss darauf, wie erfolgreich das Development Team arbeiten kann.
Eigenschaften des Product Backlogs
Das Product Backlog weist fünf wesentliche Eigenschaften auf:
- Priorisiert
Die Einträge sind durch eine eindeutige Reihenfolge von oben nach unten priorisiert. So kann das umsetzende Team stets die bestmögliche Arbeit liefern und weiß, was für den Kunden wichtig ist und welche Punkte in welcher Reihenfolge während des Sprints erledigt werden sollen.
- Unterschiedlich detailliert
Die Einträge haben einen von oben nach unten abnehmenden Detaillierungsgrad. Während die obersten Einträge konkret ausgearbeitet sind und bestimmte Qualitätskriterien gemäß der Definition of Ready (DoR) erfüllen, sodass sie in den kommenden Sprints eingeplant werden können, ist der mittlere Bereich meist eher knapp und der unterste Bereich oft nur sehr grob formuliert. Bei der Ausarbeitung der Product Backlog-Einträge ist es üblich, dass aus einem groben Eintrag mehrere kleinere werden.
Darüber hinaus ist es möglich, ein mehrstufiges Product Backlog einzuführen. Hier sind die Einträge in Stufe drei noch unsortiert gesammelt. In Stufe zwei müssen sie dagegen schon bewertet und spezifiziert sein, um schließlich in der höchsten Stufe freigegeben zu werden. Erst mit diesem Informationslevel ist dann das Sprint-Planning-Meeting möglich.
- Geschätzt
Für jedes Product Backlog Item sollte eine grobe Schätzung des Umsetzungsaufwands vorgenommen werden. Für die obersten Einträge, die typischerweise detailliert ausgearbeitet und am besten verstanden sind, kann diese Schätzung präziser ausfallen. Wichtig ist in jedem Fall, dass diejenigen den Aufwand schätzen, die auch für die konkrete Umsetzung verantwortlich sind.
Es gibt verschiedene Arten, Anforderungen zu schätzen. In Scrum wird häufig das „Planning Poker“ verwendet. Hier bewertet das Team die Anforderungen nach bestimmten Kategorien von „sehr geringer Aufwand“ bis „extrem hoher Aufwand“.
- Bewertet
Der Wert oder Nutzen des zu entwickelnden Product Backlog Items für den Kunden ist das wichtigste aber nicht das einzige Kriterium für die Priorisierung des Product Backlogs.
Neben dem Business-Nutzen gilt es auch Abhängigkeiten, sinnvolle fachliche Gruppierungen von Funktionen und Maßnahmen für eine technisch gute Umsetzung und den Aufwand bei der Priorisierung zu berücksichtigen. Ist ein Item beispielsweise weniger aufwändig umzusetzen, hat es für den Kunden aber einen höheren Wert oder Business-Nutzen, so wandert dieser Punkt in der Liste weiter nach oben.
- Nicht in Stein gemeißelt
Im Rahmen der Verfeinerung, aber auch durch neue Erkenntnisse, veränderte Rahmenbedingungen, auftretende Fehler usw. können neue Product Backlog Items entstehen. Genauso ist es möglich, dass bestehende obsolet und gelöscht werden können. Umgesetzte Items werden als „done“ gekennzeichnet. Dazu stellt das Team zuvor die sogenannte Defintion of Done (DoD) auf, eine Menge von Qualitätskriterien, die erfüllt sein müssen, bevor ein Item tatsächlich als „done“ gekennzeichnet werden kann und darf.