Was ist ein Product Backlog?

Das Product Backlog (oder kurz PBL) ist eines von drei Scrum Artefakten. Wie das Sprint Backlog und das Inkrement sorgt es dafür, Transparenz für alle Beteiligten zu erzeugen. Denn nur durch Transparenz wird Überprüfung & Anpassung (Inspection & Adaption) möglich. Gleichzeitig unterstützt Dich das Backlog bei der Priorisierung von Aufgaben für Dein Produkt. Damit ist es ein wichtiger Baustein, um empirische Prozesssteuerung zu ermöglichen, auf der das gesamte Scrum Framework basiert.

In diesem Beitrag vermittle ich Dir die die wichtigsten Eigenschaften eines gut organisierten Product Backlogs und gebe Dir ein paar grundlegende Tipps mit auf dem Weg, mit denen Du die eine oder andere Stolperfalle im Leben eines Product Owners umgehen kannst.

Der Scrum Guide gibt uns zum Product Backlog einige wichtige Informationen an die Hand:

The Product Backlog is an emergent, ordered list of what is needed to improve the product. It is the single source of work undertaken by the Scrum Team.

Einen weiteren wichtigen Punkt kannst Du im Abschnitt über den Product Owner entdecken:

Those wanting to change the Product Backlog can do so by trying to convince the Product Owner.

Diese Informationen sind natürlich erst einmal „recht dünn“. Schauen wir uns diese vier Aspekte deshalb noch einmal gemeinsam genauer an.

Komplexität führt dazu, dass Du zu Beginn eines Projektes oder einer Produktentwicklung noch nicht viel darüber weißt, was Dein Team tun muss, um sein Ziel zu erreichen.

Später kann es dann geschehen, dass bestimmte Features gar nicht mehr benötigt werden oder andere Dinge sich als viel wichtiger herausgestellt haben.

Deshalb ist Dein Product Backlog dynamisch (oder emergent). Es verändert sich permanent und wird daher auch gerne als living artifact bezeichnet.

In jedem PBL gibt es natürlich Dinge, die wichtiger sind als andere. Häufig bauen Funktionen eines Produktes aufeinander auf oder sind anderweitig abhängig voneinander. Gleichzeitig wollen natürlich Deine Stakeholder und Kunden (wenigstens ungefähr) wissen, wann sie mit bestimmten Features rechnen können.

Aus diesem Grund fordert der Scrum Guide, dass das Product Backlog eine geordnete Liste ist. Was nichts anderes bedeutet, als dass Dein Backlog priorisiert ist.

Viele Organisationen und Unternehmen verteilen notwendige Aufgaben, Bugs oder Anforderungen an ihre Produkte auf eine Unzahl an Quellen. Bugs werden in einem Ticketsystem verwaltet, Stakeholder fordern Features für Dein Produkt per E-Mail und dergleichen mehr. Dein Product Backlog kann aber nur dann Transparenz erzeugen, wenn alle Anforderungen an Dein Produkt an einem einzigen Ort versammelt sind.

Das bedeutet, dass Euer Team ausschließlich an dem arbeitet, was sich auch im Product Backlog wiederfindet.

Damit es seinen Zweck erfüllen kann, „koppelt“ Scrum das Backlog gewissermaßen mit der Scrum Rolle des Product Owners.

Das heißt, dass niemand etwas ins Product Backlog hineinschreiben kann bzw. darf, ohne das Einverständnis des Product Owners zu haben.

In seinem 2010 erschienenen Buch Agile Product Management with Scrum hat Roman Pichler die DEEP-Formel für ein gutes Product Backlog geprägt. Demnach sollte es folgende Eigenschaften aufweisen:

In Deinem Product Backlog können sich alle möglichen Aufgaben und ToDo’s befinden. Häufig wird dabei von User Stories gesprochen. Aber das ist eigentlich nicht richtig, da User Stories lediglich eine sehr weit verbreitete Form von Aufgaben darstellt. Der Scrum Guide selbst spricht daher auch nur von Product Backlog Items (kurz PBI). Grundsätzlich ist es deshalb auch denkbar, dass Du gar keine User Stories für Dein Backlog verwendest.

Mögliche Product Backlog Items sind beispielsweise:

Viele Product Backlogs sind darüber hinaus in verschiedene Hierarchiestufen unterteilt.

Auf diese Weise werden mehrere User Stories zu Features zusammengefasst und mehrere Features zu einem übergeordneten Epic.

Ob (und welche) Hierarchien Du für Dein eigenes Scrum Backlog nutzen möchtest, ist natürlich von diversen Faktoren abhängig. Falls Du beispielsweise Objectives & Key Results nutzt, ist es auch denkbar, User Stories (oder sogar Features) einem Key Result zuzuordnen.

Hierarchiestufen eignen sich für Dich als Product Owner ganz besonders für die Kommunikation mit Stakeholdern oder beim gemeinsamen Blick auf Dein Backlog in der Sprint Review. (Erfahrungsgemäß interessieren sich gerade interne Stakeholder weniger für einzelne User Stories, sondern stärker für neu verfügbare Features.)

Eine der spannendsten Aspekte ist die Frage nach der Priorisierung des Product Backlogs. Auch wenn sie sich nicht allgemeingültig beantworten lässt, spielt das Produktziel dabei eine ganz besondere Rolle.

Mit dem Update im November 2020 ist der Scrum Guide um das Produktziel erweitert worden, das als Scrum Commitment Teil Deines Product Backlogs ist.

Denn jedes Product Backlog Item, das nicht direkt auf Dein Produktziel einzahlt, sollte logischerweise relativ weit unten in Deinem Backlog zu finden sein. Diejenigen ToDo’s, die einen großen Effekt auf die Erreichung Deines Produktziels haben, stehen natürlich möglichst weit oben.

Nutzt Du in Deiner Organisation oder Team Objectives & Key Results, ist es auch denkbar, die Priorisierung Deines Backlogs anhand eines Objectives festzulegen. Das Objective tritt dann in diesem Fall an die Stelle Deines Produktziels.

Achte jedoch darauf, nur ein Objective zur gleichen Zeit zu verfolgen.

Auch Evidence-Based Management kannst Du zur Priorisierung Deines Backlogs heranziehen. Die Reihenfolge richtet sich dann am Strategic bzw. Intermediate Goal aus, das im Rahmen von EBM gesetzt wurde. (Auch hier ersetzt das EBM-Ziel das Produktziel bzw. ist das Produktziel.)

Hast Du eine Priorisierung in Deinem PBL festgelegt, musst Du gemeinsam mit Deinem Scrum Team daran arbeiten, dass diejenigen Backlog Items, die sich weit oben befinden, möglichst klein, detailliert und gut verstanden sind, während Items im unteren Bereich unklar und undefiniert sein können bzw. sogar sollten.

User Stories, die sich weit oben in Deinem Backlog befinden, werden (höchstwahrscheinlich) in einer Eurer nächsten Iterationen umgesetzt. Sind sie dann zu groß, unklar oder existieren Abhängigkeiten, führt das dazu, dass ihr mit sehr viel Unklarheit und Komplexität in Euren nächsten Sprint starten werdet. Sofern es möglich ist, solltet Ihr das natürlich vermeiden.

Umgekehrt erzeugt ein hoher Detailgrad bei Product Backlog Items, die sich weit unten in Deinem Backlog befinden, potenziell für doppelten Aufwand. Denn es wird fast immer so sein, dass sich die Gegebenheiten für solche User Story bereits wieder stark verändert haben, wenn sie dann endlich an der Reihe sind. Und dann müsst Ihr alles von vorne besprechen

Im Optimalfall werden Product Backlog Items immer weiter verfeinert, je mehr sie im Laufe der Zeit nach oben rücken.

Viele Teams nutzen eine Definition of Ready, um klare Kriterien zu haben, wann ein Product Backlog Item wirklich als „ready for a sprint“ gilt. Diese auch oft DoR genannte Liste birgt jedoch in meinen Augen mehr Gefahren als sie nutzen stiftet, da Scrum Teams dadurch schnell in klassisches Wasserfall-Denken verfallen können.

Das Backlog ist ein wichtiges Werkzeug für Dich als Product Owner, wenn es darum geht, potenzielle Release Dates für neue Features zu prognostizieren oder einschätzen zu können, wann ein Projekt abgeschlossen sein wird.

Dazu ist es allerdings wichtig, dass alle Product Backlog Items mit einer Schätzung versehen sind. (Eines der beiden „E“ der DEEP-Formel, die ich Dir weiter oben vorgestellt habe, steht genau deshalb für Estimated.) Über den Sinn eines vollumfänglich geschätzten Backlogs in Scrum scheiden sich allerdings die Geister.

Sollte es jedoch aus berechtigten Gründen notwendig sein, bereits zum Projektstart oder zu Beginn der Produktentwicklung alle Aufwände zu schätzen, empfehle ich Dir die Lektüre der folgenden Artikel, die dieses Thema sehr detailliert behandeln:

Ich hoffe, ich konnte Dir mit diesem Artikel den grundsätzlichen Aufbau des Product Backlogs ein wenig näher bringen. Falls Du noch offene Fragen, Anregungen oder Kritik hast, hinterlasse mir gerne einen Kommentar hier auf der Seite. Ich werde diesen Beitrag dann gerne erweitern, anpassen und verändern.