Backlog

Ein Backlog ist eine geordnete Liste der ausstehenden Arbeit, oft in Form von User Storys formuliert und vom Business priorisiert, mit der die Arbeit eines adaptiven oder agilen Projekts organisiert und gesteuert wird. Es spiegelt den aktuellen Bedarf des Projekts wider, einschließlich Produktanforderungen und User Storys, und enthält einen laufend neu priorisierten Plan für die verbleibende Arbeit.

Das entscheidende Wort ist geordnet. Ein Backlog ist keine Sammlung von allem, was jemals gewünscht wurde, sondern genau diese Sammlung in einer Reihenfolge. Deshalb hat die Frage „was als Nächstes?“ jederzeit genau eine Antwort.

Der deutsche PMBOK Guide behält den englischen Begriff bei und schreibt „Backlog“. Die frühere Übersetzung „Rückstand“ ist irreführend, denn ein Backlog ist keine liegen gebliebene Arbeit, sondern die geplante.

Die drei Backlogs

Die achte Ausgabe nennt drei Typen, die in adaptiven und agilen Projekten üblich sind. Sie sind ineinander verschachtelt, keine Alternativen.

Backlog	Enthält	Verantwortet meist
Produkt-Backlog	Anforderungen, Features, Epic User Storys und User Storys, also den gesamten Umfang und die Vision des Produkts	Der Product Owner
Release Backlog	Die Teilmenge für ein bestimmtes Release, das mehrere Sprints oder Iterationen umfassen kann	Product Owner mit dem Team
Iteration Backlog	Die ausgewählten User Storys plus die Aufgaben, die zur Fertigstellung der zugesagten Arbeit in der laufenden Iteration nötig sind	Das Entwicklungsteam

Die Unterscheidung zwischen Produkt-Backlog und Sprint- beziehungsweise Iteration-Backlog hebt der Leitfaden eigens hervor: Das erste enthält die vollständige Liste der gewünschten Features und Änderungen, das zweite nur die Teilmenge, die für eine bestimmte Iteration ausgewählt wurde.

Wie das Backlog die Änderungssteuerung ersetzt

Das ist der Teil, der aus plangetriebener Sicht überrascht. In adaptiven Ansätzen erfolgt das Änderungsmanagement laut achter Ausgabe über Backlog-Management und nicht über einen formalen Änderungsantrag. Wenn ein Stakeholder etwas vorschlägt:

• wird es als Produkt-Backlog-Element erfasst und dem Backlog hinzugefügt;
• wird trotzdem eine Auswirkungsanalyse durchgeführt, um Wirkung und Priorität zu bestimmen. Die Analyse entfällt nicht, nur der Papierweg;
• gibt es in der Regel keinen formalen Genehmigungsschritt. Eine niedrige Priorität ist die Zurückstellung. Das Element nicht aufzunehmen oder wieder zu entfernen ist die Ablehnung.

Die Elemente werden nach Geschäftswert oder Bedeutung für den Kunden gereiht und vom Entwicklungsteam geschätzt, sodass die wertvollsten Elemente in den nächsten Entwicklungszyklus gehen. Abhängigkeiten und Randbedingungen werden dabei berücksichtigt und können die Position eines neuen Elements verändern.

Backlog-Verfeinerung

Verfeinerung ist die fortschreitende Ausarbeitung der Backlog-Inhalte samt Neupriorisierung, um die Arbeit zu bestimmen, die in der kommenden Iteration geleistet werden kann. Praktisch heißt das: das Produkt-Backlog fortlaufend durchsehen, überarbeiten, reihen und redigieren, damit das Team baut, was Business und Kunde tatsächlich brauchen.

Zwei Dinge machen Verfeinerung wirksam. Elemente oben sind klein und klar genug, um sie zu beginnen, Elemente weiter unten dürfen grob bleiben. Und die Sitzung endet mit einer Reihenfolge, nicht mit einer Diskussion. Ein Verfeinerungstermin ohne Neupriorisierung hat nichts verfeinert.

Das Backlog im PMBOK Guide 8

• Eigener Eintrag in Abschnitt 4, Inputs und Outputs (S. 114), mit der vollständigen Definition und den drei Typen darunter.
• Output von „Scope-Struktur entwickeln“ (Abbildung 2-17). Das Produkt-Backlog steht dort neben Scope-Baseline, Projektstrukturplan, PSP-Wörterbuch und User Storys. In agilen Projekten, so der Leitfaden, entspricht der Projektstrukturplan dem Produkt-Backlog, in dem Arbeitselemente in Epics und User Storys zerlegt werden.
• Input von „Terminplan überwachen und steuern“ (Abbildung 2-24), wo zugleich die Backlog-Verfeinerung als Werkzeug und Technik geführt wird.
• Werkzeug von „Änderungen bewerten und umsetzen“ (Abbildung 2-10). Backlog-Management steht dort in derselben Liste wie die integrierte Änderungssteuerung. Deutlicher lassen sich die zwei parallelen Wege im Umgang mit Änderungen nicht darstellen.
• Backlog-Management und Backlog-Verfeinerung haben eigene Einträge im Abschnitt zu Werkzeugen und Techniken (S. 148).
• Gleichsetzung mit der Baseline. Für adaptive Ansätze hält der Leitfaden fest, dass die Scope-Baseline auch „priorisierte Anforderungen“ oder „Sprint-Backlog“ heißen kann.

In der Praxis

• Eine Reihenfolge, keine Gleichstände. Wenn zwei Elemente beide „hohe Priorität“ haben, hat das Backlog seine einzige Aufgabe verfehlt. Die Reihung erzwingen.
• Ein Backlog ist kein Parkplatz. Elemente, die seit einem Jahr unter dem Strich liegen, sind Rauschen. Sie zu löschen ist eine legitime Entscheidung, und die achte Ausgabe wertet das Entfernen ausdrücklich als Ablehnung einer Änderung.
• Schätzen nach dem Reihen, nicht davor. Das Business reiht nach Wert, das Team schätzt, was oben liegt. Das ganze Backlog zu schätzen ist verlorene Zeit.
• Auf die Wachstumsrate achten, nicht auf die Anzahl. Ein Backlog, das schneller wächst als die Geschwindigkeit des Teams, sagt mehr über die Scope-Disziplin aus als jeder Statusbericht.
• Abnahmekriterien gehören ans Element. Der Leitfaden knüpft den Abschluss einer Iteration daran, dass die priorisierten Backlog-Elemente fertig sind und alle Abnahmekriterien erfüllt wurden.

Häufige Fragen

Ist ein Backlog dasselbe wie eine To-do-Liste?

Nein. Eine To-do-Liste ist eine Menge von Aufgaben, ein Backlog eine gereihte Menge von Wertversprechen aus Anwendersicht, die laufend neu geordnet wird. Reihenfolge und Verantwortung machen den Unterschied.

Wem gehört das Backlog?

Das Produkt-Backlog pflegt üblicherweise der Product Owner, der das Business vertritt. Das Iteration-Backlog gehört dem Team, weil dort die Zusage liegt. Wer beides vermischt, sagt dem Team gleichzeitig, was es bauen und wie viel es zusagen soll.

Hat ein plangetriebenes Projekt ein Backlog?

In diesem Sinn nicht. Sein Gegenstück ist die Scope-Baseline aus Scope-Beschreibung, Projektstrukturplan und PSP-Wörterbuch, änderbar nur über die formale Änderungssteuerung. Manche hybriden Projekte führen eine Baseline für den vertraglich gebundenen Teil und ein Backlog für den frei gestaltbaren.

Verhindert ein Backlog schleichenden Scope-Zuwachs?

Es macht ihn nur anders sichtbar. Nichts hindert ein Backlog daran, unbegrenzt zu wachsen. Die Disziplin liegt in der Reihung und in der Bereitschaft, Elemente zu entfernen, nicht im Behälter.

Wie groß sollte ein Backlog sein?

Groß genug, um die nächsten Iterationen im Detail und das absehbare Release im Überblick abzudecken. Darüber hinaus veraltet Detailtiefe schneller, als sie genutzt wird. Genau deshalb wird laufend verfeinert statt vorab spezifiziert.

Autor: Tom, seit 2004 PMP-zertifiziert. Zuletzt aktualisiert: August 2026.