Das Product Backlog (und warum es DEEP ist)

Product Backlog DEEP
Von Sebastian Schneider // 05.06.2017 // 1 Kommentare

Das Scrum Product Backlog ist ein Artefakt in Scrum, in dem alle Anforderungen an ein Produkt stehen, die zum aktuellen Zeitpunkt bekannt sind. Es ist damit eine priorisierte Liste von Aufgaben. Die wichtigsten Aufgaben stehen immer oben. Das Product Backlog "gehört" dem Product Owner und er ist dafür accountable (rechenschaftspflichtig). Er steuert damit das Produkt hinsichtlich Kundennutzen und Wirtschaftlichkeit. Damit die im Product Backlog enthaltenen Aufgaben (Product Backlog Items, welches User Stories sein können) gut umgesetzt werden können, werfen wir in diesem Artikel zudem noch einen Blick auf das Akronym DEEP und auf den Lebenszyklus, den ein solchen Product Backlog hat.

Ein guter Product Backlog ist immer einer, der transparent und aktuell gehalten ist. Die PBI sind im Backlog absteigend der Wichtigkeit immer sortiert. Einen vollständigen Backlog gibt es nie - er spiegelt immer nur eine Momentaufnahme wieder.

Hinweis, sowohl das oder der Product Backlog und auch die unterschiedlichen Schreibweisen wie deutsch/englisch und mit und ohne Bindestrich werde ich für die Lesbarkeit des Artikels immer durch wechseln.

Der Lebenszyklus eines Product Backlogs

Lass uns gemeinsam einmal auf den Lebenszyklus eines Backlogs schauen und uns daran wichtige Eigenschaften, Termine und Aktionen reflektieren.

Die Erstellung

Wenn es ein Produkt gibt, dann gibt es auch ein Product Backlog dazu. Damit wird ein Product Backlog entweder bereits vor dem eigentlichen Produktstart geführt und mit ersten Inhalten gefüllt. Spätestens beim Start der Entwicklung benötigt der Product Owner dann ein solches Product Backlog.

Du kannst zum Beispiel das initiale Backlog Refinement (früher auch Backlog Grooming genannt) aus dem LeSS oder auch ein Story Mapping nutzen, um dir das Product Backlog zu erstellen. Es kann auch ein Brainstormig sein oder eine lose Sammlung. Das Product Backlog benötigt gerade zu Beginn erstmal noch keine formale Form.

Die Befüllung

Ein Product Backlog kann jederzeit verändert werden. Es ist keine statische Liste und wird auch nicht irgendwann "gefreezt". Somit kommen immer mal wieder neue Product Backlog Items dazu. In manchen Scrum Implementierungen schreibt der Product Owner alleine die User Stories und füllt damit das Product Backlog. In anderen Implementierungen schreibt das ganze Scrum-Team die Product Backlog Items und schreibt damit die Anforderungen.

Nur wenn etwas in diesem Product Backlog steht, dann hat es die Chance umgesetzt zu werden. Wenn es nicht in diesem Backlog steht, wird es definitiv nicht umgesetzt. Wann es umgesetzt wird, hängt maßgeblich von der Position im Product Backlog ab.

Die Benutzung

Das ganze Scrum-Team nutzt das Product Backlog. In den verschiedenen Events wird das Product Backlog verwendet. In der Sprint Planung überlegt das Scrum-Team, was und wie viel es schaffen kann. Im Daily Scrum wird der fixe Teil aus dem Product Backlog (der in das Sprint Backlog übernommen wurde) besprochen. In deinem Sprint Review werden die Einträge aus dem Product Backlog besprochen, die auch erledigt wurden und der Definition of Done entsprechen. Damit ist und bleibt das Product Backlog eine dynamische Liste an Anforderungen, die sich laufend ändert.

Das Ende

Wie lange existiert das Product Backlog? Im Grunde gibt es kein Ende eines Product Backlog. Wird der Sprint abgebrochen, weil der Sprint keinen Sinn mehr macht und wird danach auch kein Produkt weiter fortgeführt, dann endet auch ein Backlog. Auch wenn ein Produkt vom Markt genommen wird, findet auch das Product Backlog sein Ende. Wichtig ist aber zu verstehen, dass das Backlog immer eine emergente, sortierte Liste ist, die nie "fertig" ist.

Die Rollen beim Product Backlog

Werfen wir nun einen Blick auf die Rollen, die entweder mit den Inhalten oder am Artefakt selbst Hand anlegen.

Scrum Master

Der Scrum Master ist weniger der inhaltliche Mitspieler. Er unterstützt ggf. die erste Fassung des Product Backlog. Er hilft dem Product Owner das zu tun, erklärt der Organisation warum es das gibt und wie damit gearbeitet wird.

Product Owner

Der sogenannte Product Owner ist der Hauptmitspieler, wenn es um das Backlog geht. Du benötigst Training und Kenntnisse, die für eine gute Verkörperung der Rolle des Product Owners unverzichtbar sind.

Entwickler

Die Entwickler sind die Menschen, die mit dem Inhalt dieser Liste umgehen. Sie nutzen dieses als einzige Quelle der Anforderungen. Auch hier gilt wie bei vielen Quellen, Entwicklerteam Aufgaben oder generell Entwicklerteam verwenden wir nicht mehr. Wir nennen die Rolle nur noch Entwickler.

Stakeholder und andere Gruppen

Auch Stakeholder können Backlog-Einträge sehen und damit interagieren. Ob du das bei dir pauschal regelst, oder anderweitig ist natürlich eine Ausgestaltung, die bei dir liegt. Auch wenn du weitere Dienstleister über ein gut priorisiertes agiles Backlog steuerst, musst du dir Gedanken zur Sichtbarkeit machen. In Scrum versuchen wir natürlich alles in einem Team zu halten.

In welchen Terminen wird das Product Backlog verwendet?

Beim Thema Scrum spielen die Events natürlich eine Rolle und wir wollen aus Sicht der Product Backlogs mal auf die Termine schauen, in denen es verwendet wird.

Das Backlog ist allgegenwärtig

Das Product Backlog ist immer vorhanden, es ist transparent und deshalb immer und in jedem Event und Termin verfügbar. Jetzt gibt es natürlich durchaus Termine, in denen es eine größere Rolle spielt. Wichtig ist aber, es ist nicht schwarz und weiß. Es muss immer vorhanden sein und auch durchgängig aktuell und transparent.

Die Sprint Planung und das Sprint Review

Sowohl im ersten Event des Sprints, als auch im vorletzten gibt es einen besonderen Fokus auf unsere einzige Quelle der Anforderungen. Dann wenn wir planen schauen wir uns natürlich genau an, welche Einträge wir im Sprint auch wirklich bearbeiten können - besser ausgedrückt: Wie viele von den verfeinerten Einträgen! Regelmäßige Backlog-Reviews helfen dem Team, wie auch dem Kunden.

Das Daily Scrum und die Sprint Retrospektive

Im Daily Scrum und in der Sprint Retrospektive liegt der Fokus nicht direkt auf dem Product Backlog. Während du im Daily Scrum den Fokus mehr auf dem Sprint Backlog hast (im Grunde ein Teil des Product Backlogs oder auch "selected Backlog"), schaust du in der Retrospektive mehr auf die Zusammenarbeit und Interaktionen zwischen deinen Teammitgliedern.

Backlog Refinement / Backlog Grooming Session

Der Begriff Product Backlog Grooming existiert so nicht mehr. Nicht erst seit dem letzten Scrum Guide Update, sondern lange davor. Ich kann mich nicht mehr dran erinnern, aber inhaltlich stand der Begriff in der Bedeutung zu nah bei sexuellen Handlungen, so dass dieser so nicht mehr verwendet wurde und das Refinement es auch sprachlich viel besser trifft.

Wie ein Product Backlog aufgebaut ist

In diesem Abschnitt schauen wir uns an, wie ein Product-Backlog aufgebaut ist. Eines ist immer ganz wichtig: die höchste Priorität steht immer ganz oben! Doch ein gutes Product Backlog hat noch weitere Eigenschaften und diesen wollen wir uns nun mal widmen.

Welche Eigenschaften hat der Inhalt eines Product Backlog?

Egal in welchem Tool oder an welcher Wand du dein Backlog hältst. Es hat immer einige Eigenschaften, die sich als wertvoll und sinnvoll erwiesen haben. Der Inhalt eines Product Backlogs wurde einmal durch das sogenannte DEEP-Akronym definiert. Ich bin mir auch nicht mehr sicher, aus welcher Feder es letztendlich kam. Schauen wir uns nun einmal genauer an, wofür DEEP genau steht und was das genau bedeutet.

Das Akronym DEEP

DEEP steht für detailliert, emergent, estimated und priorisiert. Die Übersetzung hinkt natürlich etwas, aber ich denke, du verstehst, was ich meine. Lass uns diese einzelnen Faktoren der Reihe nach noch einmal durchgehen.

Detailliert

DEEP - Detailliert - Product Backlog

Product Backlog Einträge sind angemessen detailliert. Product Backlog Items sind entsprechend ihrer Position im Product Backlog detailliert. Je weiter oben, desto mehr sind diese verfeinert.

Emergent

DEEP - Emergent - Product Backlog

Product Backlog Einträge können sich verändern und tun dieses auch! Das Product Backlog ist nicht statisch oder abgeschlossen. Einträge können neu erzeugt und alte auch wieder entfernt werden.

Estimated

DEEP - Estimated Product Backlog

Product Backlog Einträge sind geschätzt. Zu jedem Product Backlog Item gehört auch eine Schätzung der Größe. Das agile Schätzen kann in unterschiedlichen Arten durchgeführt werden.

Priorisiert

DEEP - Priorisiert Product Backlog

Product Backlog Einträge sind relativ sortiert oder auch priorisiert. Jedes Product Backlog Item hat genau eine Position im Product Backlog. Somit ist immer klar, was das Wichtigste ist. Die wichtigsten Aufgaben stehen dabei immer oben. Das spiegelt auch die Priorität der Aufgaben wieder.

Welche Aufgaben sind im Product Backlog?

Grundsätzlich befinden sich alle Aufgaben im Backlog, die aktuell für das Produkt bekannt sind. Das können längerfristige Aufgaben sein oder aber welche, die im nächsten Sprint umgesetzt werden. Es gibt also nicht zwei Backlogs für ein Produkt, sondern immer nur eines. Die wichtigsten Punkte zur Entwicklung des Produkts erkennst du so unmittelbar. Doch auch technische Schulden können als Product Backlog Items existieren.

Die einzige Quelle für Anforderungen an das Produkt

Das Product Backlog ist die einzige Stelle, wo du neue Anforderungen für das Produkt festhalten kannst. Es gibt keine zweite Liste oder ein anderes Projekt, das Anforderungen an das Produkt definiert. Alles geht über den Product Owner der Inhaber des Product Backlogs und dafür auch accoutable ist.

Die Aufgaben im Product Backlogs

Die einzelnen Einträge in unserer sortierten Liste können ganz unterschiedlich sein. Wir haben schon gelernt, dass nicht nur neue Einträge enthalten sind, sondern alles was zum Produktrückstand gehört. Alles was wir aktuell über das Produkt wissen, welche Anforderungen etc. wir haben, stehen in unserer Liste.

Die Backlog-Einträge können z.B. folgendes sein:

  • Komplexe Aufgaben
  • Einfache Aufgaben
  • Kurzfristige Aufgaben
  • Langfristige Aufgaben

Wenn wir von Aufgaben sprechen, muss schon klar sein, dass wir die Inhalte von einem Produkt-Backlog sich möglichst an einem INVEST Akronym orientieren. Ohne jetzt zu sehr in die Details abzutauchen bedeutet das, dass wir immer etwas liefern wollen, was einen Wert generiert. So ist zum Beispiel auch die User Story aufgebaut.

Wie kannst du dein Product Backlog aufsetzen?

Um dein Product-Backlog zu erstellen kannst du recht einfach und ohne große Vorarbeit beginnen. Sobald du eine Idee hast, kannst du die Anforderungen und Wünsche aufschreiben - auf Klebezettel, in ein Tool oder ein Google Sheet. 

Ein Product Backlog Beispiel

Schauen wir uns nun kurz anhand eines beispielhaften Product Backlogs mal an, wie du so etwas konkret erstellen kannst. Nehmen wir an, wir haben einen Team, welches sich um einen Prozess im HR Bereich kümmert und das dieses auch das Produkt des Teams ist. Wenn wir ganz am Anfang stehen, wird es eine Vision geben und auch ein Produkt Ziel. Das überspringe ich nun an dieser Stelle, sondern wir schauen uns nur das Product Backlog Beispiel an. Der Product Owner würde starten und zum einen so ein Backlog erstellen und es transparent für alle gestalten - er kann auch mit Unterstützung arbeiten.

Als nächstes trägt er oder sie alles bekannte zu dem Prozess, was unser Produkt ja hier an der Stelle ist, ein. Dafür nutzt er natürlich die Eigenschaften, die wir oben beschrieben haben. Ein Beispiel könnte so aussehen:

  • Interviews mit mindestens drei Personen führen, um aktuelle Hindernisse im Prozess zu erkennen.
  • Einen ersten Prozessentwurf visualisieren
  • ...

Diese Beschreibungen sind nun noch nicht als User Story beschrieben und auch nicht nach dem INVEST Akronym. Das ist übrigens etwas ganz normales, was oft so ist. Es zeigt eben den aktuellen Stand der Entwicklung des Produktes.

Als nächstes werden die einzelnen Einträge Schritt für Schritt verfeinert. Das passiert dann im Backlog Refinement mit den Entwicklern. Hier könnte es zum Beispiel so sein, dass sich folgendes ergibt:

  • Als Anwender des HR Prozesses, möchte ich anhand eines Prozessentwurfes früh verstehen können, ob der neue Prozess die Schmerzpunkt adressiert.
  • Dann könnte es sein, dass du eine Schätzung von 8 Story Points vorfindest und
  • ein paar Akzeptanzkriterien wie zum Beispiel "2 Anwender wurden befragt"

Und so geht es dann weiter. Wenn die Entwickler entscheiden, das es gut genug für das gemeinsame Verständnis ist, dann kann so etwas in der Sprint Planung adressiert werden und für den nächsten Sprint auch ausgewählt werden.

Umsetzung von DEEP für das Product Backlog

Angemessenen Detaillierungsgrad erreichen

Ein Product Backlog ist immer angemessen detailliert. Doch was genau bedeutet angemessen? Die Frage des Detaillierungsgrades müssen wir in Abhängigkeit der Position im Backlog beantworten. Das Product Backlog ist dein Arbeitsvorrat für die Sprints. Das was in den nächsten Sprints bearbeitet werden soll, benötigt einen feineren Detaillierungsgrad, als vage Ideen, die sich am Ende des Backlogs befinden.

Im Backlog Refinement ist es deine Aufgabe diesen Detallierungsgrad zu erzeugen. Das spielt oft in die sogenannte (nicht offiziell existierende) Definition of Ready mit hinein. Nur wenn du Product Backlog Items bekommst, die angemessen detailliert sind, dann können diese auch in das Sprint Planning gelangen.

Mit der Emergenz richtig umgehen

Ein Product Backlog ist keine Spezifikation, die einmal zu Beginn geschrieben wird und dann final ist. Das Product Backlog ist lebendig, das bedeutet, dass sich laufend auch Dinge ändern können: Elemente werden hinzugefügt, entfernt oder verändert.

Diese Emergenz ist auch gewünscht, denn wir wissen, dass Anforderungen die über eine lange Zeit festgelegt werden, sich definitiv wieder ändern. Wir akzeptieren also die Unbeständigkeit der Anforderungen und versuchen aktiv damit umzugehen. Und aus diesem Grunde muss das Product Backlog auch emergent sein.

Schätzen von Einträgen

Jedes dieser Product Backlog Einträge benötigt eine Schätzung. Zumindest dann, wenn es bald in den nächsten Sprint aufgenommen werden soll. Die Schätzung in Scrum wird in der Regel in einem einfachen Schätzformat ausgedrückt (z.B. Story Points). Der Scrum Guide (auch 2020 Update) spricht grundsätzlich nur davon, dass die Einträge im Product Backlog eine Größe haben müssen - mehr nicht.

Auf der Backlog Ebene ist - im Gegensatz zur Sprint Ebene - die Art der Schätzung eine andere. Während wir auf Product Backlog Ebene sehr schnell schätzen wollen, ob Einträge in den Sprint gelangen oder nicht, gehen wir im Sprint Backlog dann in die Details, wenn nötig.

Wichtig ist zu verstehen, dass die Schätzungen die wir hier tätigen noch kein Waste sind. Sie sind schnell und trotzdem genau genug. Es reicht um festzustellen, ob etwas in den Sprint passt oder nicht.

Die Reihenfolge

Zu jedem Zeitpunkt ist klar, welches das wichtigste Element im Product Backlog ist. Und das bedeutet, es gibt zu keinem Zeitpunkt zwei gleichwichtige Elemente. Damit das klappt, arbeiten wir in Scrum gerne mit einer sogenannten relativen Priorisierung.

Relativ bedeutet dabei, das jedes Element (solange es nicht das erste oder letzte ist) immer ein Element hat das wichtiger ist und eines, das weniger wichtig ist. Also immer einen Vorgänger und Nachfolger. Das erste (und damit wichtigste) hat natürlich kein Element, das wichtiger ist. Und das letzte Element im Backlog keines, das weniger wichtig ist. Für alle anderen Elemente gilt aber genau dieser Sachverhalt.

Um noch mal zu klären, warum das so ist und sein muss. Wir rechnen in Scrum immer mit unvorhergesehenen Dingen. Es kann also passieren, dass uns das Geld im Projekt ausgeht, es wichtigere Dinge als unser Projekt plötzlich vorgeschoben werden oder ähnliches. Wenn wir immer genau wissen, was das wichtigste Element ist und wir uns nicht in negativen Multitasking verlieren, dann haben wir eine sehr gute Chance, dass die wichtigen Dinge auch abgeschlossen werden.

Ist das nicht klar und arbeitest du an zehn Dingen mit der Priorität "top", dann ist nicht klar, mit was du eigentlich starten sollest. Häufig fängt dann ein Team mit allem an und wird mit nichts so richtig fertig. Auch hier kann es helfen, sich noch mal mit der Priorisierung im Sprint zu befassen!

Zusammenfassung

Das Product Backlog ist das wichtigste Artefakt in Scrum, wenn es um Anforderungen geht. Mit dem Akronym DEEP hast du eine gute Reflexionsmöglichkeit, um zu überprüfen, ob dein Product Backlog eine gute Struktur besitzt. Wenn sich deine Einträge im Backlog dann auch noch an dem Akronym INVEST orientieren, dann bist du bestens gerüstet!

Sebastian Schneider ist dem Framework Scrum - es war Liebe auf den ersten Sprint - bereits seit 2005 verfallen. Seitdem begleitet er Unternehmen (meist größere) bei der Transition in eine neue Arbeits- und Produktwelt.

Dafür findet er den richtigen Grad zwischen zielgerichteten systemischen Impulsen und dem nachhaltigen Coaching in der Organisation, um diese bei der Entwicklung und Optimierung des eigenen Kundenmehrwerts zu unterstützen und entwickelt mit ihnen Produkte, die ihre Kunden lieben.

Im richtigen Maß gehören dazu die effektive und effiziente Facilitation dazu, sowie agile Spiele und Simulationen, die sein Themenfeld auf einfache Art begreiflichen machen.

Auf Konferenzen, sei es im Fachbeirat oder als Akteur, gibt er gerne Erkenntnisse weiter und freut sich über Kontakte von Angesicht zu Angesicht.

>