Product Backlog

Product Backlog ist in der agilen Software-Entwicklungsmethode ↑Scrum die Liste aller Anforderungen an eine zu erstellende Software.

Bereits die Wahl der Bezeichnung "Backlog" (Auftragsbestand) weist darauf hin, dass das Product Backlog eine dynamische Liste ist und somit kein ↑Lastenheft im traditionellen Sinn ist. Konsequent definiert der Scrum Guide den Product Backlog als Dokument des Product Lifecycle Managements und nicht als temporäres Projektdokument.

Verwaltung des Product Backlogs

Für die Dauer eines Projekts für den Product Backlog verantwortlich ist bei Scrum der ↑Product Owner. Der Product Owner muss Erweiterungen des Product Backlogs durch neue oder veränderte Anforderungen genehmigen. Weiterhin darf es für jedes Produkt nur genau einen Product Backlog geben, um Eindeutigkeit zu gewährleisten.

Der Product Owner priorisiert die Anforderungen des Backlogs und entscheidet letztverantwortlich darüber, welche Anforderungen vom Product Backlog in den Sprint Backlog übernommen werden.

Zusammensetzung des Product Backlogs

Der Scrum Guide macht keine genauen Angaben darüber, wie ein Product Backlog aufgebaut sein sollte. Explizit zählt er Eigenschaften, Funktionen, Anforderungen, Verbesserungen und Fehlerbehebungen als Elemente des Product Backlogs auf. Jeder Eintrag muss eine Beschreibung, die Angabe der Position, eine Aufwandsschätzung und eine Wertangabe enthalten.

Der Scrum Guide schreibt Form und Inhalt von Einträgen im Product Backlog nicht vor. Weit verbreitet ist die Verwendung von User Stories, deren Aufwände mit ↑Story Points relativ abgeschätzt werden.

Relevante Beiträge im Projekt Magazin
von Benjamin Seidler
5 Bewertungen
3.8
0 Kommentare
Bei der Entwicklung eines neuen Produkts fällt es Projektteams manchmal schwer, die Sicht des Kunden einzunehmen. Abhilfe schafft das Product Canvas: Es zerlegt Anforderungen in ihre grundlegenden Bestandteile und bildet diese in Form eines vorstrukturierten Plakats ab. Agile Coach Benjamin Seidler zeigt, wie ein agiles Team dieses Canvas erstellt und damit im Projektverlauf jederzeit flexibel auf sich ändernde Anforderungen reagiert.
von Dorian Gloski
2 Bewertungen
3.5
1 Kommentar
Für das Schätzen eines Sprints stehen in Scrum verschiedene Methoden, wie z.B. Planning Poker, zur Verfügung. Mit etwas Erfahrung und Übung schaffen es agile Teams auf diese Weise, zuverlässige Vorhersagen darüber zu treffen, was sie in einem Sprint umsetzen können. Eine klare Aussage über den Gesamtaufwand eines agilen Projekts ist in vielen Fällen hingegen nicht möglich. Doch gerade zu Projektbeginn sind diese Informationen für den Auftraggeber von großer Bedeutung. Dorian Gloski gibt in diesem Beitrag Tipps, was beim Schätzen des Gesamtaufwands in agilen Projekten wichtig ist, um klare Aussagen treffen zu können.
von Dominik Maximini
3 Bewertungen
3.333335
0 Kommentare
Im ersten Teil stellte Dominik Maximini ein Vorgehen vor, um Scrum-Projekte strukturiert zu planen und zeigte Fehler auf, die dabei häufig in der Praxis gemacht werden. In diesem zweiten und abschließenden Teil stellt er die einzelnen Planungsschritte an einem Praxisbeispiel im Detail vor.
Alle relevanten Beiträge anzeigen
Tech Link