Als Projektleiter, Produktverantwortlicher oder Service-Eigentümer bzw. deren Berater bist Du mit folgenden Fragen konfrontiert:

  • Was hilft uns in der transparenten und dynamischen Verwaltung von Anforderungen an ein Produkt bzw. Service?
  • Worin besteht eine agile Dokumentationsalternative zur statischen Konzeptunterlage?
  • Wie sorgen wir dafür, dass die wichtigsten Bausteine einer Lösung den größten Fokus erhalten und zuerst erarbeitet werden?

Unterstützung findest Du im Product Backlog und dem damit verbundenen Management von Anforderungen.


Überblick

Ergebnis: Liste mit priorisierten Anforderungen an ein Produkt oder Service dokumentiert, transparent und abgestimmt

Teilnehmer: mind. 1 Person (besser: Entwicklungsteam)

Dauer: ab 2 Minuten (je Anforderung)

Utensilien: Notebook & Office Software oder Produktentwicklungs-Tools

Zweck

Mit einem Product Backlog dokumentierst und verwaltest Du alle bekannten und notwendigen Anforderungen an ein Produkt. Das Produkt kann dabei ein IT-System, eine Dienstleistung oder ein andere neu bzw. weiterzuentwickelnde Lösung sein.

Anders als ein verabschiedetes und damit statisches Anforderungsdokument entwickelst Du ein Product Backlog während des gesamten Produktlebenszykluses stetig weiter. Sofern das Produkt existiert, existiert auch das dazugehörige Product Backlog.

Neue Kundenbedarfe, politische, soziale, rechtliche umweltspezifische und technische Entwicklungen können zu neuen, geänderten oder obsolet gewordenen Anforderungen und damit Änderungen im Backlog führen. Da sich Anforderungen permanent ändern ist Dein Product Backlog ein lebendes Artefakt. Als einzige Anforderungsquelle an das Produkt bleiben seine Inhalte dynamisch und niemals abgeschlossen.

Seltene Synonyme für das Produkt Backlog sind die deutschen Begriffe Anforderungsspeicher, Anforderungsliste bzw. Produkt(rückstands)liste.


Aufbau

Product Backlog Eintrag

Ein Product Backlog besteht aus einer Menge von Produktanforderungen, den Product Backlog Einträgen auch Product Backlog Items genannt.

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

  • Features - neue Funktionen, Fähigkeiten und Verbesserungen
  • Defekte - Fehlerbehebungen, technische Aufgaben und Bug Fixing
  • Wissenserwerb - 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 zeitliche Aufwand zur Umsetzung
  • Wert (das 'Weshalb') - der Nutzen für Kunden und andere Zielgruppen

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.

Product Backlog
Struktur und Elemente eines Product Backlogs

Gerne kannst Du weitere Faktoren wie das Umsetzungsrisiko oder die Machbarkeit in die Priorisierung einbeziehen. Hoch priorisierte Einträge werden in der nächsten Entwicklungsphase umgesetzt, niedrig priorisierte Einträge müssen warten.

Product Backlog

Die Gesamtheit aller Anforderungen an das Produkt bzw. den Service bilden das Product Backlog. Je weiter oben dabei ein Eintrag im Backlog, desto…

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

Verantwortlich für das Product Backlog inklusive Inhalt, Verfügbarkeit und Sortierung ist der Product Owner. Als Eigentümer des Anforderungsspeichers verwaltet dieser die Einträge, verfeinert sie zusammen mit dem Entwicklungsteam und veranlasst das Team zur Schätzung bzw. Umsetzung.


Anwendung

Aufbau, Pflege und Verwaltung eines Product Backlogs ist eine kontinuierliche Aufgabe. Durchlaufe als Product Owner zusammen mit dem Entwicklungsteam folgende Schritte.

  • 1

    Verfeinern

    In der Rolle des Product Owners obliegt Dir die kontinuierliche Aufgabe der Backlog Entwicklung. Wann immer Du kannst…
    - ergänzt oder entfernst Du Backlog Einträge,
    - detaillierst Du die Beschreibungen,
    - legst Du die Prioritäten fest und
    - fixierst Du die Werte
    bzw. veranlasst jemanden anderen dies in Deinen Namen zu tun. Zudem stellst Du den lesenden Zugriff auf das Product Backlog für beteiligte Stakeholder sicher.

  • 2

    Kommunizieren

    Verbreite die Inhalte Deines Backlogs. Relevante Zielgruppen sind u.a.:
    - Entwicklungsteam und Betriebsverantwortliche
    - Nutzer, Käufer und Sponsoren des Produktes
    - Parallelprojekte, Projektprogramme und Gremien
    Zeige 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 zielgruppenspezifisch vor und kommuniziere so breit und detailliert wie erforderlich.
    Hole Rückmeldungen für die Präzisierung der Anforderungen ein.

  • 3

    Schätzen

    Aufwandsschätzung ist Aufgabe des Entwicklungsteams. Dieses führt für jede Anforderung 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 fällt die Schätzung aus.
    Präzisere Schätzungen entstehen auf der Basis von größerer Klarheit und Detailtiefe.
    Lasse das Entwicklungsteam beurteilen, wann eine Anforderung 'bereit' für die Umsetzung ist, die Schätzung für den Eintrag also belastbar ist.

  • 4

    Abarbeiten

    Entscheide welche Einträge aus Deinem Product Backlog in der bevorstehenden Entwicklungsphase abgearbeitet werden sollen. Starte ganz oben im Backlog mit den top priorisierten Anforderungen und übergeben diese an das Entwicklungsteam. Dieses verpflichtet sich auf die Umsetzung.
    Prüfe nach der Entwicklungsphase den Fertigstellungsgrad. Nicht (vollständig) erledigte Anforderungen wandern zurück ins Backlog.


Beispiele

Product Backlog für den Consulting Methodenkoffer

Untere Abbildung zeigt beispielhaft einen Ausschnitt des Product Backlogs für den Consulting Methodenkoffer. Die fünf Einträge repräsentieren die Anforderungen zur Ergänzung der digitalen Methodensammlung um den Baustein 'Product Backlog'.

Product Backlog
Beispiel für das Product Backlog des Consulting Methodenkoffers

Das initiale Desk Research zur Technik besitzt die höchste Priorität, gefolgt von der Beitragsredaktion und einer Qualitätsprüfung. Am Ende steht die Erstellung des Methodenspickers und der Vorlagen. Jeder Eintrag enthält den geschätzten Aufwand in Arbeitstagen.


Vor- & Nachteile

Pro

  • 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 begünstigt die Kommunikation zwischen den Anforderern (= Product Owner) und Umsetzern (= Entwicklungsteam).

Contra

  • Für klassische Organisationen ist das Konzept des Product Backlogs und dem mit ihm verbundenen dynamischen Verfeinerungsprozess neu und ungewohnt.
  • Ein Backlog setzt voraus, das ein Requirements Engineering gleichzeitig mit der Produktentwicklung stattfindet. Speziell bei der Ausschreibung und Vergabe von Festpreisentwicklungsleistungen an Externe ist diese Bedingung nicht immer haltbar.
  • Ohne das Prozessrahmenwerk Scrum und seine Meetings, Artefakte und Rollen entfaltet das Product Backlog nur mittleren Mehrwert.
  • Anders als das Kanban Board oder die Aufgabenliste zeigt das Product Backlog nur die offenen Aufgaben an. Die visuelle Motivation eine Sache erledigt zu haben bleibt aus.

Praxistipps

  • Tipp 1 - Zentral und einfach erreichbar ablegen

    Lege das Product Backlog  zentral und für jeden einsehbar ab. Mit wenigen Mausklicks sollte sich jeder Projektteilnehmer in Erinnerung rufen können, welche Aufgaben bzgl. des Produktes offen sind.

    Überführe zudem Anforderungen aus Meeting-Unterlagen, Arbeitsdokumenten und E-Mailkommunikation zentral in die wachsende Liste. Alle Anforderungen stehen somit an einer einzigen Stelle.

  • Tipp 2 - Anforderungen einheitlich formulieren

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

    Vereinbare mit dem Team, in welcher Form und welchem Detailgrad die Anforderungen beschrieben und modelliert werden müssen damit ein gemeinsames Verständnis besteht der Dokumentationsaufwand jedoch minimal bleibt.

  • Tipp 3 - Gegen andere Anforderungsdoku abgrenzen

    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. Der Fokus liegt auf den Details, dem ‘Wie’.
  • Tipp 4 - Ausschließlich für Anforderungen nutzen

    Das Product Backlog ist ein Anforderungsdokument und keine Sammlung von organisatorischen und inhaltlichen (Zwischen-)Resultaten.

    Ausgearbeitete Ergebnisse, gefällte (Entwurfs-)Entscheidungen, wichtige Randbedingungen, abgestimmte Terminpläne etc. gehören nicht in das Product Backlog, sondern ausschließlich Anforderungen an das Produkt.

  • Tipp 5 - Backlog Eintrag mit Augenmaß erweitern

    Je nach Bedarf kannst Du einen Product Backlog Eintrag durch zusätzliche Attribute wie Anforderungskategorie, -abhängigkeiten oder -quelle ergänzen.

    Bedenken jedoch: Jedes weitere Merkmal bedeutet wiederkehrend 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.

  • Tipp 6 - Zeit für Aufbau & Verfeinerung vorsehen

    Ein gutes Backlog ist ein aktuelles Backlog. Reserviere ausreichend Zeit für die Pflege Deines Anforderungsspeichers.

    Gerade die Initialanlage des Product Backlogs zu Beginn eines Produduktlebenszyklus gestaltet sich aufwendig, da Du zunächst alle bisher bekannten Anforderungen aufnehmen und (zumindest rudimentär) dokumentieren wirst.

    Auch mit dem sich anschließenden Produkteinsatz, den Rückmeldungen der Kunden sowie dem Erfahrungsstand des Entwicklungsteams wächst Dein Backlog in Tiefe und Detailbreite beständig weiter.


Ursprung

Das Product Backlog ist eines von drei Scrum Artefakten und wurde wie das agile Prozessrahmenwerk selbst in den letzten Jahren sehr populär.

Der englische Begriff 'Backlog' steht dabei für Rückstau bzw. Auftragsbestand. Das Product Backlog bezeichnet demnach einen Nachholebedarf an Aufgaben, der sich über der Zeit bzgl. Deines Produktes angesammelt hat.


Bonusmaterial

YouTube

Mit dem Laden des Videos akzeptieren Sie die Datenschutzerklärung von YouTube.
Mehr erfahren

Video laden

Tommy Norman: How to Create a Scrum Product Backlog (8 min) - Nutzung des Product Backlogs im agilen Projektrahmenwerk Scrum

 

Zuletzt aktualisiert am 21. Oktober 2021 durch Dr. Christopher Schulz

PDFDrucken

Du möchtest Consulting Methodenkompetenz als Buch?

  • 24 erprobte Consulting Tools auf > 200 Seiten
  • Mein Erfahrungswissen als eBook und Print
  • Kompakt erklärt und einfach umsetzbar
  • An einer Stelle direkt zum Nachschlagen
  • Bereits über 4.000 zufriedene Leser



Gib ein Kommentar

Your email address will not be published.