Guidelines / Backlog im FAST Kontext

Backlog im FAST Kontext

Backlog

Das Backlog ist die priorisierte Liste von Anforderungen für die jeweilige Arbeitsebene im FAST.

Es dient zur Vorbereitung und Strukturierung eines „Vorrats“ an Inhalten, die dann in Folge in die unterschiedlichen Arbeitsebenen für die nächste Iteration eingeplant werden. Auf diese Weise wird in FAST nicht nur die Feinheit der Anforderungen, sondern auch die zeitliche Dimension unterschieden. Dies führt zu einer deutlich klareren Struktur für alle Beteiligten bis auf Führungsebene.

Daraus ergeben sich folgende Backlogs:

Planning Backlog 

Resultierend aus dem Year/Season Planning, ergeben sich Backlog Items (meist Use Cases), welche für die weiteren Planungen in kleinere Elemente zerlegt werden. Dennoch handelt es sich hierbei in der Gesamtheit um ein Backlog, welches aber in der Regel nach der Season Planning bis zur nächsten SeasonPlanning nicht mehr betrachtet wird.

Program Backlog 

Das Program Backlog bildet die Menge aller Backlog Items, welche in der aktuellen Season über alle Products ausgewählt worden sind. Ein Program Backlog ergibt nur Sinn. wenn mehrere Products/Teams mit FAST abgebildet werden.

Product/Team Backlog 

Das Product Backlog im FAST Kontext bildet die Menge der Backlog Items, welche in der aktuellen Season auf die Sprints eines Teams verteilt werden. Es kann auch bereits erstellte und auf zukünftige Seasons geplante Items enthalten.

Das Product Backlog sollte für die aktuelle Season vom Aufwand möglichst vollständig und durchdacht sein. Es ist aber nicht nötig, bereits detailliert in die Items am Ende der Season einzusteigen oder diese bereits alle vollständig auszuformulieren. Dennoch kann dies ggf. Sinn ergeben, um unerwartete Blocker zu erkennen und zu behandeln.

 

Die Option, nicht zu detailliert zu arbeiten, entbindet den Product Owner nicht davon, die Items zu bewerten.

Grundsätzlich: Items, die geplant sind, werden vielleicht erledigt. Nicht vorhandene Items werden nicht erledigt!

Der Unterschied zum klassischen Scrum: Es werden die Sprints der gesamten Season vorgeplant. Das Backlog Grooming findet in bereits vorgeplanten Sprints statt. 

Sprint Backlog 

Der Sprint Backlog ist eine Sammlung aller Product Backlog Items, die das Scrum-Team für den jeweiligen Sprint ausgewählt hat. Zudem stellt der Sprint Backlog einen Plan dar. Aus ihm lässt sich ablesen, wie das Sprint-Ziel erreicht werden soll.

⚠️Sprint Backlogs sind für die gesamte aktuelle Season vorgeplant.

Das Sprint Backlog des aktuellen Sprints stellt die aktuell laufende/geleistete Arbeit dar. Der Inhalt dieses Sprint Backlogs ist grundsätzlich erstmal fix und darf nur durch den Product Owner in Abstimmung mit dem Team verändert werden.

Kommt es zu Veränderungen im aktuellen Sprint Backlog oder werden Items nicht oder nur teilweise erledigt, dann müssen die Abhängigkeiten beachtet und kommuniziert werden – sowohl für Nachfolge-Sprint-Items als auch in Sprints anderer Value Streams des Programms.

Wenn die Abhängigkeiten geklärt und aufgelöst sind, dann gibt es 2 Möglichkeiten:

  1. Es wird dieses Item vom Umfang (Storypoints) reduziert auf den verbleibenden Umfang. Danach (meistens) in den  nachfolgenden Sprint übernommen. Das Wachstum des nachfolgenden Sprints wird erst in dem jeweiligen Sprint Planning besprochen.

  2. Es wird nicht reduziert, da die Arbeit geleistet und ein Nachfolge-Item angelegt wurde, welches den verbleibenden Umfang darstellt und ebenfalls (meistens) in den  nachfolgenden Sprint übernommen wurde. Am besten verwendet man in diesem Fall eine Versionierung (v0.8 und v1.0) für die Items. Anschließend kann das ursprüngliche Item auf Fertig gesetzt werden.

Items ins Backlog verschieben

Im generellen Sprachgebrauch wird häufig der Begriff „ins Backlog verschieben“ verwendet, wenn man Sprint Backlog Items aus einem Sprint nimmt und ins „Backlog“ verschiebt. Dieses Backlog ist ein unbestimmter Raum und sollte nach Möglichkeit nicht stark verwendet werden. Beim Verschieben von Backlog Items sollte bestimmt/diskutiert werden, wann diese erledigt und dann entsprechend direkt eingeplant werden.

Backlog Eigenschaften

Gute, erfolgreiche Backlogs weisen folgende Kriterien auf:

 

⚠️ Ideensammlungen, Reminder und Geistesblitze sind keine Backlog (Items)

Backlog Überarbeitung – Refinement/Grooming 

Das Wichtigste zum Schluss: Jedes Backlog muss kontinuierlich bearbeitet werden. Das ist eine der Hauptaufgaben des jeweiligen Owners. Der Owner ist gemeinsam mit dem Scrum Master verantwortlich für den Erfolg des Teams. Der Owner trägt dabei sowohl die Verantwortung für die inhaltliche Arbeit als auch deren Priorisierung.

Deshalb sollte sich jeder Owner sehr viel Zeit nehmen für die kontinuierliche Überprüfung und Überarbeitung des Backlogs, und dieses auch ständig an aktuelle/neue Rahmenbedingungen anpassen.