---

Was ist das Scrum Product Backlog? Das könnte Sie überraschen!

Das Product Backlog (Scrum Backlog), auch Scrum Product Backlog, ist das zentrale Element für alle bekannten Produktanforderungen.

Es enthält die entstehende, geordnete Arbeit zur Produktverbesserung und Zielerreichung. Dazu zählen funktionale und nichtfunktionale Anforderungen sowie Nutzererlebnis und Oberflächengestaltung.

Es enthält Funktionswünsche und grobe Stories, aber auch Voraussetzungen wie Test- und Entwicklungsumgebungen, Fehlerbehebung, technische Schulden und Funktionsverbesserungen.

Jedes Produkt hat ein Backlog für alle beteiligten Teams. Erstellung, Pflege und Verfeinerung verantwortet der Product Owner. Es soll nicht beantworten, wie Anforderungen entwickelt und geliefert werden.

Das entscheidet das Team und dokumentiert die Aufgaben im Sprint Backlog. Product und Sprint Backlog sind getrennte Einheiten, obwohl das erste den Inhalt des zweiten bestimmt.

Verantwortlich für das Scrum Product Backlog ist der Product Owner. Scrum Master, Team und Stakeholder tragen zu einer umfassenden Story-Liste für den Produkterfolg bei.

Zusätzliche Artefakte sind erlaubt, etwa Rollenübersichten, Abläufe, Oberflächenregeln, Storyboards und Prototypen. Sie ergänzen und detaillieren das Product Backlog, ersetzen es aber nicht.

Das Product Backlog ist ein lebendiges Dokument. Wie die Software verbessert es sich schrittweise und wächst mit der Zeit. Scrum verlangt keinen separaten Änderungsprozess. Die erste Fassung basiert auf dem besten anfänglichen Produktverständnis des Product Owners.

Mit Beobachtung jedes Sprints und wachsendem Kundenwissen ergänzt, entfernt und verfeinert er Anforderungen.

Er priorisiert sie im Backlog. Je höher die Priorität, desto detaillierter sollten Einträge sein, damit das Team sie versteht und nötige Aufgaben erstellt.

Entwickler schätzen bei Bedarf; Punkte sind optional. Vorrangige Stories werden für die Planung genauer geschätzt.

Folgende Eigenschaften unterscheiden es von einer einfachen Aufgabenliste:

• Jede Story schafft geschäftlichen oder technischen Wert für Kunden, Geschäftsverantwortliche und Nutzer,
• alle Stories stehen nach absteigender Priorität,
• der Detailgrad hängt von der Position ab,
• Stories werden bei Bedarf geeignet geschätzt,
• das Backlog ist lebendig,
• es beschreibt Produktarbeit; der detaillierte Ausführungsplan gehört ins Sprint Backlog.

Stories schaffen Wert für Kunden, Geschäft und Systeme

Jede Story muss Kundennutzen bieten. Ohne ihn verschwendet sie Ressourcen und sollte entfallen. Mögliche Inhalte sind:

• funktionale und nichtfunktionale Anforderungen,
• grobe Arbeitszerlegung für die Produkteinführung,
• Entwicklungs- und Vorführumgebungen außerhalb der Produktion,
• Fehlerbehebung.

Beispiel eines Scrum Product Backlogs

Auch ohne direkten funktionalen Kundennutzen können Aufgaben langfristig Qualität, geringere technische Schulden und bessere Wartbarkeit schaffen.

Das Product Backlog lebt

Im ganzen Projekt kommen Stories hinzu, werden geändert, detailliert oder gelöscht. Anders als bei Wasserfall werden Anforderungen nicht früh eingefroren.

Sie entstehen vielmehr iterativ gemeinsam mit den Inkrementen.

Das unterscheidet sich von traditioneller Anforderungsanalyse, maximiert aber Kundennutzen und minimiert Verschwendung.

Unterschiedliche Detailgrade

Anforderungen dürfen unterschiedlich fein sein. Nur Arbeit für die nächsten Sprints sollte detailliert sein.Andere Stories bleiben grob und werden erst unmittelbar vor dem Wissensbedarf bearbeitet.

Vorzeitige Spezifikation verschwendet Aufwand, wenn Anforderungen vorher geändert oder gestrichen werden. „Just in time“ ist ein großer Vorteil beim Umgang mit unbekannten Unbekannten.

Keine Detailaufgaben im Product Backlog

Es beschreibt normalerweise Produktarbeit statt Ausführungsaufgaben. Der Product Owner klärt Anforderungen mit Kunden und Stakeholdern vor Verfeinerung oder Planung. Entwickler verantworten Aufgabenzerlegung und eigene Arbeitsorganisation.

Priorität bestimmt die Reihenfolge

Der Product Owner ordnet mit Teamunterstützung absteigend nach Priorität. Geschäftswert, Kosten, Risiken und Abhängigkeiten sind typische Kriterien. So entscheidet er über die nächste Entwicklung und Lieferung.

Product-Backlog-Einträge dimensionieren

Entwickler können Fibonacci-Punkte oder relative Größen S/M/L/XL/XXL verwenden. Weder eine bestimmte Skala noch eine Schätzung jedes fernen Eintrags ist Pflicht. Später mehr dazu. Die Schätzungen beeinflussen Kapazität, Sprint Backlog und Releases.

Mit dem Backlog arbeiten

Es braucht regelmäßige, sorgfältige Pflege, denn es ist die maßgebliche Quelle zum Verständnis des Produkts..

Anfangs enthält es viele grobe Stories, deren Erfolgsbeitrag noch unklar sein kann. Mit jedem Sprint lernen Product Owner und Team dazu.

Der Inhalt spiegelt zunehmend das Produkt und die Erkenntnisse wider.

Nach dem Aufbau bleibt kontinuierlich nötig:

• Neue Anforderungen beschreiben und ergänzen, bestehende passend ändern oder entfernen,
• die wichtigsten Stories nach oben ordnen,
• vorrangige Stories meist in der Verfeinerung auf die Planung vorbereiten,
• Stories meist in der Verfeinerung neu oder erneut schätzen.

Der Product Owner sichert einen guten Zustand; Pflege bleibt aber gemeinsame Arbeit. Angemessene Teamkapazität muss für laufende Verfeinerung und Events reserviert sein.

Gemeinsame Pflege klärt Anforderungen und stärkt die Zustimmung zum entstehenden Produkt.