Teil 1: Backlog-Pflege

Einleitung

In diesem Beitrag möchte ich die operativen Vor- und Pflegearbeiten am Backlog beschreiben, die erforderlich sind, um kontinuierlich Forecasts zu erhalten, die es dem Kunden erlauben, im gesamten Projektverlauf informierte Entscheidungen zu treffen. Spoiler: Es geht nicht um Mehrarbeit, sondern darum, die ganz normale Backlog-Arbeit konsequent und zielgerichtet zu gestalten.

Dieser Artikel ist Teil 3 einer Serie:

1. WHY honest estimates?
   Warum eine ehrliche und solide Schätzung die bessere Grundlage für ein erfolgreiches Projekt darstellt.

2. HOW meaningful estimates?
   Wie kommen wir zu aussagekräftigen Abschätzungen als Grundlage informierter Entscheidungen?

Wenn du dich jetzt fragst, ob dieser Artikel für dich relevant ist, obwohl du die Projektmanagement-Tool XYZ verwendest, kommen hier gleich zwei gute Gründe weiterzulesen:

• Ein aussagekräftiges Backlog-Forecasting braucht mehr als das Zusammenrechnen und Interpolieren von ein paar Zahlen. Wenn du die beiden ersten Artikel dieser Serie gelesen hast, hast du hoffentlich sehr hohe Erwartungen an unsere Vorgehensweise. Eine so differenzierte und optimierte Methodik können die Tools zumindest mit Boardmitteln nicht anbieten. 

• Ganz egal, welches Tool du heute für deine Backlog-Arbeit nutzt, unser Forecasting-Konzept ist agnostisch gegenüber der eingesetzten Plattform. Anders würde es in unserem Umfeld gar nicht funktionieren, weil wir sehr häufig in der Tool-Landschaft arbeiten, die unsere Kunden mitbringen.

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.

Wer die Eigenschaft der Emergenz jetzt als Rechtfertigung dafür versteht, nur ein paar wenige Items im Backlog vollständig auszudefinieren, wird durch ein produktives Team schnell in die Wirklichkeit zurück geholt. Je besser der Product Owner die Items am Kopf der Liste beschreibt und je klarer daraus hervorgeht, was erwartet wird und was nicht, desto effizienter wird das Team diese Items abarbeiten. Das bedeutet, ein gutes Team ist auf einen ebenso guten Product Owner angewiesen, der dafür sorgt, dass am Anfang des nächsten Sprints wieder ebenso viele gut beschriebene Items für den Produktivitäts-Hunger des Teams zur Verfügung stehen. Kannst du dir vorstellen, was für eine Energie in diesem Zusammenspiel stecken kann? Wenn diese Hand-in-Hand-Arbeit gut funktioniert, sehen wir die sogenannten hyperproduktiven Teams, die wir im agilen Kontext anstreben.

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.

Vollständig verfeinert

Unser Konzept des Backlog Forecastings führt ein einziges neues Attribut ein, das ebenfalls im Zuge dieses Verfeinerungsprozesses gepflegt wird: Immer, wenn ein Item höherer Ebene vollständig durch die Items der darunter liegenden Ebene beschrieben wurde und diese Items vom Team abgeschätzt worden sind, erhält das Item der höheren Ebene die Kennzeichnung „vollständig verfeinert“.

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.

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.

Release Scope

Um nicht zu weit in einen undurchdringlichen Nebel hinein planen zu müssen und damit die Aussagekraft jeder Vorhersage ad absurdum zu führen, empfiehlt es sich, den Ausblick so nah wie möglich auf die relevante Zukunft zu begrenzen. Es bietet sich an, auf einzelne Releases – man könnte sie auch Meilensteine nennen – zu schauen. Die meisten Backlog-Pflege-Tools bieten die Möglichkeit, Items einem bestimmten Release zuzuordnen. Im Verlauf einer typischen Backlog-Pflege kommen dabei sehr viele Versionen zusammen. Für unser Forecasting-Tool stellt sich die Herausforderung, diese Releases in eine zeitliche Abfolge zu bringen und dynamisch zwischen abgeschlossenen, unmittelbar bevorstehenden und zukünftigen Release zu unterscheiden.

Wir haben uns dafür des Now/Next/Later-Modells bedient und so diese Unterscheidung vollständig in die aktuelle Auswertung verschoben.

Um genau zu sein, unterscheiden wir vier Release Scopes:

1. Now: Das Release, an dem aktuell gearbeitet wird.

2. Next: Das Release, an dem gearbeitet wird, sobald die Arbeiten am aktuellen Release abgeschlossen sind. Dabei werden ebenfalls alle offenen Aufwände von Nowberücksichtigt.

3. MVP: Alle Features des Projektes, mit Ausnahme derer, die explizit als Later markiert sind.

4. Later: Alle Features des Projektes.

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.

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.