Ein Backlog-Eintrag oder Backlog-Item 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, Format, Größe und Ebene
Typ
Allgemein beschreiben Backlog-Items Arbeitselemente für die Produktentwicklung. Alle Backlog-Items des gleichen Typs für ein Produkt beschreiben dabei die Summe der Arbeiten für die Produktentwicklung in einer anderen Dimension. So kann ein Produkt als Summe seiner Funktionen beschrieben werden, als Summe der zu klärenden und zu entscheidenden Wissenslücken (Knowledge-Gaps), als Summe der zu bauenden Muster und Prototypen oder als Summe aller Tätigkeiten aller beteiligten Teams. Von Anfang an alle Tätigkeiten zu beschreiben entspricht einer klassischen Planing und ist im P4-Framework nicht vorgesehen. Durch das Prinzip des „Rolling-wave-planning“ oder auch Just-in-time-Planung, werden weiter entfernt liegende Arbeitselemente iterativ und möglichst spät heruntergebrochen, da wir mit häufigen Änderungen rechnen. Mehr dazu hier.
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.