Der Scrum Guide bezeichnet jedes Element, das sich im Product Backlog befindet, als Product Backlog Item (kurz PBI). Der Grund dafür liegt natürlich darin, dass Scrum lediglich ein Framework ist. Deshalb kann es auch keine konkreten Vorgaben dazu machen kann, was ein sinnvolles Item für Dein Produkt ist.
Per Definition ist daher alles, was Dein Scrum Team im Product Backlog festhält, automatisch auch ein Product Backlog Item. Das beginnt also bei Spezifikationen und Anforderungen an das Produkt, geht über User Stories, Features oder Epics bis hin zu zeitlich begrenzten Analyseaufgaben wie beispielsweise Spike Stories.
Übliche Product Backlog Items
Das sind beispielsweise:
Merkmale eines Product Backlog Items
Trotz aller Unterschiedlichkeit und Vielfalt gibt es einige gemeinsame Merkmale für (gute) Product Backlog Items.
Beschreibung
Jedes PBI sollte ausreichend beschrieben sein, damit klar ist, was das Ziel bzw. der Sinn und Zweck dieses Backlog Elements ist. Je nach aktueller Position in Deinem Product Backlog kann der Detailgrad dieser Beschreibung natürlich mehr oder weniger hoch sein. Befindet sich ein Item weit unten im Backlog kann ein PBI deutlich ungenauer sein, als wenn es sich weit oben befindet und (höchstwahrscheinlich) im nächsten Sprint umgesetzt werden soll.
Wert
Für jedes PBI sollte klar sein, welchen Wert es für das Produkt stiftet. Denn falls es keinen Wert stiften sollte, stellt sich die Frage, warum es sich dann im Product Backlog befindet. Der Wert eines PBI ist für Dich als Product Owner außerdem ein wichtiges Merkmal, nach dem Du Dein Product Backlog priorisierst.
Schätzung
Ein gutes PBI sollte außerdem mit einer Schätzung versehen sein, damit allen Beteiligten klar ist, wie viel Aufwand es sein wird, es umzusetzen. Üblicherweise geschieht diese Schätzung in agilen Teams mit Hilfe von Story Points. Allerdings ist auch das lediglich eine etablierte Praxis und keine Vorgabe des Scrum Guides.
Manchmal kann der Aufwand, der in ein PBI fließen soll, auch zeitlich begrenzt sein. Das heißt, die Arbeit daran wird auch dann beendet, wenn es nach einer vorher festgelegten Zeit nicht komplett abgeschlossen werden konnte. (Spike Stories sind hierfür ein gutes Beispiel.)
Position
Je nachdem welchen Wert ein Backlog Element hat und wieviel Aufwand es (voraussichtlich) sein wird, es umzusetzen, hat es eine Position im Product Backlog. Das gewährleistet, dass Dein Product Backlog nicht einfach nur ein großer Topf mit Aufgaben ist, aus dem sich Dein Scrum Team im Sprint Planning bedient.
