Das Product Backlog ist eine geordnete Liste von allem, von dem bekannt ist, dass es im Produkt enthalten sein soll. Es dient als einzige Anforderungsquelle für alle Änderungen am Produkt. Der Product Owner ist für das Product Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich.
Ein Product Backlog ist niemals vollständig. Während seiner ersten Entwicklungsschritte zeigt es die anfangs bekannten und am besten verstandenen Anforderungen auf. Das Product Backlog entwickelt sich mit dem Produkt und dessen Einsatz weiter. Es ist dynamisch; es passt sich konstant an, um für das Produkt klar herauszustellen, was es braucht, um seiner Aufgabe angemessen zu sein, im Wettbewerb zu bestehen und den erforderlichen Nutzen zu bieten. Sofern ein Produkt existiert, gibt es auch das dazugehörige Product Backlog.
Im Product Backlog werden alle Features, Funktionalitäten, Verbesserungen und Fehlerbehebungen aufgelistet, die die Änderungen an dem Produkt in zukünftigen Releases ausmachen. Ein Product-Backlog-Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert. Product-Backlog-Einträge enthalten oft Testbeschreibungen, die ihre Vollständigkeit nachweisen, wenn sie fertig [„Done“] sind.
Das Product Backlog entwickelt sich mit dem Einsatz eines Produktes, dessen Wertsteigerung sowie durch das Feedback des Marktes zu einer längeren, ausführlicheren Liste. Anforderungen werden nie aufhören, sich zu ändern. Daher ist das Product Backlog ein lebendes Artefakt. Änderungen an den Geschäftsanforderungen, Marktbedingungen oder der Technologie können Änderungen am Product Backlog nach sich ziehen.
Häufig arbeiten mehrere Scrum-Teams gemeinsam an einem Produkt. Dann wird ein einziges Product Backlog benutzt, um die anstehende Arbeit am Produkt zu beschreiben. In diesem Fall kann ein Gruppierungsattribut für die Product-Backlog-Einträge verwendet werden.
Als Verfeinerung [Refinement] des Product Backlogs wird der Vorgang angesehen, in dem Details zu Einträgen hinzugefügt, Schätzungen erstellt, oder die Reihenfolge der Einträge im Product Backlog bestimmt werden. Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Product Owner und das Entwicklungsteam gemeinsam die Product-Backlog-Einträge detaillieren. Bei der Verfeinerung des Product Backlogs werden die Einträge begutachtet und revidiert. Das Scrum-Team bestimmt, wann und wie diese Verfeinerungsarbeit erfolgt. Sie sollte normalerweise nicht mehr als 10% der Kapazität des Entwicklungsteams beanspruchen. Der Product Owner kann jedoch jederzeit die Einträge im Product Backlog aktualisieren oder aktualisieren lassen.
Höher eingeordnete Product-Backlog-Einträge sind generell klarer und weisen mehr Details auf als niedrigere. Präzisere Schätzungen entstehen auf der Basis von größerer Klarheit und Detailtiefe – je niedriger der Rang, desto weniger Details sind bekannt. Die Product-BacklogEinträge, mit denen sich das Entwicklungsteam im kommenden Sprint beschäftigen soll, werden so weit verfeinert, dass jeder von ihnen innerhalb des Sprints fertiggestellt werden kann. Die Product-Backlog-Einträge, für die das der Fall ist, werden als bereit [„Ready“] für die Auswahl durch das Entwicklungsteam in einem Sprint Planning angesehen. Ein Product-Backlog-Eintrag entwickelt diesen Transparenzgrad in der Regel durch die oben beschriebenen VerfeinerungsAktivitäten.
Das Entwicklungsteam ist für alle Schätzungen verantwortlich. Der Product Owner kann das Entwicklungsteam dahingehend beeinflussen, dass er ihm beim Verständnis der Einträge hilft oder Kompromisse eingeht. Die endgültige Schätzung erfolgt immer von denen, die auch die Arbeit erledigen werden.
Überwachung der Zielerreichung
Die verbleibende Arbeit zur Erreichung eines Ziels kann jederzeit aufsummiert werden. Der Product Owner vermerkt diese gesamte verbleibende Arbeit mindestens zu jedem Sprint Review. Er vergleicht diesen Betrag mit der verbleibenden Arbeit in früheren Sprint Reviews, um den Fortschritt der Arbeiten im Verhältnis zur restlichen Zeit zu begutachten. Diese Information wird allen Stakeholdern präsentiert.
Zur Fortschrittsprognose werden diverse Planungspraktiken eingesetzt, wie Burndown- oder Burnupdiagramme. Diese haben sich als nützlich erwiesen, allerdings schmälern sie nicht die Bedeutung des empirischen Vorgehens. In komplexen Umgebungen lassen sich zukünftige Ereignisse nicht vorherbestimmen. Nur was bereits geschehen ist, gibt Anhaltspunkte für die zukunftsgerichtete Entscheidungsfindung.
Scrum Guide Stand November 2017