Scrum-Leitfaden · Artefakte und Praktiken
Product Backlog in Scrum: was es ist und wie Sie es managen
Das Product Backlog ist eine emergente, geordnete Liste dessen, was zur Verbesserung des Produkts nötig ist. In Scrum ist es die einzige Quelle der Arbeit, die das Scrum Team übernimmt, und sein Commitment ist das Produktziel.
Das Wichtigste in Kürze
- Das Product Backlog ist eine emergente, geordnete Liste und die einzige Quelle der Arbeit für das Scrum Team.
- Der Product Owner ist dafür verantwortlich; die Developers schätzen die Einträge.
- Sein Commitment ist das Produktziel, das dem Backlog die Richtung gibt.
- Halten Sie es kurz, geordnet und oben verfeinert, und entfernen Sie Einträge, die keinen Wert mehr stiften.
Was das Product Backlog ist
Das Product Backlog ist eines der drei Scrum-Artefakte, neben dem Sprint Backlog und Inkrement. Es enthält alles, wovon das Scrum Team derzeit annimmt, dass es dem Produkt Wert hinzufügen könnte: neue Features, Änderungen, Fehlerbehebungen, technische Arbeit, Recherche und Experimente.
- Emergent: Es ist nie vollständig. Einträge werden hinzugefügt, geändert und entfernt, während Team und Stakeholder dazulernen.
- Geordnet: Einträge haben eine klare Reihenfolge, sodass alle sehen, woran als Nächstes gearbeitet wird. Der Scrum Guide 2020 spricht von „geordnet“ statt „priorisiert“, weil die Reihenfolge neben der Priorität auch Wert, Risiko, Abhängigkeiten und Lernen widerspiegeln kann.
- Einzige Quelle der Arbeit: Wenn das Scrum Team daran arbeiten wird, sollte es im Product Backlog sichtbar sein.
- Eines pro Produkt: Mehrere Scrum Teams, die am selben Produkt arbeiten, teilen sich ein Product Backlog und einen Product Owner.
Wer das Product Backlog verantwortet
Der Product Owner ist für ein wirksames Product-Backlog-Management verantwortlich. Laut Scrum Guide 2020 umfasst das:
- Das Produktziel entwickeln und ausdrücklich kommunizieren.
- Product-Backlog-Einträge erstellen und klar kommunizieren.
- Product-Backlog-Einträge ordnen.
- Sicherstellen, dass das Product Backlog transparent, sichtbar und verstanden ist.
Der Product Owner kann andere bitten, einen Teil dieser Arbeit zu übernehmen, bleibt aber verantwortlich. Die Developers, die die Arbeit erledigen, sind für das Schätzen der Einträge zuständig, und der Scrum Master hilft dem Product Owner, wirksame Techniken für das Backlog-Management zu finden. Wer das Product Backlog ändern möchte, muss dafür den Product Owner überzeugen.
Das Produktziel
Das Produktziel beschreibt einen zukünftigen Zustand des Produkts, auf den das Scrum Team hinplant. Es steht im Product Backlog, und der Rest des Product Backlogs entsteht, um zu definieren, was es erfüllen wird. Das Team sollte ein Produktziel erreichen oder aufgeben, bevor es das nächste angeht.
| Ebene | Commitment | Beispiel |
|---|---|---|
| Product Backlog | Produktziel | Kunden können ihr gesamtes Konto online verwalten, ohne den Support anzurufen |
| Sprint Backlog | Sprint-Ziel | Kunden können frühere Rechnungen als PDF herunterladen |
| Inkrement | Definition of Done | Code geprüft, getestet, barrierefrei und in Produktion bereitgestellt |
Was in einen Product-Backlog-Eintrag gehört
Der Scrum Guide schreibt kein Format vor. Die Attribute variieren je nach Arbeitsbereich, doch die meisten Teams erfassen:
| Attribut | Zweck |
|---|---|
| Beschreibung | Was benötigt wird und warum; oft formuliert als User Story |
| Reihenfolge | Seine Position im Verhältnis zu anderen Einträgen |
| Größe | Eine Schätzung der Developers, zum Beispiel in Story Points |
| Akzeptanzkriterien | Bedingungen, die bestätigen, dass der Eintrag tut, was er soll |
| Wert oder Begründung | Das erwartete Ergebnis oder der erwartete Nutzen |
| Notizen und Links | Designs, Recherchen, Abhängigkeiten oder zugehörige Epics |
Einträge weit oben sind klein, klar und detailliert. Einträge weiter unten können größer und vager sein, weil zu früh ergänzte Details oft verschwendet sind. Einträge, die innerhalb eines Sprints fertiggestellt (Done) werden können, gelten als bereit für die Auswahl im Sprint Planning.
So managen Sie ein Product Backlog, Schritt für Schritt
- Halten Sie das Produktziel schriftlich fest und teilen Sie es mit Team und Stakeholdern.
- Erfassen Sie Ideen, Anfragen und bekannte Arbeit als Einträge, ohne sich vorerst um Details zu kümmern.
- Ordnen Sie die Einträge unter Berücksichtigung von Wert, Risiko, Kosten, Abhängigkeiten und dem, was das Team lernen muss.
- Verfeinern Sie den oberen Teil des Backlogs regelmäßig, damit die Einträge für die nächsten ein bis zwei Sprints klar und geschätzt sind; siehe Backlog Refinement.
- Nutzen Sie das Sprint Review , um den Fortschritt mit den Stakeholdern zu überprüfen und das Backlog anzupassen.
- Entfernen Sie Einträge, die das Produktziel nicht mehr unterstützen, damit das Backlog kurz und nützlich bleibt.
- Verfolgen Sie den Fortschritt in Richtung Produktziel mit einem Burnup-Chart oder einer Prognose; siehe Scrum-Kennzahlen.
Praxisbeispiel: ein kleines Backlog ordnen
Der Product Owner eines Online-Buchungsdienstes hat das Produktziel „Kunden können Termine buchen und ändern, ohne uns anzurufen“. Die Developers haben die Einträge geschätzt. Der Product Owner ordnet sie, indem er Wert gegen Größe und Risiko abwägt:
| Reihenfolge | Eintrag | Größe (Punkte) | Begründung für die Position |
|---|---|---|---|
| 1 | Online einen Termin buchen | 8 | Kern des Produktziels; ohne ihn ist nichts anderes nützlich |
| 2 | E-Mail-Bestätigung nach der Buchung | 3 | Hoher Wert, klein, verringert Nichterscheinen |
| 3 | Eine Buchung ändern oder stornieren | 5 | Verringert direkt die Zahl der Anrufe |
| 4 | Spike: Integration des Kalenderanbieters | 2 | Senkt das Risiko vor Eintrag 5 |
| 5 | Buchungen mit den Kalendern der Mitarbeitenden synchronisieren | 8 | Wertvoll, hängt aber von den Erkenntnissen des Spikes ab |
| 6 | Rabattcodes für Treuekunden | 13 | Für das aktuelle Produktziel nicht erforderlich |
Wenn die Velocity bei etwa 15 Punkten liegt, sind die Einträge 1 bis 3 (16 Punkte) etwas mehr als ein Sprint. Das Team könnte also die Einträge 1 und 2 plus den Spike einplanen und Eintrag 3 im nächsten Sprint angehen. Eintrag 6 kann entfernt oder bis zu einem späteren Produktziel zurückgestellt werden.
Product Backlog vs. Sprint Backlog
| Product Backlog | Sprint Backlog | |
|---|---|---|
| Inhalt | Alles, was das Produkt verbessern könnte | Sprint-Ziel, ausgewählte Einträge und ein Plan |
| Accountable (ergebnisverantwortlich) | Product Owner | Developers |
| Commitment | Produktziel | Sprint-Ziel |
| Zeithorizont | Die Lebensdauer des Produkts | Ein Sprint |
| Verändert | Immer wenn der Product Owner Einträge neu ordnet oder hinzufügt | Täglich, während die Developers dazulernen |
Häufige Fehler
- Ein Backlog, das nur wächst. Hunderte alter Einträge verdecken, was wichtig ist. Löschen oder archivieren Sie Einträge, die dem Produktziel nicht mehr dienen.
- Mehrere Backlogs für ein Produkt. Getrennte Team-Backlogs machen eine produktweite Reihenfolge unmöglich.
- Alles hat „hohe Priorität“. Die Reihenfolge ist eine strikte Abfolge, keine Sammlung von Kennzeichnungen.
- Zu viele Details zu früh. Detaillierte Spezifikationen für Einträge, die erst in Monaten anstehen, werden meist neu geschrieben.
- Der Product Owner arbeitet allein. Refinement funktioniert am besten in Zusammenarbeit mit den Developers und Stakeholdern.
- Kein Produktziel. Ohne es wird das Backlog zu einer Liste von Wünschen statt zu einem Plan für Wertschöpfung.
Kostenlose Vorlagen zu diesem Thema
Häufig gestellte Fragen
Was ist ein Product Backlog in Scrum?
Es ist eine emergente, geordnete Liste dessen, was zur Verbesserung des Produkts nötig ist, und die einzige Quelle der Arbeit für das Scrum Team. Sein Commitment ist das Produktziel.
Wer verantwortet das Product Backlog?
Der Product Owner ist dafür verantwortlich. Andere können beitragen und gebeten werden, einen Teil der Arbeit zu übernehmen, doch der Product Owner entscheidet über die Reihenfolge.
Wer kann dem Product Backlog Einträge hinzufügen?
Jeder kann Einträge vorschlagen, und in vielen Teams fügen Developers Einträge direkt hinzu. Der Product Owner bleibt für Inhalt und Reihenfolge verantwortlich.
Was ist der Unterschied zwischen einem priorisierten und einem geordneten Product Backlog?
Priorisieren bedeutet oft, Einträge als hoch, mittel oder niedrig zu kennzeichnen. Ordnen bedeutet, jeden Eintrag in eine einzige Reihenfolge zu bringen, die Wert, Risiko, Abhängigkeiten und Lernen widerspiegeln kann.
Wie hängt das Produktziel mit dem Product Backlog zusammen?
Es ist das Commitment für das Product Backlog: ein zukünftiger Zustand des Produkts, auf den das Scrum Team hinplant. Das Team arbeitet jeweils an einem Produktziel.
Wie groß sollte ein Product Backlog sein?
Dafür gibt es keine Regel. Ein Backlog, das zu lang ist, um es zu lesen und zu ordnen, wird schwer handhabbar. Viele Teams halten daher detaillierte Einträge für nur wenige Sprints vor und führen den Rest als größere, grobe Einträge.
Müssen Product-Backlog-Einträge User Stories sein?
Nein. Der Scrum Guide schreibt kein Format vor. User Stories sind beliebt, doch Einträge können auch Fehler, technische Aufgaben, Experimente oder einfache Beschreibungen sein.
Wer schätzt Product-Backlog-Einträge?
Die Developers, die die Arbeit erledigen, sind für das Schätzen zuständig. Der Product Owner kann ihnen helfen, Einträge und Zielkonflikte zu verstehen.
Wann ist ein Product-Backlog-Eintrag bereit?
Laut Scrum Guide gelten Einträge, die innerhalb eines Sprints fertiggestellt (Done) werden können, als bereit für die Auswahl im Sprint Planning. Manche Teams ergänzen eine optionale Definition of Ready.
Können mehrere Teams ein Product Backlog teilen?
Ja. In Scrum hat ein Produkt ein Product Backlog und einen Product Owner, auch wenn mehrere Teams daran arbeiten.
Ist das Product Backlog dasselbe wie ein Projektplan?
Nein. Es ist eine sich entwickelnde Liste für das Produkt statt eines festen Plans, kann aber zusammen mit Prognosen und einem Release-Plan.
Welche Tools kann ich für ein Product Backlog nutzen?
Alles von einer Tabelle oder Haftnotizen bis zu Tools wie Jira oder Trello. Siehe Scrum-Softwaretools.