Gliederung und Priorisierung
Häufig werden Epics oder (User) Stories genutzt, um PBIs zu beschreiben. Epics beschreiben große Themen in höherer Abstraktion, Stories decken Teilaspekte dieser übergeordneten Themen ab.
In Ticketingsystemen können items in der Form Epic → Story → Aufgabe → Unteraufgabe gegliedert werden. Ist das sauber angelegt, ‘weiss’ jede Aufgabe zu welchem Epic sie gehört und kann verfolgt werden.
Die am höchsten priorisierten items sind in einem hinreichenden Detaillierungsgrad beschrieben, um sie im nächsten Sprint umsetzen zu können. Niedriger priorisierten items werden während der Projektzeit in so genannten refinements weiter detailliert. In absteigender Reihenfolge werden die PBIs damit unschärfer, weniger wichtig und geringer priorisiert.
- ganz oben rangieren Items / Stories für den nächsten Sprint. Diese müssen zu Beginn der Sprintplanung ready sein: eindeutig priorisiert, geschätzt und vom Team verstanden.
- in der Mitte Items / Stories, an denen gearbeitet und weiter verfeinert werden muss, zu denen das Team noch Rückfragen hat, die technologisch nicht klar sind oder zu grob, um sie in einem einzigen Sprint abzuarbeiten
- weiter unten und damit geringer oder noch nicht priorisiert: Epics als übergreifende Stories
Wenn gerade so viele items als ‘ready to implement’ bereitstehen, dass der nächste Sprint damit bestritten werden kann, ist das PBL gut gepflegt aufgestellt. Über die Zeit — je mehr Unklarheiten durch mehr Wissen aufgelöst werden — werden die PBIs präziser formuliert, besser geschätzt und klarer formuliert.
Erst wenn das Entwicklungsteam ein item komplett und in allen Querverbindungen verstanden hat und es als ready markiert, erst dann kann es zur Implementierung im nächsten Sprint ausgewählt werden.
Umfang und Tools
Das Product Backlog soll eine überschaubare Größe haben, 30-80 Stories und Epics sind handhabbar. Hunderte items erschweren den Überblick. Product Owner pflegen auch andere Dokumente wie Story Maps und Impact Maps, mit denen längerfristige Planung und Produktgestaltung unterstützt werden.
Auch bei komplexen Produkten oder hohem Regulierungsbedarf und unter komplizierteren Randbedingungen werden die benötigten Features immer in kleine Einträge zerlegt und in eine eindeutige Reihenfolge gebracht.
Haptische Karteikarten und analoge Boards mit Kartonkärtchen sind zum Start eines Vorhabens gut geeignet zum Aufbau eines Backlog. Wächst ein Projekt, gibt es in vielen Unternehmen Ticketingsysteme wie Jira, Redmine oder Target Process uvm., die für die längerfristige Speicherung, zur dynamischen Filterung und Kommunikation besser geeignet sind als analoge Karten, deren Wandel fotografisch dokumentiert werden müssten.
Wichtig für das Entwicklungsteam
- Das Product Backlog ist die zentrale Schnittstelle des Teams zum Product Owner.
- Das Team unterstützt bei Schätzung und Aufteilen der Produktfeatures in Stories, die in einem Sprint umsetzbar sind.
- Das Team weist auf Unklarheiten und technische Unsicherheiten hin. Das kann bedeuten, daß vor einer Implementierung zuerst ein Prototyp oder spike, eine Machbarkeitsstudie geschehen muss, um mit diesen Ergebnissen ein Feature oder eine Lösung genauer beurteilen zu können. Umgekehrt kann auch der Product Owner einen Spike initiieren, um so Optionen für Features zu sehen oder sie mit Kunden durchzusprechen und validieren zu können.
- Das Team weist auf technologische Schulden hin und fordert Zeit für Umbauten oder Refactoring. Entwickler kennen das Softwaresystem. Sie können und müssen daher Notwendigkeiten zur Sicherung der inneren Produktqualität formulieren. Der bessere Weg ist natürlich, erst gar keine technischen Schulden aufzubauen. In der Praxis entstehen aber neue Lösung selten unabhängig von Vorhandenem und technische Schulden werden damit vererbt.
Nützliche Spikes, Vorarbeiten und Folgearbeiten sollten auf jeden Fall …
- … eine Timebox zur Begrenzung des Aufwands haben
- … demonstrierbar sein und ein konkretes Ergebnis liefern
- … akzeptierbar sein, also eine Entscheidung über die Zielerreichung ermöglichen
Das Backlog ist ein Katalysator für Kommunikation
Das direkte Gespräch (face-to-face) ist durch nichts zu ersetzen. Das Verstehen einer Anforderung geschieht am Besten und Schnellsten in einem Gespräch. Die konzentrierte Diskussion mit dem Entwicklungsteam und dem PO kann helfen, auf aufwändige und naturgemäß auch fehlerträchtige a priori Spezifikationen zu verzichten.
So wie user stories ein Anlass für Diskussionen sind, mit denen besser und schneller Einvernehmen hergestellt werden kann als mittels formaler und verschriftlichter Spezifikationen ist das gesamte Backlog der Spiegel der Entwicklung.
Merkregel: DEEP
Ein Backlog ist …
Detailed appropriately – angemessen detailliert
Emergent – in laufender Änderung
Estimated – geschätzt
Prioritized – priorisiert
