5 4 Votes
Artikel-Rating

Das Product Backlog (oder kurz PBL) ist eines von drei Scrum Artefakten. Wie das Sprint Backlog und das Increment 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 Prozesskontrolle 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.

Merkmale eines guten Product Backlogs

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.

Das Product Backlog ist emergent

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.

  • Das macht es natürlich notwendig, dass Du Dein Backlog kontinuierlich gemeinsam mit Deinem Team pflegst. Wie das genau funktioniert, erfährst Du in meinem Artikel Was ist Product Backlog Refinement?

Das Backlog besitzt eine Priorisierung

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.

Das Product Backlog ist die einzige Quelle für Arbeit

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.

Das Product Backlog gehört dem Product Owner

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.

Damit Du als Product Owner diese Rolle erfüllen kannst, musst Deine Organisation natürlich Deine Entscheidungen respektieren und Dich gewissermaßen ermächtigen, sie auszuüben.
0
Bist Du selbst Product Owner? Wie viel Hoheit über Dein Backlog hast Du tatsächlich?x

DEEP-Merkformel

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:

  • Detailed appropriately

  • Estimated

  • Emergent

  • Prioritised

Elemente im Product Backlog

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:

  • Bugs und technische Mängel

  • Impediments

  • Aufgaben zu Forschung & Entwicklung

Hierarchien im Product Backlog

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 im Product Backlog

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.)

Priorisierung des Product Backlogs

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.

Priorisierung durch ein Produktziel

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

Anhand Deines Produktziels kannst Du zum einen festlegen, ob der Wunsch eines Kunden oder Stakeholders überhaupt den Weg ins Product Backlog findet. Zum anderen kannst Du mit Hilfe Deines Produktziels auch die Priorisierung Deines Backlogs festlegen.
0
Nutzt Du bereits Produktziele zur Priorisierung? Wie sind Deine Erfahrungen damit?x

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.

Priorisierung mit Hilfe von OKR

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.

Priorisierung mittels Evidence-Based Management

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.)

Weitere Methoden zur Backlog Priorisierung

  • Eine Möglichkeit, Dein Product Backlog zu priorisieren, ist das MoSCoW-Prinzip von Dai Clegg.

  • Zweitens kann Dir in User Story Mapping Workshop dabei helfen, eine Sortierung in Dein Product Backlog zu bringen.

  • Willst Du durch die Priorisierung Deines Product Backlogs vor allem vermeiden, Verzögerungskosten zu generieren, solltest Du einen Blick auf die WSJF-Methode (Weighted Shortes Job First) werfen.

  • Viertens kannst Du das populäre Kano-Modell nutzen, um die Reihenfolge von Features in Deinem Product Backlog festzulegen. Es hilft Dir dabei zu erkennen, welche Features zur Kundenzufriedenheit beitragen und welche nicht.

  • Darüber hinaus ist da Innovation Game Buy a Feature ein interaktiver Workshop, mehr Klarheit über die Wünsche Deiner Nutzer zu erlangen und eine sinnvolle Reihenfolge von Features zu ermitteln.

Priorisierung für Fortgeschrittene: Opportunity Scoring

  • Legst Du den Fokus darauf, neuen Nutzen für Deine Kunden zu stiften, kann Dir bei der Priorisierung Deines Backlogs auch das sogenannte Opportunity Scoring helfen.

Die optimale Struktur eines Product Backlogs

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 einem Eurer nächsten Sprints 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

Optimale Struktur eines Product Backlogs

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.

Release Dates prognostizieren

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:

Release Burndown Chart mit Velocity Range

Fazit zum Product Backlog

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.