Product Backlog
Die geordnete Liste aller Anforderungen für das Produkt
Zweck
Sammlung und Priorisierung aller bekannten Anforderungen, Features und Verbesserungen
Ein Product Backlog ist eine priorisierte Liste von Anforderungen, Funktionalitäten und Verbesserungsvorschlägen. Es organisiert alle aktuell bekannten Themen für die Produktentwicklung und ist niemals vollständig oder fertig - es entwickelt sich stetig weiter. Ein aktuelles Backlog gibt uns eine gemeinsame Orientierung von dem, was wir als nötig sehen, um unser Produktziel zu erreichen.
💡 Key Insight
Ein Backlog ist mehr als nur eine Sammlung von Anforderungen. Es ist unser strategischer Ausblick für die gemeinsame Produktentwicklung.
Der Ursprung des Backlogs
Backlogs in Scrum sind inspiriert aus der Nutzung von Backlogs in Finance und Logistik. In diesen Bereichen entstehen aus der laufenden Arbeit kontinuierlich neue zu erledigende Themen. Diese werden in Backlogs gesammelt und priorisiert, um sicherzustellen, dass trotz immer neu aufkommender Arbeit an den richtigen Dingen gearbeitet wird.
In diesem Sinne sind Backlogs keine statische Anforderungsliste, sondern spiegeln die aktuell vor uns liegende Arbeit wider. Diese Herangehensweise passt perfekt zur agilen Arbeitsweise: Wir streben danach, zügig aus der Lieferung minimaler Ergebnisse zu Produkt und Arbeitsweise dazu zu lernen.
Wichtig: Backlogs werden leider viel zu oft zu Planungswerkzeugen alter Schule umgedeutet. Die Ursprungsidee war aber immer, dass sie eine dynamische Anforderungsliste sind. Geht diese verloren, kann keine effektive agile Umgebung entstehen!
Bestandteile
- Product Backlog Items (PBIs)
- Priorisierung nach Business Value
- Schätzungen und Refinement
- Product Goal als langfristiges Ziel
Der Product Owner und das Backlog
Der Product Owner ist dafür zuständig, den zu schaffenden Mehrwert des Scrum Teams zu maximieren. Sein wichtigstes Werkzeug dabei ist das Product Backlog. Über die richtige Priorisierung schafft der PO es, den Fokus auf die richtigen Dinge zu setzen, um mit möglichst wenig Aufwand möglichst viel Nutzen zu erreichen.
Alleine kann ein PO dies aber nicht leisten. Der Product Owner ist auf die Zusammenarbeit mit den Stakeholdern und den Entwicklern angewiesen:
**Im Austausch mit Stakeholdern** versteht der Product Owner die Bedarfe, konsolidiert Wünsche in Richtung des Produktziels und trifft harte Fokusentscheidungen. Schließlich sind unsere Kapazitäten immer begrenzt.
**Mit den Entwicklern** gestaltet der PO das Backlog in effektiver Co-Creation aus. Die Aufgabe eines POs ist es nicht, die Entwicklung für das Team vorzudenken - das wäre kontraproduktiv! Entwickler liefern: - Feedback zur effektiven Ausrichtung - Frühes Feedback zu groben Backlog-Items - Identifikation von Risiken - Einschätzung des Aufwands - Vorschläge von Lösungsansätzen - Herunterbrechen von Backlog-Items
So ist gute Product Ownership ein Teamsport.
Best Practices
- ✓Halte 5-10 Items für den kommenden Sprint bereit
- ✓Biete strategischen Überblick über zukünftige Arbeit
- ✓Maximal 120 Items gesamt (Focus!)
- ✓Involviere Entwickler in kontinuierliches Refinement
- ✓Fokussiere auf Customer Value, nicht auf Tasks
Häufige Fehler
- ✗Backlog wie statischen Work Breakdown Structure behandeln
- ✗Zu detaillierte, vorschreibende Beschreibungen
- ✗Entwickler NICHT ins Refinement einbeziehen
- ✗Starre Deadlines hinzufügen
- ✗Unstrukturierte Liste von Tickets erstellen
Ein gutes Product Backlog ist DEEP: Detailed, Estimated, Emergent, Prioritized
Praktische Faustregeln für ein effektives Product Backlog
Ein Product Backlog kann verschiedene Item-Formate enthalten
Das Product Backlog als lebendige, dynamische Themenliste
DEEP Prinzipien für gute Backlogs
Ein gutes Product Backlog ist DEEP:
Detailed (Detailliert)
Unmittelbar bevorstehende Items sind konkret und klar, während weiter entfernte Items grober beschrieben sind. Wie bei einer Reise: Der Hinweg muss detailliert bekannt sein, über den Rückweg reicht erstmal zu wissen, wann er angetreten wird.
Emergent (Sich entwickelnd)
Das Backlog ist dynamisch und wird kontinuierlich gepflegt. Niemals sind von Anfang an alle Informationen bekannt. Es spiegelt immer unser jeweils aktuelles Verständnis wider, was zur Erreichung des Produktziels benötigt wird.
Estimated (Geschätzt)
Items haben Aufwandsschätzungen, die durch den Dialog beim Schätzen entstehen. Dies nutzt die Insights der Entwickler für bessere Backlog-Pflege und macht Priorisierung nach Wert und Aufwand möglich.
Prioritized (Priorisiert)
Das Backlog ist eindeutig sortiert. Die Priorisierung verdeutlicht die Abfolge und schafft Fokus. Dadurch können wir schnell an den wichtigsten Dingen arbeiten und minimale, wertvolle Ergebnisse liefern.
Vier Faustregeln für ein gutes Backlog
Menge: Fünf bis zehn Items für den Sprint
Items sollten so eingeteilt werden, dass ca. 5-10 in den Sprint einfließen können. Bei weniger als fünf Items leidet die Motivation (2 von 4 nicht geschafft = 50% Failure!). Bei mehr als zehn Items geht die Übersicht verloren.
Auswahl: Die 1,5- bis 2-fache Menge bieten
Um dem Team eine sinnvolle Auswahl sowie einen Ausblick zu ermöglichen, sollten 1,5-2x so viele Items "ready" sein. Zusammenhänge und Synergien können so besser bei der Auswahl berücksichtigt werden.
Ausblick: Strategischer Ausblick schafft Orientierung
Ein Backlog sollte immer einen strategischen Ausblick auf zukünftige Aktivitäten geben. Basierend darauf ist das Team in der Lage, sinnvolle Items zu wählen und Sprint-Ziele festzulegen.
Überblick: Max. 120 Items reduziert Komplexität
Ein Backlog sollte nicht mehr als 120 Items beinhalten. Es geht darum, größere Items früh zu erkennen und im Verlauf schrittweise herunterzubrechen. Items, die weiter in der Zukunft liegen, können der Übersichtlichkeit zuliebe gruppiert werden.
Product Backlog Refinement
Das Backlog Refinement bedeutet die kontinuierliche Pflege des Backlogs durch den Product Owner und das Entwicklungsteam. Früher wurde auch der Begriff "Grooming" verwendet, dieser wurde jedoch abgeschafft, nachdem deutlich wurde, dass er im British English eine negative Bedeutung hat.
Der Product Owner und sein Team: Der Product Owner ist grundsätzlich für die Backlog-Pflege verantwortlich. Jedoch macht es keinen Sinn, dass dieser sich völlig isoliert darum kümmert. Ein guter Product Owner bindet sein Team frühzeitig und regelmäßig in die Pflege mit ein.
**Wann genau?** Das Backlog Refinement ist kein fixes Scrum Event - dem Team ist völlig freigestellt, wann es diese Pflege durchführt. Ursprünglich war es Teil des <a href="/scrum/events/sprint-planning/" className="text-brand-600 hover:text-brand-700 font-medium">Sprint Plannings</a>, hat sich aber in der Praxis außerhalb etabliert. Teams können wählen: - Regelmäßig (z.B. jeden Mittwoch- oder Freitagnachmittag) - Häufig (z.B. täglich 15 Minuten nach dem Daily) - Just-in-time vor dem <a href="/scrum/events/sprint-planning/" className="text-brand-600 hover:text-brand-700 font-medium">Sprint Planning</a>
Wichtig dabei ist, dass es dem Team weiterhin möglich bleibt, sich auf den Sprint zu konzentrieren.
Häufig gestellte Fragen zu Product Backlog
Was zeichnet ein gutes Product Backlog aus?
Ein gutes Product Backlog zeichnet sich durch drei wesentliche Eigenschaften aus: Es hat einen passenden Detailgrad, wobei die obersten Items konkret und die weiter entfernten gröber beschrieben sind, um einen strategischen Ausblick zu bieten. Zweitens ist es eindeutig priorisiert (sortiert), um klaren Fokus zu schaffen und frühzeitig wichtige Entscheidungen zu treffen. Drittens ist es ein gelebtes Artefakt, das sich durch neue Erkenntnisse, Ideen und Veränderungen ständig weiterentwickelt und nicht als starrer Anfangsplan dient.
Wie viele Items sollten idealerweise in einem Sprint sein?
Es hat sich bewährt, fünf bis zehn Items pro Sprint anzustreben. Weniger als fünf Items können zu großen Fortschrittsschwankungen und Frustration führen, falls ein einzelnes Item nicht fertig wird. Mehr als zehn Items führen oft zum Verlust der gemeinsamen Übersicht im Team. Diese Faustregel unterstützt ein verlässliches Fortschrittstracking und die Team-Motivation, da der Ausfall eines Items weniger gravierend ist und die Arbeit in überschaubaren Paketen bleibt.
Wie viel vom Backlog sollte vor dem Sprint Planning 'ready' sein?
Es ist empfehlenswert, etwa das 1,5- bis 2-fache der Menge an Items im 'Ready'-Zustand zu haben, die ein Team typischerweise in einen Sprint zieht. Diese Auswahl ermöglicht dem Team im <a href="/scrum/events/sprint-planning/" className="text-brand-600 hover:text-brand-700 font-medium">Sprint Planning</a> ein unabhängiges und sinnvolles Votum, um ein rundes Paket zu schnüren. Es bietet Flexibilität, falls Items doch nicht fertig vorbereitet sind oder das Team schneller geworden ist, und verhindert, dass mangelnde Vorbereitung zum Engpass wird.
Wie groß sollte ein Product Backlog insgesamt sein?
Ein Product Backlog sollte überschaubar bleiben, idealerweise nicht mehr als 120-150 Items umfassen. Ab dieser Größe übersteigt es oft die kognitive Verarbeitungsfähigkeit des Teams, eine gemeinsame mentale Übersicht zu behalten. Ein zu großes Backlog wird zu einer unübersichtlichen Liste, in der man nur noch suchen kann. Größere Brocken sollten gruppiert oder als strategische Übersicht gehalten werden, um den gemeinsamen Gestaltungsdialog und das proaktive Risikomanagement zu ermöglichen.
Was für Einträge (Items) gehören in ein Product Backlog?
Im Backlog stehen priorisierte Items, die dabei helfen, ein wertvolles Produkt zu schaffen. Bewährt haben sich <a href="/scrum/artefakte/user-stories/" className="text-brand-600 hover:text-brand-700 font-medium">User Stories</a>, es sind aber auch Use Cases, Epics oder andere selbstdefinierte Formate erlaubt. Wichtig ist, dass es sich um übergreifende, wertorientierte Items handelt und nicht lediglich technische Aufgaben oder Gewerke (wie 'Design-Story', 'Code-Story') abgebildet werden. Das Ziel ist gemeinsame Produktentwicklung, nicht die Abbildung alter Arbeitsweisen in neuen Begriffen.
Wer ist für die Pflege und das Refinement des Product Backlogs verantwortlich?
Die Verantwortung für ein gut gepflegtes Backlog liegt beim Product Owner. Die erfolgreiche Pflege ist jedoch ein Teamspiel, das die frühe Einbindung des Entwicklungsteams erfordert. Das Team bringt entscheidende Insights für das Runterbrechen großer Items, für Schätzungen und proaktives Risikomanagement ein. Dieses gemeinsame Refinement stellt sicher, dass das Backlog formbar bleibt und frühzeitig minimale Items zur Validierung von Annahmen entstehen, was letztlich zu einem besseren Produkt führt.
Verwandte Events
Dieses Artefakt spielt in folgenden Scrum Events eine wichtige Rolle:
Nächste Schritte
Möchtest du mehr über Scrum Artefakte lernen? Besuche unsere anderen Seiten oder höre dir die passenden Podcast-Folgen an.
Product Backlog - Podcast-Folgen
#126: Wieviele Methoden sollte ein guter Scrum Master wie gut kennen
Ein guter Scrum Master braucht nicht unzählige Methoden. Erfahre, welche 5 Kompetenzen wirklich zählen, um Teams situativ und effektiv zu begleiten.
#55: Agile Coaching Kompetenzen - Nachlese
Agile Coaches verlieren sich oft in theoretischen Abgrenzungen. Erfahre, warum die Wirkung für den Klienten wichtiger ist als dogmatische Methodenreinheit.
#22: Product Owner Verantwortung – Sekretär-Falle vermeiden
PO-Verantwortung fürs Backlog klären: Mike Leber über Rollenkonflikte in Organisationen, Sekretär-Falle, Dreh- & Angelpunkt zwischen Teams. Nachlese zu Ep. 21.
#93: Von der fragmentierten Task-Liste zum richtigen Product Backlog
Ihr Backlog ist ein unpriorisierter Task-Haufen? Erfahren Sie in dieser Episode, wie Sie mit einem einfachen Workshop zu einem wertorientierten Product Backlog kommen.