Der Begriff „Product Backlog“ stammt aus der agilen Methode Scrum. Das Product Backlog ist die Menge aller Anforderungen, die in ihrer Summe und Umsetzung das Produkt ergeben. Man könnte es also als eine Art Fachkonzept bezeichnen. Ein wichtiger Unterschied dazu ist aber, dass die im Product Backlog enthaltenen Anforderungen aus Sicht des Kunden, also in seiner Fachsprache und aus seiner Sicht, wie das Produkt genutzt werden soll, beschrieben sind. Scrum schreibt nicht vor, in welcher Form die Elemente eines Product Backlogs vorliegen müssen. Im Allgemeinen werden an dieser Stelle aber User Stories verwendet.
Beim Product Backlog handelt es sich um ein abstraktes Konzept. Wie es praktisch aussieht, ist dem jeweiligen Projekt überlassen. Es kann sich beispielsweise um Zettel handeln, die an einem Task Board hängen, Tabelleneinträge in einem Excel-Sheet oder Tickets in einem elektronischen Ticket-System. Als Softwarewerkzeug, mit dem ein Product Backlog verwaltet werden kann, hat sich die Anwendung „Jira“ von der Firma Atlassian fast schon als Standard etabliert. Jira ist ursprünglich ein Ticket-System, das dann nach und nach um verschiedene agile Funktionen (insbesondere um ein Task Board und Burndown Charts) erweitert wurde.
Auch wenn man agil arbeitet, ohne Scrum zu folgen und ein Product Backlog zu pflegen, benötigt man natürlich eine Form der Fixierung der Anforderungen. Vielleicht ist dies dann ein Fachkonzept, dessen Kapitelstruktur in User Stories organisiert ist. Es lohnt sich auf jeden Fall, das Konzept des Backlogs näher zu betrachten, weil es einige interessante Anregungen enthält.
Folgt man der Scrum-Methode, sind die Einträge im Backlog streng geordnet. Der Kunde oder Auftraggeber muss sich dann klar dazu bekennen, welche Anforderung ihm am wichtigsten ist, welche am zweitwichtigsten, und so weiter (vgl. Business Value). Üblicherweise ist das Backlog in der Praxis in verschiedenen Segmenten organisiert. Dazu kann man sich das Backlog als Stapel vorstellen, in dem die Einträge (englisch: Items), also gemeinhin User Stories, sich umso weiter oben befinden, je wichtiger sie sind.
Das Backlog wird im Wesentlichen von oben nach unten abgearbeitet. Daher müssen die Stories im oberen Segment möglichst so detailliert sein, dass sie von den Produktentwicklern ausreichend verstanden werden. Außerdem müssen diese Stories in ihrem Aufwand oder ihrer Komplexität bereits geschätzt sein, damit sie sinnvoll in die nächste Iteration (Sprint) eingeplant werden können. Stories (oder je nach Granularität eben Epics) in dem unteren Segment haben noch etwas Zeit und dürfen auch noch gröber beschrieben sein. Mit der Zeit werden sie genauer beschrieben, ggf. verfeinert und geschätzt. Da das Backlog „lebt“, kann es von dem Verantwortlichen (bei Scrum: dem Product Owner) jederzeit um neue Kundenwünsche erweitert werden. Ebenso können Kundenwünsche, die nicht mehr aktuell sind, herausgestrichen werden.
Das Sprint Backlog beschreibt die Arbeiten, die für das aktuelle Inkrement (bei Scrum: Sprint) geplant sind. Dazu werden in einem speziellen Meeting (Sprint Planning) passende Anforderungen aus dem Product Backlog ausgewählt. Daraus werden dann wiederum konkrete Aufgaben abgeleitet, so dass deutlich wird, wie genau das Ziel des Sprints erreicht werden kann. Dazu muss natürlich auch der Aufwand für die Aufgaben mit einem konkreten Wert abgeschätzt werden. Als Einheit für diese Schätzung werden gemeinhin Personentage verwendet. Das Team aktualisiert das Sprint Backlog während eines Projektes fortlaufend. Daher wird durch einfaches Aufsummieren der Aufwandsschätzungen aller noch ausstehenden Aufgaben leicht ersichtlich, ob ein Team aktuell im Plan liegt.
Das Sprint Backlog gehört denjenigen, die die Anforderungen umsetzen. Es darf daher auch nur von ihnen verändert werden. Da sie sich nur um die Aufgaben im Sprint Backlog kümmern müssen bzw. sollen, ist es somit nicht erlaubt, von außen neue Aufgaben an sie heranzutragen.