Product Backlog: Wie man ihn effektiv erstellt und priorisiert

Das Product Backlog ist der Motor der agilen Entwicklung. Jedes Feature, jeder Bugfix, jede Verbesserung und jede technische Aufgabe, die jemals umgesetzt werden könnte, findet sich im Backlog wieder. Es ist nach Priorität geordnet, für die Schätzung dimensioniert und bereit, in einen Sprint übernommen zu werden.

Ein gut gepflegtes Backlog ist eines der deutlichsten Anzeichen für ein reifes agiles Team. Ein vernachlässigtes Backlog mit hunderten von Einträgen, vielen irrelevanten Inhalten, unklaren Prioritäten und fehlenden Schätzungen ist eines der sichersten Anzeichen dafür, dass der Prozess des Teams Aufmerksamkeit benötigt.

Dieser Leitfaden behandelt, wie man ein Product Backlog von Grund auf aufbaut, wie man es pflegt und wie man sicherstellt, dass es die Entwicklung tatsächlich vorantreibt, anstatt als unkontrollierte Müllhalde für Ideen zu fungieren.

Was ist ein Product Backlog?

In Scrum ist das Product Backlog eine geordnete Liste von allem, was getan werden könnte, um das Produkt zu verbessern. Es liegt in der Verantwortung des Product Owner und ist die einzige Quelle der Wahrheit für die Aufgaben, an denen das Team arbeiten wird.

Das Backlog enthält:

User Stories: Features aus der Perspektive des Benutzers beschrieben
Bugfixes: Fehler, die behoben werden müssen
Technische Schulden: Verbesserungen an der Codequalität, Architektur oder Infrastruktur
Spikes: Rechercheaufgaben zur Reduzierung von Unsicherheiten, bevor man sich für ein Feature entscheidet
Nicht-funktionale Anforderungen: Verbesserungen bei Performance, Sicherheit oder Barrierefreiheit

Jeder Eintrag im Backlog sollte aus einem bestimmten Grund dort sein: Er stellt einen potenziellen Wert für Benutzer oder das Unternehmen dar. Einträge, die keinen Wert mehr bieten, sollten gelöscht und nicht nur in der Priorität herabgestuft werden.

Die Rolle des Product Owner

Der Product Owner (PO) ist für das Backlog verantwortlich. Das bedeutet:

Hinzufügen neuer Einträge, sobald diese identifiziert wurden
Entfernen von Einträgen, die nicht mehr relevant sind
Ständige Aufrechterhaltung der Priorisierung des Backlogs
Sicherstellen, dass der obere Teil des Backlogs für das Entwicklungsteam bereit zur Bearbeitung ist

Der PO erstellt das Backlog nicht isoliert. Input kommt von Benutzern, Stakeholdern, Entwicklern und Daten. Der PO trifft jedoch die endgültige Entscheidung über die Priorität.

Dieses Modell mit einem einzigen Verantwortlichen ist eines der wichtigsten Prinzipien von Agile. Backlogs, die von einem Komitee verwaltet werden oder bei denen per Abstimmung entschieden wird, neigen zu Kompromissen statt zu klarer Priorisierung. Die Folge ist, dass Teams am Ende versuchen, alles gleichzeitig zu erledigen.

Gute Backlog-Einträge schreiben

Epic

"Benutzer kann Daten exportieren"

Story

"Als Benutzer kann ich filtern"

Task

"Paginierung zur Liste hinzufügen"

User Story Format

Das Standardformat für User Stories lautet:

Als [Art von Benutzer], möchte ich [Aktion], damit [Nutzen].

Beispiel: “Als Projektmanager möchte ich Aufgaben nach Bearbeiter filtern können, damit ich die Arbeitslast meines Teams auf einen Blick sehen kann.”

Dieses Format zwingt dazu, zu artikulieren, wer profitiert, was benötigt wird und warum. Diese drei Kontextinformationen verhindern, dass Features aus den falschen Gründen gebaut werden.

Akzeptanzkriterien

Jeder Backlog-Eintrag sollte Akzeptanzkriterien haben: spezifische, testbare Bedingungen, die erfüllt sein müssen, damit der Eintrag als erledigt betrachtet werden kann.

Beispiel für Akzeptanzkriterien für die Filter-Story:

Benutzer können nach einem oder mehreren Bearbeitern gleichzeitig filtern
Die gefilterte Ansicht aktualisiert sich in Echtzeit ohne Neuladen der Seite
Der Filterstatus bleibt erhalten, wenn der Benutzer die Seite verlässt und zurückkehrt
Nicht zugewiesene Aufgaben erscheinen, wenn “Nicht zugewiesen” ausgewählt ist

Ohne Akzeptanzkriterien ist “erledigt” nicht definiert. Mit ihnen wissen sowohl der Entwickler als auch der Tester genau, was zu überprüfen ist.

INVEST-Kriterien

Gute User Stories erfüllen die INVEST-Kriterien:

Buchstabe	Bedeutung
I	Independent (Unabhängig): kann ohne Abhängigkeit von einer anderen Story entwickelt werden
N	Negotiable (Verhandelbar): Details können in Diskussionen angepasst werden
V	Valuable (Wertvoll): liefert einen Mehrwert für Benutzer oder das Unternehmen
E	Estimable (Schätzbar): das Team kann den erforderlichen Aufwand einschätzen
S	Small (Klein): kann innerhalb eines Sprints abgeschlossen werden
T	Testable (Testbar): hat klare Akzeptanzkriterien

Stories, die diese Kriterien nicht erfüllen, müssen verfeinert werden, bevor sie in einen Sprint gelangen. Dies geschieht typischerweise, wenn sie zu groß, zu vage oder nicht unabhängig lieferbar sind.

Techniken zur Backlog-Priorisierung

Priorisierungsmethoden

MoSCoW: Must/Should/Could/Won't

RICE: Reach x Impact / Effort

Weighted shortest job first

Bei der Priorisierung treffen Produktentscheidungen auf Daten. Mehrere Frameworks bieten Struktur für Priorisierungsentscheidungen.

MoSCoW-Methode

Kategorisieren Sie jeden Eintrag als Must have, Should have, Could have oder Won’t have (für dieses Release). Dies schafft ein einfaches vierstufiges Prioritätensystem, das Stakeholder verstehen und nutzen können.

RICE-Scoring

RICE steht für Reach (Reichweite), Impact (Auswirkung), Confidence (Vertrauen) und Effort (Aufwand). Jeder Eintrag wird anhand dieser Dimensionen bewertet und nach dem RICE-Score gereiht: (Reichweite × Auswirkung × Vertrauen) / Aufwand.

Dies ist eine quantitative Priorisierung. Sie funktioniert gut, wenn Daten zu Reichweite und Auswirkung vorliegen und eine fundiertere Rangfolge als nur das Bauchgefühl gewünscht ist.

Wert-Aufwand-Matrix

Tragen Sie jeden Backlog-Eintrag in eine 2x2-Matrix ein: Wert auf der einen Achse, Aufwand auf der anderen. Einträge im Quadranten mit hohem Wert und geringem Aufwand sind schnelle Erfolge und sollten priorisiert werden. Einträge mit geringem Wert und hohem Aufwand sind Kandidaten für die Entfernung.

Kano-Modell

Das Kano-Modell kategorisiert Features danach, wie sie die Benutzerzufriedenheit beeinflussen:

Basisbedürfnisse: Das Fehlen führt zu Unzufriedenheit. Ihre Anwesenheit wird erwartet (Must-haves)
Leistungsbedürfnisse: Mehr ist besser (Kernfeatures)
Begeisterungsfaktoren: Unerwartete Features, die die Zufriedenheit signifikant steigern

Dieses Framework hilft dabei, Must-haves gegen Innovation abzuwägen.

Backlog Grooming, auch Backlog Refinement genannt, ist der wiederkehrende Prozess des Überprüfens, Aktualisierens und Verbesserns von Backlog-Einträgen. In Scrum findet dies typischerweise einmal pro Sprint als eigenständiges Meeting statt.

Eine Grooming-Sitzung beinhaltet:

Überprüfung neuer Einträge: Einträge, die seit dem letzten Grooming hinzugefügt wurden. Sind sie klar geschrieben? Haben sie Akzeptanzkriterien?
Schätzung von Einträgen: Teams schätzen den Aufwand für Einträge am oberen Ende des Backlogs, damit sie für die Sprintplanung bereit sind.
Zerlegung großer Einträge: Epics und große Stories werden in kleinere, Sprint-taugliche Einträge zerlegt.
Bereinigung: Entfernen von Einträgen, die nicht mehr relevant, veraltet oder Duplikate sind.
Neu-Priorisierung: Anpassung der Reihenfolge basierend auf neuen Informationen, Stakeholder-Feedback oder geänderten geschäftlichen Prioritäten.

Ein gesunder Grooming-Rhythmus bedeutet, dass der obere Teil Ihres Backlogs immer für den nächsten Sprint bereit ist: geschrieben, geschätzt und priorisiert.

Das Backlog gesund halten

Ein Backlog, das ohne Bereinigung unendlich wächst, wird zur Belastung. Teams hören auf, ihm zu vertrauen, weil sie wissen, dass es voller Einträge ist, die niemand umsetzen will. Hier sind die Anzeichen für ein gesundes Backlog und wie man es pflegt.

Anzeichen für ein gesundes Backlog

Die obersten zehn bis fünfzehn Einträge sind verfeinert und bereit für einen Sprint
Alle Einträge haben klare Titel und Akzeptanzkriterien
Das Backlog enthält keine Einträge, die älter als sechs Monate sind und nie in der Nähe der Spitze priorisiert wurden
Jeder im Team hat den oberen Teil des Backlogs kürzlich gelesen
Einträge werden regelmäßig entfernt, nicht nur hinzugefügt

Die “Wenn es nicht in sechs Monaten gebaut wird, lösche es”-Regel

Viele Teams führen hunderte von Backlog-Einträgen mit sich, die sie in den nächsten sechs Monaten nicht umsetzen wollen. Dies erzeugt Rauschen, das die echten Prioritäten schwerer erkennbar macht. Eine nützliche Regel: Wenn ein Eintrag seit sechs Monaten im unteren Drittel des Backlogs liegt, archivieren oder löschen Sie ihn. Wenn er wichtig ist, wird er wieder auftauchen.

Die “Eisbox” trennen

Einige Teams führen eine “Eisbox”: eine separate Sammlung von Ideen und potenzieller zukünftiger Arbeit, die explizit nicht das aktive Backlog ist. Einträge in der Eisbox werden nicht priorisiert, nicht verfeinert und nicht geschätzt. Sie werden lediglich für zukünftige Überlegungen festgehalten.

Dies verhindert, dass die Eisbox das aktive Backlog verschmutzt, und macht das aktive Backlog kleiner, sauberer und vertrauenswürdiger.

Product Backlog vs. Sprint Backlog

Das Product Backlog und das Sprint Backlog sind verwandt, aber unterschiedlich:

	Product Backlog	Sprint Backlog
Umfang	Alles, was gebaut werden könnte	Was das Team für diesen Sprint zusagt
Eigentümer	Product Owner	Entwicklungsteam
Dauer	Laufend, sich entwickelnd	Ein Sprint (1–4 Wochen)
Detailgrad	Variabel (oben = detailliert, unten = grob)	Alle Einträge sind vollständig verfeinert
Größe	Potenziell hunderte Einträge	Typischerweise 10–20 Einträge

Bei der Sprintplanung zieht das Team Einträge von der Spitze des Product Backlogs in das Sprint Backlog. Deshalb muss der obere Teil des Product Backlogs immer bereit sein: Das Sprint-Planungsmeeting kann Stories nicht in Echtzeit für den gesamten Sprint verfeinern.

Weiterführende Lektüre: Sprint Planning: Wie man eine effektive Sitzung durchführt und User Story Mapping Guide

Tools zur Verwaltung eines Product Backlogs

Kanban

Backlog

Sprints

Tool	Am besten geeignet für	Backlog-Funktionen	Preis
Jira	Große Engineering-Teams	Epics, Stories, Sprints, Reporting	$7.75/Benutzer/Monat
Linear	Produkt-Engineering-Teams	Saubere UI, Zyklen, Roadmaps	Kostenlos / $8/Monat
TasksBoard	Google Workspace-Teams	Kanban, geteilte Aufgabenlisten	Kostenlos / Premium
Notion	Flexible Teams	Benutzerdefinierte Datenbanken, Ansichten	Kostenlos / $8/Monat
Trello	Kleine Teams	Karten, Listen, Labels	Kostenlos / $5/Monat
Asana	Funktionsübergreifende Teams	Portfolio, Timelines, Arbeitslast	Kostenlos / $10.99/Monat

Für Teams, die Google Workspace nutzen, bietet TasksBoard eine unkomplizierte Möglichkeit, Backlog-Einträge als geteilte Google Tasks-Listen mit einer Kanban-Board-Ansicht zu verwalten, ohne den Overhead einer dedizierten Projektmanagement-Plattform.

FAQ

Wer ist Eigentümer des Product Backlogs?

Der Product Owner ist Eigentümer des Backlogs und verantwortlich für dessen Inhalt, Reihenfolge und Verfügbarkeit. Das Entwicklungsteam trägt Schätzungen und technischen Input bei, aber der PO trifft die endgültigen Priorisierungsentscheidungen.

Wie oft sollte das Backlog gepflegt werden?

Die meisten Scrum-Teams pflegen das Backlog einmal pro Sprint und wenden etwa 10 % ihrer Sprint-Kapazität für das Refinement auf. Bei einem zweiwöchigen Sprint sind das etwa 90 Minuten pro Woche.

Wie groß sollte ein Product Backlog sein?

Es gibt keine universelle Antwort, aber ein Backlog mit mehr als 100 Einträgen ist oft ein Zeichen dafür, dass alte Einträge nicht bereinigt werden. Konzentrieren Sie sich darauf, die obersten 20–30 Einträge verfeinert und bereit zu halten. Der Rest kann weniger detailliert sein.

Was ist ein Epic im Kontext eines Product Backlogs?

Ein Epic ist eine große User Story, die zu umfangreich ist, um sie in einem einzigen Sprint abzuschließen. Epics werden während des Backlog-Refinements in kleinere Stories zerlegt. Sie dienen als organisatorische Container für zusammengehörige Features.

Wie geht man mit Bugs im Product Backlog um?

Bugs werden wie Backlog-Einträge behandelt und gegen Features priorisiert. Kritische Bugs springen typischerweise an die Spitze. Kleinere kosmetische Bugs können unter vielen Features liegen. Einige Teams führen eine separate Bug-Liste und führen sie erst zum Zeitpunkt der Priorisierung mit dem Backlog zusammen.

Was ist der Unterschied zwischen einem Product Backlog und einer Roadmap?

Eine Roadmap kommuniziert geplante Features und Zeitpläne auf hoher Ebene an Stakeholder. Ein Backlog ist die interne, operative Liste der für die Entwicklung priorisierten Arbeit. Roadmaps werden aus Backlogs abgeleitet, präsentieren aber eine vereinfachte, zeitgebundene Sicht, die für externe Zielgruppen geeignet ist.

Verwalten Sie Ihr Backlog mit TasksBoard

Ein Product Backlog ist nur nützlich, wenn das Team es sehen, aktualisieren und ihm vertrauen kann. TasksBoard verwandelt geteilte Google Tasks-Listen in ein visuelles Kanban-Board und gibt Ihrem Team eine einfache, kollaborative Möglichkeit, Backlog-Einträge ohne komplexe Einrichtung zu verwalten.

Erstellen Sie Listen für Ihre Backlog-Phasen (Eisbox, Backlog, In Arbeit, Erledigt), fügen Sie Aufgaben mit Beschreibungen und Fälligkeitsdaten hinzu und teilen Sie das Board mit jedem im Team. Es ist der kürzeste Weg von “Was bauen wir als Nächstes?” zu einer klaren, geteilten Antwort.