Product Backlog: Wie man es 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, befindet sich im Backlog – sortiert nach Priorität, geschätzt für den Aufwand und bereit, in einen Sprint gezogen zu werden.
Ein gut gepflegtes Backlog ist eines der deutlichsten Anzeichen für ein reifes agiles Team. Ein vernachlässigtes Backlog – hunderte von Einträgen, viele davon irrelevant, unklare Prioritäten, keine 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 Ideensammlung zu verstauben.
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 Owners und ist die einzige Quelle der Wahrheit für die Arbeit des Teams.
Das Backlog enthält:
- User Stories — Features aus der Perspektive des Nutzers beschrieben
- Bugfixes — Fehler, die behoben werden müssen
- Technische Schulden — Verbesserungen der Codequalität, Architektur oder Infrastruktur
- Spikes — Rechercheaufgaben zur Verringerung von Unsicherheiten, bevor ein Feature zugesagt wird
- Nicht-funktionale Anforderungen — Verbesserungen bei Performance, Sicherheit oder Barrierefreiheit
Jeder Eintrag im Backlog sollte einen Grund haben: Er repräsentiert einen potenziellen Wert für Nutzer oder das Unternehmen. Einträge, die keinen Wert mehr darstellen, sollten gelöscht und nicht nur in der Priorität herabgestuft werden.
Die Rolle des Product Owners
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 Priorisierung des Backlogs
- Sicherstellen, dass der obere Teil des Backlogs für das Entwicklungsteam bereit zur Umsetzung ist
Der PO erstellt das Backlog nicht isoliert. Input kommt von Nutzern, Stakeholdern, Entwicklern und Daten. Aber der PO trifft 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 oder durch Abstimmungen verwaltet werden, neigen zu Kompromissen statt zu klarer Priorisierung, und Teams arbeiten am Ende an allem gleichzeitig.
Gute Backlog-Einträge schreiben
"User can export data"
"As a user I can filter"
"Add pagination to list"
User Story Format
Das Standardformat für User Stories lautet:
Als ein [Art von Nutzer], möchte ich [eine Aktion ausführen], sodass [ein Nutzen entsteht].
Beispiel: “Als Projektmanager möchte ich Aufgaben nach Bearbeiter filtern können, damit ich die Arbeitslast meines Teams auf einen Blick sehe.”
Dieses Format zwingt dazu, zu artikulieren, wer profitiert, was benötigt wird und warum – drei Kontextinformationen, die 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” gilt.
Beispiel für Akzeptanzkriterien für die Filter-Story:
- Nutzer können gleichzeitig nach einem oder mehreren Bearbeitern filtern
- Die gefilterte Ansicht aktualisiert sich in Echtzeit ohne Neuladen der Seite
- Der Filterstatus bleibt erhalten, wenn der Nutzer die Seite verlässt und zurückkehrt
- Nicht zugewiesene Aufgaben erscheinen, wenn “Nicht zugewiesen” ausgewählt ist
Ohne Akzeptanzkriterien ist “erledigt” undefiniert. 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 Nutzer 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 – meist weil sie zu groß, zu vage oder nicht unabhängig lieferbar sind –, müssen vor dem Sprint verfeinert werden.
Techniken zur Priorisierung des Backlogs
Bei der Priorisierung treffen Produkturteil und Daten aufeinander. 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ätssystem, 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 in diesen Dimensionen bewertet und nach dem RICE-Score sortiert: (Reichweite × Auswirkung × Vertrauen) / Aufwand.
Dies ist eine quantitative Priorisierung – sie funktioniert gut, wenn Sie Daten zu Reichweite und Auswirkung haben und ein besser begründbares Ranking als nur ein Bauchgefühl wünschen.
Wert vs. 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 “hoher Wert, geringer Aufwand” sind schnelle Erfolge und sollten priorisiert werden. Einträge im Quadranten “geringer Wert, hoher Aufwand” sind Kandidaten für die Löschung.
Kano-Modell
Das Kano-Modell kategorisiert Features danach, wie sie die Nutzerzufriedenheit beeinflussen:
- Basis-Anforderungen — fehlen sie, entsteht Unzufriedenheit; sind sie vorhanden, werden sie erwartet (Must-haves)
- Leistungs-Anforderungen — mehr ist besser (Kernfeatures)
- Begeisterungs-Faktoren — unerwartete Features, die die Zufriedenheit signifikant steigern
Dieses Framework hilft dabei, Must-haves gegen Innovation abzuwägen.
Backlog Grooming (Refinement)
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 separates 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 Einheiten zerlegt.
- Bereinigung (Pruning) — 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 bereit ist – geschrieben, geschätzt und priorisiert – für den nächsten Sprint.
Ein gesundes Backlog erhalten
Ein Backlog, das unendlich wächst, ohne bereinigt zu werden, wird zur Last. Teams verlieren das 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 die 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 in sechs Monaten nicht gebaut wird, lösche es”-Regel
Viele Teams führen hunderte Backlog-Einträge 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” (Icebox) 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 |
| Verantwortlich | Product Owner | Entwicklungsteam |
| Dauer | Laufend, entwickelnd | Ein Sprint (1–4 Wochen) |
| Detailgrad | Variiert (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 vom oberen Ende 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: How to Run an Effective Session und User Story Mapping Guide
Tools zur Verwaltung eines Product Backlogs
| Tool | Am besten geeignet für | Backlog-Funktionen | Preis |
|---|---|---|---|
| Jira | Große Engineering-Teams | Epics, Stories, Sprints, Reporting | $7.75/Nutzer/Monat |
| Linear | Produkt-Engineering-Teams | Sauberes 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 normalerweise an die Spitze; kleinere kosmetische Bugs können unter vielen Features liegen. Manche 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.
Bereit, Ihre Google Tasks zu teilen?
Starten Sie kostenlos mit TasksBoard, keine Kreditkarte erforderlich.
Anmelden
