Ein Produkt kann ein Service, Produkt oder Software sein. Das Produkt Backlog ist die Liste der Funktionen und User Stories eines Produktes. Die Funktionsliste wird häufig mit Trello oder Jira gepflegt. Die wertvollsten Funktionen des Product Backlogs werden sortiert. Die wichtigste Funktion liegt oben und wird als wichtigste Funktion definiert. Im Refignment Meeting wird der Umfang der Funktionalitäten geschätzt. In den Refignment Meetings werden die Funktionen vom Product Owner mit den Entwickler definiert und erkannt. Ein Refignment Meeting darf nicht mehr als 10 % der Entwicklungszeit entsprechen. Der Product Owner pflegt das Product Backlog.
Das erste oder initiale Product Backlog, die Aufgabenliste ist beim Beginn der Erstellung umfangreich. Der Product Owner muss bei der Definition der User Stories eine Vision zum Produkt haben. Bei der Erstellung der User Stories wird das Entwicklungsteam und deren Expertise benötigt. Er muss die Produktlinie und Roadmap der Produkte und des Produkts des Unternehmens kennen. Das erste funktionsfähige Produkt und vom Kunden akzeptierte Produkt ist Minimum Viable Product (MVP) woraufhin Feedback für die Weiterentwicklung gegeben werden kann. Stackholder wie Kunden oder Käufer können und sollen die Anforderungen mit definieren und Feedback geben.
Der Product Backlog ist eine Liste von Funktionen des Produktes, Services oder Hardware. Die Funktionen einer Software oder Hardware werden in einen 'Requirements Workshop' mittels Kreativitätstechniken ermittelt. Der Product Owner baut den Product Backlog auf in denen sich die Aufgaben sogenannte Product Backlogs Items (PBI's) befinden. Die Funktionen können in einer Exceltabelle oder in Tools wie Jira dokumentiert werden. Mit Jira ist es möglich das Produkt Backlog zu teilen oder Sortierungen vorzunehmen. Viele Scrum Teams verwenden Sticky Notes auf denen Anforderungen geschrieben. Auf die Rückseite einer Sticky Note ist es möglich Akzeptanzkriterien einer Funktion zu beschreiben. Durch das haptische, der Flexibilität im Umgang und das hängen der Stick Note an eine Wand wird der Dialog und die Kommunikation gefördert. Der Product Owner nimmt die Priorisierungen der Anforderungen vor. Die Anforderungen welche wichtig und umgesetzt werden sollen, stehen oben und sind gut definiert, strukturiert und können in einen Sprint von maximal vier Wochen bearbeitet werden. Die Priorisierungen können nach Umsatz, Kosten, Risiko, Risiko-Wert-Abschätzung und Wissensaufbau vorgenommen werden. Aufgaben welche einen hohes Risiko und Wert haben sollten priorisiert werden sodass Unsicherheiten bereinigt werden. Sodann werden Aufgaben priorisiert welche ein niedriges Risiko und einen hohen Wert haben. Sodann werden Aufgaben priorisiert welche ein niedriges Risiko und Wert haben. Aufgaben mit hohen Risiko wo kein wertvolles Inkrement geliefert werden kann, sollten nicht priorisiert sondern gelöscht und vermieden werden.
Ein Product Backlog sollte nach DEEP gestaltet sein. Detailed oder Detailliert. Die Aufgaben und User Stories im Product Backlog sind ausführlich formuliert und erfüllen die Qualitätskriterien der Definition of Ready und weitere individuelle Qualitätskriterien für eine User Story. Das Product Backlog sollte ein Fülle von Aufgaben für die nächsten 1-2 Sprints haben. Emergent oder entstehend. Das Product Backlog und die User Stories können abgeändert, erweitert oder entfernt werden (agiler Ansatz). Estimated oder abschätzend. Der Aufwand sollte abgeschätzt werden können sodass die Ressourcen für einen Sprint und die Umsetzung geplant werden können. Prioritized oder priorisiert. Die User Story muss nach für den Kunden wichtigen Funktionen sortiert werden können. Eine Priorisierung muss nach Wertschöpfung, Komplexität (Unbekannte früh begegnen), Umsetzbarkeit (Einträge müssen mit der vorhanden Expertise umgesetzt werden können), Unabhängigkeit (User Stories müssen für sich alleinstehend sein). Der Product Owner erstellt und pflegt mit dem Scrum Master und Entwicklungsteam das Product Backlog.