Anforderungen an die Backlog-Pflege

Es liegt auf der Hand, dass ein Backlog gut gepflegt sein muss, um eine aussagekräftige Projektion in die Zukunft zu ermöglichen. Als Leitgedanke kann das Akronym DEEP dienen. Eine Backlog sollte folgende Kriterien erfüllen:

• Detailed
  Die Items – jedenfalls diejenigen, die unmittelbar zur Bearbeitung durch das Team anstehen – müssen detailliert formuliert sein. Sie sollten das Why, How und What der einzelnen Funktionen beschreiben. Darüber hinaus sollten sie Akzeptanzkriterien enthalten, die umreißen, was funktionieren muss und was vielleicht auch „out-of-scope“ ist, also im Rahmen dieses Items nicht umgesetzt werden soll. Aus dieser Beschreibung sollte ein gemeinsames Verständnis darüber abzuleiten sein, wann dieses Item als fertig betrachtet werden kann.

• Estimated
  Für das Forecasting ist die Abschätzung des Aufwands von zentraler Bedeutung. Der Gesamtaufwand ergibt sich schließlich als Summe der Aufwände der einzelnen Items. Über die Frage, welche Rolle bei dieser Schätzung die Komplexität spielt, ließe sich eine eigene Blog-Serie schreiben. Das Gleiche gilt für den Aspekt des gefühlten Risikos.

• Emergent
  Der Versuch, alle Items eines mittel- oder langfristigen Projektes detailliert zu beschreiben und abzuschätzen, birgt die Gefahr, dass man sich mehr Arbeit macht, als sinnvoll ist. Wir erinnern uns: Im Projektverlauf wird es Veränderungen und Abweichungen geben. Aus dieser Perspektive genügt es völlig, nur die Items vollständig und detailliert beschrieben und abgeschätzt zu haben, die zeitnah vom Team bearbeitet werden. Ein „emergentes“ Backlog darf also durchaus größere, weniger genau beschriebene Items weiter unten haben. Wenn die Items in der Priorisierung zum Kopf der Liste aufsteigen, wird es Zeit, ihnen weitere Pflege zukommen zu lassen.

• Prioritized
  Das Backlog soll priorisiert sein. Die Frage, nach welchen Maßstäben diese Priorisierung stattfinden soll, füllt Bücher und Diskussionsforen. Einigkeit besteht darin, dass diese Aufgabe dem Product Owner vorbehalten ist. Dabei sollte der Wert, der mit einem Feature generiert werden kann – sei es Anwendernutzen oder Business Value – eine zentrale Rolle spielen. Ein möglicher Ansatz dafür könnte die „Weighted Shortest Job First“-Methode sein, die den antizipierten Wert im Hinblick auf Verzögerungskosten („cost of delay“) ins Verhältnis zum Aufwand setzt. Entscheidend ist, dass sich das Team bei der Reihenfolge der Implementierung von Funktionalität immer an den am höchsten priorisierten Items orientiert.

Unser Backlog Forecasting basiert auf einem vollständig abgeschätzten Backlog. Um auf dem Weg zu so einem Backlog ein „big planning upfront“, also eine umfassende und zeitaufwändige Vorausplanung, zu vermeiden, arbeiten wir mit Items auf drei verschiedenen Flughöhen: Initiativen, Epics und User Stories. Diese Vorgehensweise habe ich im vorigen Artikel dieser Serie detailliert erläutert. (Wenn du diesen Artikel noch nicht gelesen hast, ist jetzt vielleicht ein guter Zeitpunkt, um die nachfolgenden Konzepte besser zu verstehen.)

Mit Hinblick auf das Backlog Forecasting bekommt dieser kontinuierliche Verfeinerungsprozess der Anforderungen eine weitere, überaus wichtige Bedeutung. Durch die zunehmende Konkretisierung von Anforderungen auf höherer Flugebene durch Details auf darunter liegenden Flugebenen und durch die Aufwandsschätzung dieser verfeinerten Anforderungen verschiebt sich die Basis für den Forecast zunehmend von großen, nur grob beschriebenen Initiativen hin zu vielen kleinen, detailliert beschriebenen User Stories. Das macht es dem Team erheblich leichter, plausible Einschätzungen abzugeben. Der Forecast wird dadurch schrittweise immer aussagekräftiger und zuverlässiger. Der Cone of Uncerntainty verengt sich

Items, die dieses Kennzeichen tragen, dienen dazu, den Umrechnungsfaktor zwischen den Aufwänden höhere Ebene und den Aufwänden der darunter liegenden Ebene zu berechnen. Wie im vorigen Artikel beschrieben, bedarf es bereits zu Beginn jeweils mindestens eines Items jeder Ebene, das „vollständig verfeinert“ ist, um zu einem ersten Umrechnungsfaktor zu kommen.

Durch die kontinuierliche Verfeinerung und damit verbunden immer mehr Items mit diesem Kennzeichen wird der Umrechnungsfaktor auf einer breiteren statistischen Basis ermittelt. Das führt zu einer zunehmend aussagekräftigeren Abschätzung des Gesamtaufwandes.

Feature Creep

Unter Feature Creep verstehen wir das Anwachsen des Aufwandes im Verlauf des Projektes, z. B. durch vergessene oder neu erdachte Funktionalitäten. In der Theorie erkennt man diesen Feature Creep recht offensichtlich an einem ansteigenden Gesamtaufwand der Projektes.

Unser Forecast kann aber aus zwei Gründen schwanken:

1. Funktionalitäten, die hinzukommen, gestrichen oder auf Grund veränderter Spezifikationen neu geschätzt werden.

2. Veränderungen der Umrechnungsfaktoren durch neue „vollständig verfeinerte“ Items.

Ersteres verändert sozusagen das Gewicht des Backlogs im Sinne der Menge aller Features. Letzteres verändert lediglich die Einschätzung des Gesamtaufwandes. Als Feature Creep im engeren Sinne verstehen wir nur die Veränderungen gemäß des ersten Punktes. Darum haben wir eine Methode entwickelt, die diese beiden Arten der Veränderung von einander unterscheidet und nur den Feature Creep im engeren Sinne als stetiges Wachstum des Backlogs in die Zukunft projiziert.

Nun ist es aber nicht erforderlich, bei der Backlog-Pflege neben den bereits angesprochenen Releases noch diese Scopes hinzuzufügen. Das wäre auch äußerst lästig, denn sobald Now erledigt wäre, müssten ja alle mit Nextmarkierten Items auf Now umgeschrieben werden. Um die Pflege der Scopes aus der eigentlichen Backlog-Pflege herauszuhalten, bietet unser Forecasting ein Scope-Mapping an. Über eine einfache Zuordnung können ein oder mehrere Releases während der Auswertung dem Scope Now oder Next zugeordnet werden. Darüber hinaus können ein oder mehrere Releases dem Scope Laterzugeordnet werden, was zur Folge hat, dass diese Releases aus dem Scope MVP ausgenommen werden.

Die Visualisierung dieses Wachstums hilft im gesamten Projektverlauf dabei, den Fokus auf die ursprünglich vereinbarten Ziele nicht aus den Augen zu verlieren und gleichzeitig verantwortungsbewusst und maßvoll Veränderungen zum Wettbewerbsvorteil des Kunden zuzulassen.

Zusammenfassung und Ausblick

Um eine aussagekräftige Prognose über den Verlauf eines Projektes zu erhalten, genügt eine gründliche Backlog-Pflege. Mehraufwand wird nicht erforderlich. Und gleichzeitig erleichtert diese gründliche Pflege die Arbeit des Teams beträchtlich und verbessert die Produktivität.

Das einzige Merkmal, das der bisherigen Backlog-Pflege hinzugefügt wird, ist die Kennzeichnung vollständig verfeinerter Items auf höherer Flugebene. So werden im Verlauf der Backlog-Pflege die Umrechnungsfaktoren zur Ermittlung des Aufwands auf höherer Flugebene zunehmend geschärft, was zu aussagekräftigeren Abschätzungen führt.

Feature Creep kann in zwei Dimensionen auftreten: Durch das Hinzufügen, Entfernen oder Neugewichten von Anforderungen und durch die Schärfung der Umrechnungsfaktoren. Letzeres betrachten wir als Lernen. Darum interpolieren wir nur die Veränderungen der Anforderungen selbst als Feature Creep in die Zukunft.

Der Forecast wird durch die Release Scopes Now, Next, MVP und Later fokussiert. Dadurch wird vermieden, zu tief in einen Nebel hinein zu planen.

Wenn du jetzt neugierig geworden bist, wie wir technisch zu diesem Forecast kommen, bleib dran. Das werde ich im nächsten Teil dieser Artikelserie detailliert erklären.