Das Product Backlog – Anforderungen flexibel und nutzenorientiert verwalten

Management Summary

• Als Kernartefakt des agilen Prozessrahmens Scrum enthält das Product Backlog alle Anforderungen an ein Produkt während des gesamten Lebenszykluses.
• Jeder Product Backlog Eintrag repräsentiert eine Anforderung und wird durch die Beschreibung, die Priorität, den Umsetzungsaufwand sowie den Kundenwert charakterisiert.
• Verantwortlich für das Product Backlog inklusive Inhalt, Verfügbarkeit und Sortierung ist der Product Owner. Dieser verwaltet die Einträge, verfeinert sie zusammen mit dem Entwicklungsteam und veranlasst das Team zur Schätzung bzw. Umsetzung.

Was ist ein Product Backlog?

Das Product Backlog ist eines von drei Scrum Artefakten und wurde wie das Prozessrahmenwerk selbst in den letzten Jahren sehr populär. Beim Konzept handelt es sich um eine dynamische Liste, in der Sie als Product Owner alle bekannten und notwendigen Anforderungen an Ihr Produkt – wie beispielsweise ein IT-System oder Service – geordnet festhalten.

Das Englische ‚Backlog‘ steht für Rückstau bzw. Auftragsbestand. Somit bezeichnet das Product Backlog einen Nachholebedarf an Aufgaben, der sich über der Zeit bzgl. Ihres Produktes angesammelt hat. Wir bevorzugen die deutsche Übersetzung Anforderungsspeicher.

Neue Kundenbedarfe, politische, soziale, rechtliche umweltspezifische und technische Entwicklungen können zu neuen oder geänderten Anforderungen und damit Änderungen im Backlog führen. Da sich Anforderungen permanent ändern ist Ihr Product Backlog ein lebendes Artefakt.

Anders als ein verabschiedetes und damit statisches Anforderungsdokument entwickeln Sie Ihr Product Backlog während des gesamten Produktlebenszykluses kontinuierlich weiter. Sofern das Produkt existiert, gibt es auch das dazugehörige Product Backlog. Als einzige Anforderungsquelle an das Produkt ist Ihr Backlog niemals abgeschlossen.

Tommy Norman: How to Create a Scrum Product Backlog (8min)

Welche Struktur besitzt das Product Backlog?

Ihr Product Backlog besteht aus einer Menge von Elementen, den Product Backlog Einträgen auch Product Backlog Items genannt. Ein Eintrag ist eine Anforderung an Ihr Produkt.

Gängige Product Backlog Einträge sind zum Beispiel:

• Features – neue Funktionen und Verbesserungen
• Defekte – Fehlerbehebungen, technische Aufgaben und Bug Fixing
• Wisssenserwerb – Ideen, Experimente und Erkenntnisse
• Technische Aufgaben – Infrastrukturaufgaben und Softwareinstallation

Jeder Eintrag enthält vier Attribute:

• Beschreibung (das ‚Was‘) – die Anforderungsdefinition,
• Priorität (das ‚Wann‘) – die Umsetzungsdringlichkeit
• Schätzung (dass ‚Wieviel‘) – der zeitlliche Aufwand zur Umsetzung
• Wert (das ‚Weshalb‘) – der Nutzen für Kunden und andere Zielgruppen

Je nach Bedarf ergänzen Sie zusätzliche Attribute wie Anforderungskategorie, -abhängigkeiten oder -quelle. Bedenken Sie jedoch: Jedes weitere Merkmal bedeutet zusätzlichen Pflegeaufwand. Ein nützliches Product Backlog Eintragsattribut ist der Status. So ist eine Anforderung ‚bereit‘ (engl. ready), sobald diese umgesetzt werden kann bzw. ‚erledigt‘ (engl. Done), sobald sie vollständig fertiggestellt ist.

Struktur und Elemente eines Product Backlogs

Die Priorität eines Product Backlog Eintrags hängt von seinem Wert sowie der Schätzung gegenüber den anderen Einträgen ab. Im Idealfall stiftet die Realisierung einer Anforderung einen hohen Nutzen bei günstigen Umsetzungskosten. Gerne können Sie weitere Faktoren wie das Umsetzungsrisiko oder die Machbarkeit in Ihre Priorisierung einbeziehen. Hoch priorisierte Einträge werden im nächsten Entwicklungssprint umgesetzt, niedrig priorisierte Einträge müssen warten.

Je weiter oben ein Eintrag in Ihrem Product Backlog steht, desto…

• höher ist seine Priorität und
• detaillierter sollte die Beschreibung, präziser die Schätzung und klarer der Wert ausfallen.

In der Praxis haben sich Epics und User Stories – textuelle Anforderungsdefinitionen in einem festen Format – für die Beschreibung eines Product Backlog Eintrags durchgesetzt. Aber auch andere Eintragsformen wie Use Cases, Einsatzszenarien oder Systemanforderungen wahlweise in Kombination mit Datenmodellen, State Charts oder Anwendungsfalldiagrammenn sind möglich. Aufwände hingegen werden häufig auf Basis von sogenannten Story Points oder T-Shirtgrößen (XL, L, S) angegeben und in sogenannten Planning Poker Runden verhandelt.

Wie wird das Product Backlog genutzt?

Wie wird nun mit dem Product Backlog gearbeitet? Unterscheiden Sie dazu am besten zwischen den verschieden Anwendungsfällen, die im Rahmen eines Entwicklungsprojektes auftreten.

Verfeinerung

In der Rolle des Product Owners obliegt Ihnen die kontinuierliche Aufgabe der Product Backlog Entwicklung. Wann immer Sie wollen…

• ergänzen oder entfernen Sie Backlog Einträge,
• detaillieren Sie die Beschreibungen,
• legen Sie die Prioritäten fest und
• fixieren Sie die Werte

bzw. veranlassen jemanden anderen dies in Ihrem Namen zu tun. Zudem stellen Sie den lesenden Zugriff auf das Product Backlog für beteiligte Stakeholder sicher, sorgen damit für Transparenz. Laut Scrum dürfen theoretisch auch Dritte Ihr Backlog ändern. Letztlich behalten Sie als Product Owner jedoch die Veranwortung für die Anforderungssammlung.

Gerade die Initialanlage des Product Backlogs zu Beginn eines Produduktlebenszyklus gestaltet sich aufwendig, da Sie zunächst alle bisher bekannten Anforderungen aufnehmen und (zumindest rudimentär) dokumentieren müssen. Auch mit dem sich anschließenden Produkteinsatz, den Rückmeldungen der Kunden sowie dem Erfahrungsstand des Entwicklungsteams wächst Ihr Backlog in Tiefe und Detailbreite beständig weiter.

Scrum nennt diese Entwicklungsaktivitäten das Refinement, zu Deutsch Verfeinerung. Als Product Owner dürfen Sie gemäß dem Prozessrahmenwerk das Entwicklungsteam (engl. Development Team) einbeziehen, sollten jedoch nicht mehr als 10 Prozent von dessen Kapazität beanspruchen. Ob Sie Regel-Refinement-Meetings vereinbaren oder die Vefeinerung in Blocktermine vorantreiben – Scrum macht hierfür keine Vorgaben. Ein offizielles Product Backlog Refinement Meeting gibt es nämlich nicht. Das Scrum Team entscheidet.

Die Product Backlog Einträge, die das Entwicklungsteam im anstehenden Sprint umsetzen soll, müssen Sie soweit verfeinern, dass jeder von ihnen innerhalb des Sprints fertiggestellt werden kann. Vereinbaren Sie mit dem Entwicklungsteam, in welcher Form und welchem Detailgrad die Anforderungen beschrieben und modelliert werden müssen damit ein gemeinsames Vertständnis besteht der Dokumentationsaufwand jedoch minimal bleibt.

Kommunikation

Als Product Owner sind Sie in der Pflicht die Inhalte des Product Backlogs zu kommunizieren. Relevante Zielgruppen sind u.a.:

• Entwicklungsteam und Betriebsverantwortliche
• Nutzer, Käufer und Sponsoren des Produktes
• Parallelprojekte, Projektprogramme und Gremien

Zeigen Sie mit dem Product Backlog an, für welche Anforderungen das Entwicklungsteam als nächstes, später und irgendwann einmal eine Lösung umsetzen wird. Gehe Sie zielgruppenspezifisch vor und kommunizieren Sie so breit und detailliert wie erforderlich.

Schätzung

Aufwandsschätzung ist Aufgabe des Entwicklungsteams. Dazu führt das Team für jede Anforderung, die Eingang in Ihr Product Backlog findet, initial eine Grobschätzung durch. Je näher nun die Umsetzung rückt – der Eintrag im Backlog also immer weiter nach oben rutscht und an Priorität gewinnt – desto genauer sollte die Schätzung ausfallen.

Präzisere Schätzungen entstehen auf der Basis von größerer Klarheit und Detailtiefe. Als Product Owner sind Sie hier in der Bringschuld. Regen Sie zudem an, zwischen dem besten und dem schlimmsten Fall zu unterscheiden, um unvorhergesehene Schwierigkeiten einzukalkulieren und Zeitverzögerungen zu vermeiden.

Laut Scrum findet die Schätzung im Rahmen des kontinuierlichen Refinements sowie als Teil des Sprint Planning Treffens zu Beginn eines Umsetzungszykluses statt. Lassen Sie das Entwicklungsteam beurteilen, wann eine Anforderung ‚bereit‘ für die Umsetzung ist, der Eintrag also ausreichend verfeinert wurde und die Schätzung belastbar ist.

Auswahl & Abarbeitung

Im Sprint Planning Meeting entscheiden Sie als Product Owner, welche Einträge aus Ihrem Product Backlog im bevorstehenden Sprint abgearbeitet werden sollen. Sie starten dazu ganz oben im Backlog mit den top priorisierten Anforderungen und übergeben diese an das Entwicklungsteam. Dieses verpflichtet sich auf die Abarbeitung.

Alle im Sprint umzusetzende Anforderungen hält das Entwicklungsteam im Sprint Backlog fest. Nach dem Sprint überprüfen Sie im Sprint Review Meeting, welche Anforderungen des Sprint Backlogs erfüllt wurden, also als ‚erledigt‘ zu bewerten sind. Anforderungen, die nicht erfüllt wurden, überführen Sie zurück in Ihr Product Backlog.

Wodurch grenzt sich ein Product Backlog zu anderen Anforderungsdokumenten ab?

Das Product Backlog ist eine Form Anforderungen zu dokumentieren und zu verwalten. Ein kleiner Überblick über weitere Anforderungsträger.

• Lastenheft: Beschreibt die Gesamtheit der Anforderungen des Auftraggebers an die Lieferungen und Leistungen eines Auftragnehmers (‚Weshalb‘ und ‚Was‘). Die Anforderungen sind statisch.
• Pflichtenheft: Beschreibt in konkreter Form, wie der Auftragnehmer die Anforderungen des Auftraggebers zu lösen gedenkt (‚Wie‘ und ‚Womit‘).
• Sprint Backlog: Enthält alle in einem Sprint umzusetzenden Anforderungen nebst einem Realisierungsplan und liegt unter der Hoheit des Entwicklungsteams. Nur dieses darf das Sprint Backlog ändern, beispielsweise indem es abgeleitete Aufgaben (engl. Sprint Tasks) ergänzt.

Worin bestehen die Stärken & Schwächen eines Product Backlogs?

Vorteile

• Anders als statische Anforderungsdokumente erlaubt das Product Backlog flexibel auf veränderte Umstände und Bedarfe zu reagieren. Jederzeit dürfen Anforderungen ergänzt, geändert oder entfernt werden.
• Das Product Backlog fördert eine ‚Just-in-Time and Just-Enough‘-Spezifikation. Nicht alle, sondern nur die wichtigsten Anforderungen müssen detailliert beschrieben werden.
• Das für alle offene und allzeit einsehbare Product Backlog fördert die Kommunikation zwischen den Anforderern (= Product Owner) und Umsetzern (= Entwicklungsteam).

Nachteile

• Für klassische Organisationen ist das Konzept eines Product Backlogs und dem mit ihm verbundenen dynamischen Verfeinerungsprozess neu und ungewohnt.
• Ein Backlog setzt voraus, das ein Requirements Engineering gleichzeitig mit der Produktentwicklung Speziell bei der Ausschreibung und Vergabe von Festpreisentwicklungsleistungen an Externe ist diese Prämisse nicht immer haltbar.
• Ohne das Prozessrahmenwerk Scrum und seine Artefakte, Rollen und Aktivitäten stiftet ein Product Backlog nur geringen Mehrwert.

Fazit

Das Product Backlog ist ein mächtiges Werkzeug in der agilen Neu- und Weiterentwicklung eines Produktes. Statt auf ein statisches Set detailliert formulierter Anforderungen, setzt das Konzept auf eine dynamisch wachsende Liste von gewünschten Produkteigenschaften und Funktionen. Probieren Sie den flexiblen Anforderungsspeicher einfach einmal aus.

Leseempfehlungen

• James, M.: Product Owner PSPO 1 Scrum Product Owner Certification Prep, Udemy Online Kurs (letzter Abruf: 18.11.2020)
• McGreal, D., Jocham, R.: The Professional Product Owner: Leveraging Scrum as a Competitive Advantage, Addison-Wesley Professional, 2018
• Schwaber, K., Sutherland J.: Scrum Guide (Deutsch) 11/2017 (letzter Abruf: 18.11.2020)

Ob Initialaufbau oder Qualitätssicherung – wir helfen Ihnen mit Ihrem Product Backlog.
Kontaktieren Sie uns!

Bitte akzeptieren Sie unsere Datenschutzerklärung.