Das Product Backlog – Anforderungen an ein Produkt verwalten

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.

---

Ergebnis: Dokumentierte, transparente und abgestimmte Liste mit priorisierten Anforderungen an ein Produkt oder Service

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.

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

---

Aufbau

Product Backlog Eintrag – „Was zeichnet eine Anforderung aus?“

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

Es gilt: Ein Eintrag für genau ein Thema. Jeder Eintrag enthält vier Attribute:

• Beschreibung (das ‚Was‘) – die aussagekräftige 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.

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 – „Welche Anforderungen haben wir an das Produkt?“

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 dem 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. Gehe regelmäßig durch die Liste und räume konsequent auf.

---

Beispiele

Product Backlog für den Consulting Methodenkoffer

Die 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‚.

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 & 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-Mails 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

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

• Christopher Schulz/palladio consulting: Das Product Backlog – Anforderungen flexibel und nutzenorientiert verwalten – Einbindung des Product Backlogs in das agile Rahmenwerk Scrum
• TPG: #25 Agiles Anforderungsmanagement (27 min) – Podcast zum Einsatz des Product Backlogs für das Anforderungsmanagement