✁
digitalien.org — Stefan Knecht
Der Backlog
Das (oder der) Backlog ist der einzige Ort, an dem funktionale und nicht-funktionale Anforderungen gepflegt, detailliert und geordnet werden.
Der Product Backlog (PBL) ist die gemeinsame und transparente Basis agiler Planung, die auf der Zerlegung von Features in kleine, werterzeugende Teile besteht.
Einträge im Backlog sind items oder PBIs (product backlog items).
Einträge im Backlog, PBIs beschreiben WAS erreicht werden soll. WIE das WAS erreicht wird, ist Aufgabe des Teams. Konkrete Aktivitäten werden vom Team erst in der Sprint-Planung abgeleitet.
Die Sortierung der PBIs nach absteigendem Wert priorisiert die wiederkehrenden Frage ‘was bringt zu diesem Zeitpunkt den größten Kundennutzen?`
Akut wertstiftenden items sind somit hoch priorisiert und kommen zuerst in die Umsetzung.
Im Scrum Flow ist das Backlog damit der Drehpunkt für alles weitere.
Wenn nicht in Scrum gearbeitet wird: es ändert nichts — der Backlog ist der single point of truth.
In der Ordnung des Backlogs werden weitere Kriterien berücksichtigt, z.B. Kosten, Risiken und Abhängigkeiten, auch Lern- und Rechercheaufgaben oder Verbesserungen aus Retrospektiven.
Was steckt im Backlog?
Das Backlog ist ein Container für ‘Wert’ als Kundennutzen, eine Liste von Eigenschaften des Produktes und bildet die Vorarbeit für zukünftige Wertschöpfung und notwendige Nacharbeiten ab — und alles, was das Team noch zu tun hat um diesen Wert zu heben.
Nicht enthalten sein sollten Verfeinerungen ‘auf Vorrat’: Items veralten, je weiter sie in die Zukunft weisen und müssten dann erneut an die dann bekannten Umstände und Details angepasst werden.
- neue Funktionalität, bevorzugt als User Stories formuliert
- Versuche, Experimente und Vorarbeiten (spikes) mit denen Unsicherheit über das weitere Vorgehen reduziert werden können. Das kann ein ‘Durchstich’ für die Anbindung einer neuen mobilen Plattform an eine Applikation sein. Oder rein technische Spikes, die Klarheit zur Machbarkeit schaffen. Oder funktionale Spikes, mit denen Funktionen so skizziert werden, dass Kunden sie konkret testen können.
- Technische Vorarbeiten für neue User Stories sind mit Bedacht einzusetzen. Technische Eigenschaften sind besser in der ersten User Story aufgehoben, in der sich das technische Problem stellt. Das bedeutet, zwar rechtzeitig, aber so spät wie möglich. Je später, desto genauer sind die Anforderungen verstanden.
- Folgearbeiten für technologische Schulden wie Wartungsarbeiten, größere Bugfixes, Refactoring oder das nachträgliche Erstellen von Tests für vorhandenen Code aus umgebenden Systemen.
Die folgende Tabelle zeigt ein Beispiel, wie unterschiedliche Typen von Einträgen im Product Backlog koexistieren können. Damit der Product Owner die items miteinander vergleichen und ordnen kann, braucht er vom Team Angaben über den Umfang der Einträge. Diese können z.B. in story points (relative Schätzgröße) angegeben werden oder in Form einer maximalen Timebox bzw. Kapazität.
| Was | Beispiel | Umfangsangabe | Kommentar |
| neue Funktionalität | Epics / user stories | story points | Story Points gegen Nutzen abwägen |
| Research | spikes Experimente | Timebox | maximale Kapazität zuordnen |
| Schulden | größere Bugs Refactorings | Timebox | maximale Kapazität zuordnen |
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 zwischen Menschen.
Die konzentrierte Diskussion zwischen Entwicklungsteam und PO kann auch helfen, auf aufwändige und naturgemäß 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.
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 oder Zyklus ausgewählt werden.
Merkregel zur Rangierung des Backlog: DEEP
Ein Backlog ist …
Detailed appropriately – angemessen detailliert
Emergent – in laufender Änderung
Estimated – geschätzt
Prioritized – priorisiert
Umfang und Tools
Das Product Backlog soll eine überschaubare Größe haben, 30-80 Stories und Epics sind handhabbar. Hunderte items erschweren den Überblick.
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.
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.
Product Owner pflegen und entwickeln mit dem Team auch andere Dokumente wie Story Maps und Impact Maps, mit denen längerfristige Planung und Produktgestaltung unterstützt werden.
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