Wenn man mit Scrum arbeitet, stößt man bald auf eine Menge Abkürzungen. Man tippt und sagt „PO“ schneller als den ausgeschriebenen „Product Owner„. Und in einem Daily Scrum ist es einfacher, in einer langwierigen Konversation „ELMOOOOO“ (kurz für Enough, Let’s Move On) zu rufen, als unterbrechen zu müssen und zu sagen „Okay, wir haben jetzt sehr lange darüber gesprochen, sollen wir weitermachen?“. In diesem Beitrag geht es um ein weiteres Akronym, PBI: Product Backlog Item, manchmal auch „Item“, „Work Item“, „Ticket“, „Issue“ und „User Story“ genannt.
Was ist ein Product Backlog Item?
Das Product Backlog ist die Inventarliste, in der die zur Erreichung des Produktziels erforderliche Arbeit festgehalten und priorisiert wird (Scrum.org, 2020). Diese Arbeit kann auf unterschiedliche Weise beschrieben werden, zum Beispiel als Aufgaben, vage Ideen, User Stories oder zu lösende Probleme. Jedes einzelne Element, das in einem Product Backlog erscheint, wird als Product Backlog Item bezeichnet.
Ein Product Backlog Item ist also die Arbeit, die sich im Product Backlog befindet. Wenn man alle PBIs so klein und unabhängig wie möglich macht, ist es einfacher, nach dem Wert zu priorisieren. Wenn man von großen Ideen spricht, kommt man schnell zu dem Schluss, dass alle Ideen realisiert werden müssen, um ein gutes Produkt zu erhalten. Aber oft bestehen große Ideen aus mehreren kleineren Teilen.
Wenn Sie anfangen, über die Arbeit auf dieser kleineren Ebene nachzudenken, stehen die Chancen gut, dass Sie nicht wirklich alles machen müssen. Der große Vorteil der Arbeit mit Product Backlog Items ist, dass Sie mehr Einblick in all diese kleinen Teile bekommen und daher gezielte Entscheidungen treffen können: Was machen wir, was lassen wir (jetzt) sein?
Nehmen wir an, Ihr Ziel ist es, einen neuen Vergnügungspark zu realisieren. Sie können alles, was dafür getan werden muss, in einem Product Backlog organisieren und priorisieren. Denken Sie an die verschiedenen Attraktionen, das Catering, die Dekoration, die Vereinbarungen mit den Behörden und anderen Parteien, die verschiedenen Shows und so weiter. Jede einzelne Arbeit ist ein Product Backlog Item: das Karussell, eine Achterbahn, ein Restaurant, ein Imbiss, ein See, die Abstimmung mit einem Stadtrat, die Abendshow und so weiter.
Woraus besteht ein Product Backlog Item (PBI)?
Um die Idee, die hinter den PBIs steht, optimal zu nutzen, ist es hilfreich, für jeden Punkt zu beschreiben, was damit gemeint ist, worin der Mehrwert dieser speziellen Arbeit besteht, wie viel Arbeit sie – ungefähr – macht und welche Priorität sie im Vergleich zu anderen PBIs hat.
Beschreibung und Wert
Product Backlog Items beschreiben, was benötigt wird, um das Produktziel zu erreichen, und nicht, wie man es erreichen kann. Um die wertvollsten Lösungen zu finden, ist es hilfreich, wenn das gesamte Team versteht, worin der Mehrwert besteht. Wenn Sie einen Vergnügungspark für Teenager bauen, hat ein Karussell einen ganz anderen Wert als eine Achterbahn.
Priorität eines PBI
Auf der Grundlage des Mehrwerts können Sie dann Prioritäten setzen. Indem Sie die Prioritäten auf der Grundlage des Wertes setzen, vermeiden Sie, dass die ersten Sprints durch Vorbereitungsarbeiten verloren gehen. Je früher Sie überprüfen können, ob Sie an der richtigen Lösung arbeiten, desto konzentrierter können Sie in späteren Sprints vorgehen. Sie wollen also zunächst überprüfen, ob Teenager überhaupt einen Freizeitpark brauchen. Das ist bei einer Achterbahn wahrscheinlich leichter zu erreichen als bei einem Karussell.
Schätzung des Umfangs
Jedes Product Backlog Item sollte innerhalb eines Sprints geliefert werden können. Schließlich wollen Sie die Arbeit, wenn Sie sie beginnen, auch abschließen und validieren. Dazu brauchen Sie eine Vorstellung vom Umfang der Arbeit. Die Zuweisung von Story Points ist ein praktischer Weg, um innerhalb weniger Sprints eine gute Vorstellung davon zu bekommen, wie viel Arbeit Sie in einem Sprint erledigen können. Und ein Nebeneffekt: Wenn man weiß, wie viel Arbeit ein PBI ist, ist es auch einfacher, Prioritäten zu setzen.
Wer bestimmt die Product Backlog Items?
PBIs befinden sich in einem Product Backlog und das Product Backlog wird vom Product Owner verwaltet. Der Product Owner entscheidet, welche Anforderungen, Ideen und Arbeiten in das Product Backlog aufgenommen werden und welche nicht. Erst wenn eine Arbeit in das Product Backlog aufgenommen wird, wird sie zu einem Product Backlog Item. Der Product Owner bestimmt also die Product Backlog Items.
Der Product Owner kann dies jedoch nicht allein tun, sondern arbeitet dazu intensiv mit den verschiedenen Stakeholdern und den Entwicklern zusammen. Die Wünsche und Bedürfnisse der Endnutzer sind die wichtigste Quelle für einen Product Owner. Aber jeder, der Ideen oder Vorschläge hat, kann sie dem Product Owner unterbreiten. Letztlich entscheidet der Product Owner, ob es sich tatsächlich um relevante Arbeit handelt. Wenn ja, wird es zu einem Product Backlog Item.
Was ist der Unterschied zwischen einem PBI und einer User Story?
Der Hauptzweck von Product Backlog Items besteht darin, zu beschreiben, welche Arbeit gewünscht wird und warum sie wertvoll ist. Für alle PBIs ist es nützlich, auf einen Blick sehen zu können, von wem der Wunsch kommt, was der Wunsch ist und warum er relevant ist. Das ist genau das, was eine User Story beschreibt: wenn , will ich , damit ich.
User Stories sind also eine praktische Art, ein Product Backlog Item zu beschreiben. Aber nicht jedes PBI muss eine User Story sein. Dafür gibt es zwei Gründe:
- Das Product Backlog entwickelt sich ständig weiter. Elemente, die noch sehr umfangreich oder vage sind, können auch in Stichworten beschrieben werden. Was als „Checkout“ beginnt, kann sich nach einem Refinement zu einer User Story entwickeln, die beschreibt, wer einen Checkout will und warum.
- Es ist nicht sinnvoll, alle Arten von Arbeit als User Story zu beschreiben. „Das Schreiben eines Handbuchs über die Verwendung der Kasse“ kann zum Beispiel klar genug sein.
Eine User Story ist also eine der vielen Formen von Product Backlog Items. Während eine User Story immer ein Product Backlog Item ist, muss nicht jedes Product Backlog Item eine User Story sein. Vergleichen Sie es mit dem Tierreich: Das Product Backlog ist die Sammlung aller Arten von Tieren. Alles, was im Product Backlog steht, ist also ein Tier. Einige dieser Tiere sind Löwen. Jeder Löwe ist ein Tier, aber nicht jedes Tier ist ein Löwe.
