Ein Backlog-Eintrag enthält als Attribute eine Beschreibung, eine Aufwandsschätzung, sowie Akzeptanzkriterien und Testbeschreibungen, die die Vollständigkeit nachweisen und beschreiben wann er erledigt [„Done“] ist.
Alle Backlog-Einträge haben folgende Eigenschaften und Attribute:
- Einen eindeutigen Kurznamen oder eine sonstige Identifikation (z.B. eine Nummer)
- Eine möglichst kurze, aber aussagekräftige Beschreibung
- Einen Hinweis darauf, wer die Quelle bzw. der Verfasser des Backlog-Eintrags ist. Damit soll klar werden, wen man bei Unklarheiten fragen kann.
- Zur Konkretisierung und Abgrenzung sind Akzeptanzkriterien definiert
- (Optional) Auf Portfolio- und Systemebene schätzen die jeweiligen Product-Owner den Nutzwert/Business-Value von Applikationen und Features ab. Hierfür werden Nutzwerte verschiedener Appikationen/Features relativ gegeneinander bewertet, wobei die Product Owner dazu z.B. Planning Poker verwenden.
- Um anzuzeigen, dass das betreffende Team eine Analyse und Abschätzung durchgeführt hat, wird der geschätzte Aufwand auf dem Backlog-Eintrag notiert
- Der Rang des Backlog-Items innerhalb des Backlogs ist seine Position innerhalb des Backlogs. Wenn der Nutzwert und der Aufwand geschätzt wurden, kann die grobe Priorität einfach berechnet werden (durch Teilen des Nutzwerts durch den Aufwand).
Unterteilung von Backlog-Items nach Typ, Ebene, Größe und Format
Formate
In der Software-Entwicklung hat sich das Spezifizieren von Backlog-Items im Format von User-Stories etabliert. Hierbei wird eine Benutzer-Anforderung in Form eines Satzes beschrieben (Wer möchte Was, Warum). P4 bevorzugt hier den Begriff der Stakeholder-Story, da die Benutzer des Systems nur einen Teil der Anforderer darstellen.
Zur weiteren Ausarbeitung werden häufig Use-Cases genutzt, die in verschiedene Szenarien aufgeteilt werden können.
Mittels Prosa-Anforderungen können einzelne Komponenten, Schnittstelle und deren Fähigkeiten und Eigenschaften beschrieben werden.
Größe & Ebene
Zur Bearbeitung eines Team-Backlog-Item (TBI) durch ein Team, muss dieses so klein sein, dass es in eine Iteration passt. Größere Backlog-Items überspannen mehrere Iterationen und müssen vor der Einplanung und Bearbeitung in mehrere TBIs zerteilt werden.
Zur Bearbeitung eines Cluster-Backlog-Item (CBI) durch ein Cluster, muss dieses so klein sein, dass es in einen Cycle passt. Größere Backlog-Items überspannen mehrere Cycle und müssen vor der Einplanung und Bearbeitung in mehrere CBIs zerteilt werden.