Agile Produktplanung – Vom Backlog zum Forecast | 2/2

In unserem ersten Blogbeitrag „Agile Produktplanung – Wirf einen Blick in eines unserer Projekte“  hast Du bereits erfahren, wie wir die Ziele und das Backlog für die agile Produktentwicklung definiert haben. Nahtlos knüpfen wir nun daran an und zeigen Dir, wie wir anschließend mit einfachen Mitteln aus den Backlogitems einen Forecast erstellen. Dafür eignet sich eine relative Schätzung der Backlogitems sowie der Velocity des Teams. Dieser Forecast hilft uns zu verstehen, was zu einem bestimmten Zeitpunkt umgesetzt sein wird und dient anschließend außerdem auch als Grundlage für die Kommunikation mit allen Stakeholdern.

Alles ist relativ - Die Schätzung mit Magic Estimation

Um die Größe der verschiedenen Backlogitems einzuschätzen, nutzen wir die Magic Estimation Methode. Magic Estimation gehört zu den relativen Schätzverfahren und ermöglicht es, den Umfang mehrerer Backlogitems in einer sehr kurzen Zeit zu schätzen. Das ist deswegen möglich, weil es fast komplett im Stillen durchgeführt wird, also ohne, dass Teammitglieder sprechen und sich unbeabsichtigt in langwierigen Diskussionen verzetteln. Besonders eingespielte Teams erlangen so eine hohe Schnelligkeit und können zugleich die Items auf Basis von Erfahrungswerten immer präziser einschätzen. Auch wir konnten so zum Beispiel in der Vergangenheit bereits einmal 100 Items innerhalb von 2 Stunden schätzen.

Vorbereitung

Zunächst sammeln wir die Backlogitems, die zu diesem Zeitpunkt als User Stories ausgearbeitet sind und platzieren diese auf der linken Seite eines Brown Papers oder eines Online-Whiteboards. Rechtsdavon wird die Fibonacci-Skala in einer Zeile abgebildet und eine dazugehörige Referenz für jeden Wert vorbereitet. Dafür nutzen wir bereits abgeschlossene Epics oder Stories, die den Wert auf der Skala besonders gut repräsentieren. Das erleichtert allen Beteiligten, den Umfang der jeweiligen Epics einzuschätzen, da direkte Vergleichswerte vorliegen. Auch bei dem Begriff Epic ist es unserer Erfahrung nach hilfreich, eine einheitliche Begriffsklärung zu definieren. In unserem Projekt haben wir zum Beispiel ein Epic als Story definiert, die nicht in einen Sprint passt. Die Grenze lag hier bei 21 Fibonacci-Punkten bzw. Storypunkten. Ein Sprint umfasste dabei 14 Tage.

Neben der Fibonacci-Skala dürfen natürlich auch zwei Kategorien nicht fehlen: Eine Kategorie mit einem “?” und eine mit einer “Tee- oder Kaffeekanne”. Legt jemand während der Schätzung ein Item auf die Teekanne, ist es Zeit für eine Pause. Items unter dem Fragezeichen sind hingegen so unklar, dass sie nicht geschätzt werden können. Unserer Erfahrung nach tritt dies auf, wenn Stories nicht verständlich genug geschrieben sind. Sind alle notwendigen Vorbereitungen abgeschlossen, sieht das Tableau dann so aus:

Schätzung

Ist das Tableau vorbereitet und das Scrum-Team eingeladen, kann die Schätzung beginnen. Um möglichst viele Blickwinkel zu erhalten, empfehlen wir die Schätzung in einem interdisziplinären Team durchzuführen. Teammitglieder können hier zum Beispiel Product Owner, Scrum Master und Entwickler mit verschiedenen Spezialisierungen sein. Zudem bietet es sich auch an, einen Moderator hinzuzuziehen, der mit dem Ablauf der Schätzung vertraut ist. Diese Schätzung der Backlogitems läuft dann wie folgt ab:​​

1. Die Teilnehmenden nehmen sich, ohne zu sprechen, die Epics links vom Board, bewerten den Aufwand des Epics und sortieren es unter eine aus ihrer Sicht passende Referenz​​.

2. Danach nehmen die Teilnehmenden entweder ein weiteres Epic oder verschieben eines, welches ein anderer Teilnehmer bereits bewertet hat. Jedes Mal, wenn ein Epic verschoben wird, bekommt dieser eine Kennzeichnung in Form eines Punkts.

3. Danach werden die Schritte 1 und 2 so oft wiederholt, bis alle Items geschätzt sind​​.

4. Nur die Epics mit 3 oder mehr Punkten werden im Team diskutiert und anschließend gemeinsam erneut geschätzt​​.

​​Nachdem alle Epics vom Team geschätzt wurden, sieht das Ergebnis zum Beispiel wie folgt aus:

Die Velocity als Basis für einen realistischen Forecast

Letztendlich lässt sich das Ergebnis – also der Forecast – mit einer Wettervorhersage vergleichen. Auch er basiert auf empirischen Werten der Vergangenheit, in unserem Fall der Velocity des Teams. Wenn das Team neu ist, empfiehlt es sich deshalb, dass es bereits 3-4 Sprints durchläuft, um anfängliche Schwankungen hinter sich zu lassen und realistische Werte der Velocity für den Forecast nutzen zu können. Die Dauer bis sich ein Team eingespielt hat, kann dabei sehr variieren. In unserem Fall arbeitet das Team bereits einige Sprints zusammen, sodass die Schätzung deutlich leichter verläuft und alle Teammitglieder ein einheitliches Verständnis haben.

Da unsere Stakeholder interessiert, welcher Output nach insgesamt 7 Sprints – also 14 Wochen – zu erwarten ist, errechnen wir die durchschnittliche Velocity der letzten 7 Sprints. In unserem Fall liegt diese bei 131 Storypunkten. Dadurch können wir den durchschnittlichen Fall errechnen. Da eine Varianz nicht auszuschließen ist, werfen wir zudem einen Blick darauf, was das Minimum und das Maximum in der Vergangenheit umfasste. Das Minimum lag bei 80% der Durchschnittsvelocity. Dadurch fallen 2 Epics raus. Im besten Fall schafft man sogar 120%, also noch 2 Epics mehr​​. Dadurch ergibt sich zwischen den 80% und 120% ein „Kegel der Unsicherheit”, welchen man mit den Stakeholdern kommunizieren kann – wie bei einer Wettervorhersage. Mit Hilfe eines Burndown-Charts oder Burnup-Charts könnte man den Sachverhalt natürlich auch als Kegel kommunizieren. Wir haben meistens die Darstellung mit dem fachlichen Prozess gewählt, da sich hier die Stakeholder am ehesten wiederfinden.

Da die Schätz- und Forecasttechnik mit Magic Estimation so schnell durchführbar ist, können neue Erkenntnisse zügig in die Planung einfließen, indem Teilschritte der Planung wiederholt werden. Auch das Requirements Engineering ist hier natürlich noch nicht zu Ende. Die Epics werden verfeinert, in User Stories geschnitten und durch Akzeptanzkriterien detailliert und mit weiteren Artefakten wie Modellen und UI-Prototypen angereichert. Mehr zu diesen Punkten erfährst Du in unserer Webinar-Aufzeichnung „So unterstützt agiles Requirements Engineering Deine Produktplanung“. Dort erklären wir Dir ausführlich, wie Du mit allen Beteiligten eine gemeinsame Produktvision etablierst und lebst.

Du bist auf der Suche nach professioneller Unterstützung in Deinem agilen Produktentwicklungsprojekt? Dann nimm jetzt ganz unverbindlich Kontakt mit uns auf und erfahre, wie Dir unsere Scrum-Teams bei Deinem Projektvorhaben behilflich sein können.