In einem früheren Artikel hat mein Kollege Holger Jahn beschrieben, warum wir ehrliche und transparente Schätzungen des Projektaufwandes als ein notwendiges Mittel ansehen, um mit unseren Kunden zusammen erfolgreiche Projekte zu gestalten. In diesem Artikel möchte ich der Frage nachgehen, wie wir zu einer soliden und aussagekräftigen Abschätzung kommen und was dafür nötig ist, diese Einschätzung im gesamten Projektverlauf als Grundlage informierter Entscheidungen nutzen zu können, sowohl beim Kunden als auch bei uns als Dienstleister.

Erwartungsmanagement

Transparente Abschätzungen erlauben den Austausch über die Prognosen. Die Projektion des Projektverlaufes in die Zukunft ermöglicht es allen Beteiligten, ihre Erwartungen mit der vorliegenden Situation abzugleichen. Wichtige Meilensteine, die es in ganz vielen unserer Projekte gibt, erhalten dabei die nötige Aufmerksamkeit. Eine Frage, die damit eng verbunden ist, lautet: „Kann der erwartete Umfang zum erwarteten Zeitpunkt geliefert werden?“ Selbst, wenn diese Frage zu Beginn des Projektes mit einem überzeugten „selbstverständlich“ beantwortet werden kann, gibt es in vielen Projekten im Verlauf unliebsame Überraschungen. Besonders ärgerlich und gleichzeitig verbreitet ist die späte Erkenntnis nur kurz vor dem avisierten Termin, dass nicht alle Erwartungen erfüllt werden können. Zu diesem Zeitpunkt ist es meist viel zu spät, um wirkungsvolle Maßnahmen zu ergreifen. Hier hilft in aller Regel nur noch der mehr oder weniger schmerzhafte und kostspielige Weg der Terminverschiebung.

Dazu ist es von besonderer Bedeutung, die Vorhersagen regelmäßig zu aktualisieren und zu diskutieren, statt sich nur einmal zu Beginn des Projektes und ein weiteres Mal kurz vor Abschluss gegenseitig in die Augen zu schauen und offen über Fortschritt und Reststrecke des Projektes zu sprechen. Wenn wir die Erkenntnis gewinnen, dass wir uns zu viel vorgenommen oder zu wenig Ressourcen für das Projekt bereitgestellt haben, bestehen zu einem frühen Zeitpunkt im Projektverlauf noch eine ganze Reihe von Optionen. Wir können dem Projekt mehr Entwickler:innen zur Verfügung stellen, den Funktionsumfang begrenzen, ein Teil-Release anstreben oder – ja, zu diesem Zeitpunkt vielleicht noch relativ schmerzfrei – den Termin verschieben.

All dies gelingt nur, wenn wir Klarheit über die Erwartungen der Projektbeteiligten erzielen. Das geht über die Absprachen auf kaufmännischer Ebene hinaus. Auch die Entwickler:innen brauchen einen klaren Blick auf die Erwartungen des Kunden. Sie sind es schließlich, die in agilen Projekten entscheiden, wieviel des geplanten Funktionsumfanges in einer Iteration der Entwicklung umgesetzt werden kann. Sie sollten also auch einen transparenten Blick darauf erhalten, was das für den Horizont des Projektes und damit verbunden auch für die Erwartungen des Kunden bedeutet. Dadurch wird Selbstverantwortung und Motivation im Entwicklungsteam gefördert.

Schleichendes Wachstum des Funktionsumfanges

Ein beträchtlicher Teil agiler Projekte erlebt es, das schleichende Wachstum des Funktionsumfanges, engl. „Feature Creep“ genannt. Und es ist Teil der agilen Herangehensweise, dass „Änderungen (i.e. Wachstum) des Funktionsumfanges“ grundsätzlich willkommen geheißen werden. Gleichzeitig darf dieses Wachstum nicht bedeuten, dass wichtige Ziele aus den Augen verloren und schließlich die gesteckten Erwartungen nicht erfüllt werden können. Darum ist es von immenser Bedeutung, das Wachstum des Funktionsumfanges sichtbar zu machen, damit auch dies eine „informierte Entscheidung“ der Projektbeteiligten bleibt und alle damit verbundenen Folgen für Termin und Kosten transparent werden.

Die übliche Technik: Release-Burnup-Graphen

Der Burnup-Graph ist das altbekannte Mittel, aus den Abschätzungen für den Aufwand und der Erfahrung aus dem Projekt (Entwicklungstempo, engl. Velocity) eine Projektion in die Zukunft zu erstellen. Dort, wo sich die Fortschreibung der angenommenen Velocity mit dem abgeschätzten Gesamtaufwand trifft, darf das Release als abgeschlossen betrachtet werden.

Je nach Umfang des Projektes kann diese auf den ersten Blick sehr einfache Technik allerdings ernsthafte Nebenwirkungen mit sich bringen. Denn die Voraussetzung für die Aussagekraft eines Burnup-Graphen besteht darin, dass alle Aufwände erfasst sind. In einem üblichen agilen Product Backlog bedeutet das: Alle relevanten Funktionen müssen in Form von Product Backlog Items im Backlog repräsentiert sein und sie alle müssen abgeschätzt sein. Nur so kann der Gesamtaufwand des Projektes und mithin die Ziellinie für den Graphen bestimmt werden. Fehlen Funktionen oder auch nur deren Abschätzungen, werden unvollständige oder gar falsche Erwartungen kommuniziert.

Daraus resultiert möglicherweise der Wunsch der Projektverantwortlichen nach einer umfassenden Planung im Vorfeld des Projektes (engl. „big planning upfront“), wie wir sie aus Projekten kennen, die nach dem Wasserfall-Prinzip umgesetzt werden. In agilen Umgebungen wird diese zeitaufwändige Planungsphase vor Projektstart allgemein als Verschwendung (engl. „waste“) betrachtet, weil ein beträchtliches Risiko besteht, dass sich Teile der Planung zum Zeitpunkt ihrer Umsetzung bereits als undurchführbar oder unnütz herausgestellt haben.

Wie können wir diesem unerwünschten Muster (engl. „anti-pattern“) entgehen?

Die Antwort kann lauten: Durch mehrstufige Backlogs.

Mehrstufige Backlogs

Anders, als im herkömmlichen Backlog, werden die Funktionen nicht ausschließlich mit Hilfe von mehr oder weniger detaillierten User Stories beschrieben. Es werden gezielt verschiedene Abstraktionsebenen oder Flughöhen genutzt, um Funktionen zu beschreiben. Bekannt sind diese Flughöhen aus dem User Story Mapping (Jeff Patton).

Vogelflug

Auf höherer Flugebene, aus Vogelflug-Perspektive, sehen wir Zusammenhänge verschiedener Arbeitsschritte zu einem übergeordneten Ziel. Oft ist dies die Abstraktionsebene, die das Produktmanagement oder der Vertrieb für die Kommunikation mit potenziellen Kunden bevorzugt.

Wir nennen die Aufgaben auf dieser Ebene „Initiativen“. Entsprechend benennen wir den Aufwand mit „Initiativ-Punkten“.

Meereshöhe

Die mittlere Ebene, sozusagen die „Meereshöhe“, stellt ein „Walking Skeleton“ dar, einen erzählbaren, sequenziellen Ablauf der Arbeitsschritte aus Sicht der Anwender:innen.

Bei Aufgaben auf dieser Ebene sprechen wir von „Epics“. Wir schätzen den Aufwand dieser Aufgaben in „Epic Points“.

Unterwasser

Die Details, Varianten, Optionen usw. zu den einzelnen Arbeitsschritten finden sich unter dem Meeresspiegel. Das sind in der Regel die Dinge, die ein Entwicklungsteam umsetzen muss, um die gewünschte Funktion für die Anwender:innen verfügbar zu machen.

Auf dieser Ebene finden wir die vielzitierten „User Stories“, die wir wie üblich in „Story Points“ abschätzen.

Ein vollständiges Backlog und dessen Abschätzung

Es ist wichtig zu verstehen, dass der Aufwand für eine Funktionalität bereits durch ein Item auf höchster Ebene repräsentiert werden kann, ohne dass notwendigerweise die Abläufe geklärt oder gar alle Einzelheiten beschrieben sind.

Wenn wir sicherstellen, dass wir alle Funktionalitäten, die sich derzeit im Erwartungshorizont des Projektes befinden, auf höchster Flugebene zumindest in Form von Initiativen benannt haben, können wir schon einmal von einer gewissen Art der Vollständigkeit sprechen.

Wenn wir weiterhin jede dieser Initiativen mit einer Abschätzung anreichern und wir darüber hinaus eine erste Idee haben, wie wir Initiativ-Punkte in Epic Points und Epic Points in Story Points umrechnen können, dann können wir die Abschätzungen in Story Points umrechnen, alles aufsummieren und mithin von einem vollständig abschätzten Backlog sprechen.

Backlog-Arbeit und der letzte verantwortbare Zeitpunkt

Natürlich muss das Backlog im Verlauf des Projektes um alle notwendigen Details ergänzt werden, bevor die Entwickler:innen die entsprechende Funktionalität umsetzen können. Wie oben schon gesagt, ist es aus agiler Sicht sinnvoll, diese Ergänzung so spät wie möglich vorzunehmen. Das entspricht einer Verschiebung von Entscheidungen auf den „letzten verantwortbaren Zeitpunkt“. Das ist eine sehr wichtige Maxime, die es uns erlaubt, Entscheidungen so spät wie möglich und gleichzeitig so früh wie nötig zu treffen. Das ist genau der Zeitpunkt, an dem wir durch zurückliegende Erfahrungen maximal viel wissen, um eine informierte Entscheidung zu treffen.

Die kontinuierliche Arbeit am Backlog, das Ausformulieren von Abläufen und das Hinzufügen von Details ist ein übliches und notwendiges Vorgehen in jedem agilen Projekt, das wir „Backlog Refinement“ nennen.

Im Zuge dieses Refinements werden zunehmend mehr Initiativen in Epics verfeinert und zunehmend mehr Epics werden um Details, um User Stories ergänzt. Genauso beruhen unsere Schätzungen anfangs auf sehr vagen Beschreibungen großer Initiativen, werden aber im Projektverlauf ebenfalls verfeinert und basieren zunehmend auf den Epics und schließlich auf den Details, den Abschätzungen einzelner User Stories. So wird sukzessive Unsicherheit und Risiko in den Schätzungen verringert. Die Vorhersage wird stabiler und zuverlässiger.