.st0{fill:#FFFFFF;}

Scrum Guide

Das Product Backlog (und warum es DEEP ist)

 Juni 5, 2017

von  Sebastian

In diesem Beitrag finden sich alle Details über das Product Backlog. Ich werde dazu ebenso das Akronym DEEP nutzen und wir werden es kennenlernen. Dieses DEEP ist im Zusammenhang mit dem Product Backlog sehr wichtig und hilft dir ein gutes Backlog zu erstellen, das sich perfekt für dein Produkt eignet.

DEEP steht im englischen für  detailled, emerget, estimated, prioritized,

Das Product Backlog

Ein zentrales Artefakt in Scrum ist das sogenannte Product Backlog. In diesem Backlog werden alle Anforderungen an ein Produkt oder eine Dienstleistung zusammen getragen. Der Product Owner ist für dieses Artefakt verantwortlich. Er steuert damit das Produkt hinsichtlich Kundennutzen und Wirtschaftlichkeit.

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.

Das Product Backlog ist das wichtigste Artefakt für die Anforderungen, die an das Produkt gestellt werden. Und genau auf diese Wichtigkeit stützt sich auf das Akronym DEEP. Wenn du DEEP erfüllst, dann hat dein Product Backlog eine gute Chance optimal in Scrum zu funktionieren. Neben den funktionalen Anforderungen die im Product Backlog stehen, gibt es auch noch die nicht-funktionalen Anforderungen, die du besser in deiner Definition of Done beschreibst.

Die einzige Quelle für Anforderungen an das Produkt

Das Product Backlog ist die einzige Stelle, wo du 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 und das Product Backlog.

Das Akronym DEEP

Schauen wir uns nun das Akronym DEEP für das Product Backlog einmal genauer an.

DEEP - Detailliert - Product Backlog

Detailliert

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.

DEEP - Emergent - Product Backlog

Emergent

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.

DEEP - Estimated Product Backlog

Estimated

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.

DEEP - Priorisiert Product Backlog

Priorisiert

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.

Umsetzung von DEEP für das Product Backlog

Angemessenen Detaillierungsgrad erreichen

DEEP - Detailliert - Product Backlog

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

DEEP - Emergent - Product Backlog

Ein Product Backlog ist keine Spezifikation, die einmal zu Beginn geschrieben wird und dann final ist. Das Product Backlog ist lebendig, das bedeutet... 

  • ... es werden neue Product Backlog Items hinzugefügt
  • ... bestehende PBI werden entfernt
  • ... die Reihenfolge der Product Backlog Items verändert sich

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

DEEP - Estimated Product Backlog

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 günstigen Schätzformat ausgedrückt (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, 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

DEEP - Priorisiert Product Backlog

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.

Sebastian

Ein paar Worte über den Autor

Agile Team Facilitator Sebastian Schneider
ICP-ACC Sebastian Schneider
Sebastian Schneider CSP
Sebastian Schneider CSP-PO

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.

  • {"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

    Sei auch mit dabei: Der Newsletter zu Scrum aus Augsburg.

    >