In meinem letzten Video haben wir uns angeschaut, was ein Backlog ist. Dabei haben wir gelernt, dass ein Backlog aus Product Backlog Items besteht, kurz PBI. In diesem Video gehen wir eine Ebene tiefer und schauen uns an, was genau ein PBI ist, wie es sich über die Zeit entwickelt und wie es mit dem Product Backlog, dem Sprint Backlog und dem Product Owner zusammenhängt.
Was ist ein Product Backlog Item?#
Ein Product Backlog Item ist ein einzelnes Arbeitselement auf dem Product Backlog. Ein solches PBI kann verschiedene Formen annehmen: ein Epic, ein Feature, eine User Story oder ein Task. Jeder dieser Typen dient einem anderen Zweck und operiert auf einer anderen Granularitätsebene. In meinen nachfolgenden Videos gehe ich auf jeden dieser Typen im Detail ein.
Der Lebenszyklus eines PBI#
Jedes Product Backlog Item durchläuft einen Lebenszyklus. Er beginnt, wenn Stakeholder, wie das Business, Kunden oder der Product Owner, neue Ideen haben. Das neue PBI wird dann am Ende des Backlogs erstellt. Danach nimmt sich der Product Owner das PBI und ordnet es gemäss Business Value, Risiken und anderen Kriterien ein. Gemeinsam mit dem Team wird das PBI Schritt für Schritt verfeinert, bis es bereit für die Implementierung ist. Nach der Implementierung wird es Teil des inkrementellen Produkts.
“Ein Product Backlog Item beginnt als einfacher Zwei-Wort-Titel und entwickelt sich über Wochen und Monate durch Diskussionen, Schätzungen und Akzeptanzkriterien, bis es bereit zur Implementierung ist.”
Wie der Product Owner das Backlog ordnet#
Der Product Owner ordnet PBIs nach verschiedenen Kriterien: Geschäftsrisiko, technisches Risiko, Business Value, Kundenzufriedenheit, Zeitkritikalität, Implementierungsstrategie, Abhängigkeiten, Infrastrukturarbeiten und Abbau von technischen Schulden.
Was ich viel zu oft sehe, sind Product Owner, die nur Features, Features, Features wollen und dabei technische Schulden, Infrastrukturarbeiten und technische Risiken komplett ignorieren. Das ist ein gefährliches Muster. Man sollte immer ein gesundes Gleichgewicht zwischen technischer Arbeit und fachlicher Arbeit halten. Wenn man die technische Seite vernachlässigt, wird das Produkt irgendwann in einen Zustand geraten, in dem man nur noch Bugs fixt und keine neuen Features mehr liefern kann.
Wie sich ein PBI über die Zeit entwickelt#
Hier ein grobes Beispiel, wie sich ein PBI entwickelt, während es im Product Backlog aufsteigt:
- Eintrag: Ein einfacher Zwei-Wort-Titel
- Zwei Monate später: Eine Diskussion, zusammengefasst in drei Sätzen
- Eine Woche später: Das Team gibt eine erste Schätzung ab
- Zwei Wochen später: Drei Akzeptanzkriterien werden hinzugefügt
- Nochmal eine Woche später: Ein UI-Sketch wird ergänzt
- Am nächsten Tag: Das Team schätzt das PBI neu
Beachten Sie, dass ich an keiner Stelle erwähnt habe, ob dieses PBI ein Epic, ein Feature, eine User Story oder ein Task ist. Diese Klassifizierung trifft das Team basierend auf den Schätzungen.
Das mentale Modell: PBIs und das Backlog#
Hier ist ein mentales Modell, das die verschiedenen Konzepte verbindet:
- Ein Epic wird durch ein oder mehrere Features realisiert
- Ein Feature wird durch eine oder mehrere User Stories realisiert
- Eine User Story wird durch einen oder mehrere Tasks implementiert
- Epics, Features und User Stories gehören zum Product Backlog
- Das Sprint Backlog ist eine Teilmenge des Product Backlogs und enthält die User Stories, die während eines Sprints implementiert werden
- Das Product Backlog gehört dem Product Owner
- Das Sprint Backlog gehört dem Entwicklungsteam
“Ein Bug ist nur eine spezielle User Story. Features werden gefixt, indem ein Bug behoben wird, und der Bug wird durch die Implementierung von Tasks gefixt.”
Einen PBI-Typ habe ich in der Visualisierung bewusst weggelassen, um es einfach zu halten: den Bug. Bugs treten auf, wenn ein Feature nicht wie erwartet funktioniert. Ein Bug ist im Grunde eine spezielle User Story. Features werden durch das Beheben von Bugs gefixt, und Bugs werden durch die Implementierung von Tasks behoben.
Kernaussagen#
Ein PBI ist eine einzelne Arbeitseinheit auf dem Product Backlog. Es kann ein Epic, Feature, eine User Story oder ein Task sein.
PBIs entwickeln sich über die Zeit durch Refinement, von vagen Ideen hin zu implementierungsbereiten Items.
Der Product Owner ordnet das Backlog nach Risiko, Business Value, Kundenzufriedenheit und anderen Kriterien.
Technische und fachliche Arbeit im Gleichgewicht halten. Technische Schulden, Infrastruktur und Risiken zu ignorieren, wird das Produkt langfristig ausbremsen.
Das mentale Modell ist einfach. Epics werden in Features aufgeteilt, Features in User Stories und User Stories in Tasks. Das Verständnis dieser Beziehungen macht das Backlog Management unkompliziert.