Lektion Progress
0% Complete

Übersicht: Backlog

Das oder der Product Backlog (PBL) ist die gemeinsame und transparente Basis agiler Planung. Einträge im Backlog sind items oder PBIs (product backlog items).

Agile Planung basiert auf der Zerlegung von Features in kleine, werterzeugende Teile. Einträge im Backlog beschreiben WAS erreicht werden soll. In welcher Form das WAS erreicht wird, das WIE zu finden, ist Aufgabe des Teams. Konkrete Aktivitäten werden vom Team erst in der Sprint-Planung abgeleitet.

Das Backlog ist der gemeinsame und transparente Ort, an dem funktionale und nicht-funktionale Anforderungen gepflegt, detailliert und geordnet werden.

Die Sortierung nach absteigendem Wert priorisiert nach der wiederkehrenden Frage ‘was bringt zu diesem Zeitpunkt den größten Kundennutzen?`Akut wertstiftenden items sind somit hoch priorisiert und kommen zuerst in die Umsetzung.

Inhalt des 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

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.

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

Merkregel DEEP
Scroll to Top