Des Product Owners Dilemma

„Bis zum 30.11. muss das neue Produkt geliefert sein, koste es was es wolle“ – wer in der Produktentwicklung kennt nicht einen solchen Satz seiner Stakeholder*innen? Oder: „dann macht Ihr halt Überstunden wenn die Deadline näher rückt!“ ist auch sehr häufig anzutreffen. „Kann die IT mal schätzen, ob sie Scope X bis zum Ende nächsten Quartals schaffen werden?“ Schön ist auch: „Wir benötigen einen Projektplan, um die Risiken des Projekts besser zu managen.“

Wie kann man als Product Owner bzw. als Entwicklungsteam konstruktiv mit diesem Druck umgehen und die folgenden Ziele souverän erreichen?

• Sind wir noch „on track“ oder müssen wir schon eine Verzögerung eines Releases kommunizieren?
• Wie können wir vermitteln, dass das zusätzlich gewünschte Feature X das Lieferdatum ernsthaft gefährdet?
• Wie können wir vermeiden, dass vorab ausführlich der Scope geschätzt wird, aber gleichzeitig schnell ein Gefühl für die Machbarkeit entwickelt wird?

Die Neu- und Weiterentwicklung eines Produktes für Kunden ist eine hochkomplexe Angelegenheit. Unwägbarkeiten lauern an jeder Ecke. Welche Features den meisten Kundenwert bringen, welche Anforderungen genau wie umgesetzt werden müssen, und wie lange genau die Entwicklung bestimmter Funktionen dauern wird ist kaum planbar. Insbesondere, wenn man sich mit einem neu zusammengesetzten Team auf den Weg macht, sind viele Unbekannte im Spiel.

Umso verständlicher ist es daher, dass ein solches Vorhaben iterativ angegangen und empirisch gemanagt werden sollte. Das liegt im Kern agiler Produktentwicklung und bedeutet, dass die zu erledigenden Tätigkeiten nicht von Anfang feststehen, sondern sich über die Zeit entwickeln. Man versucht, sich in möglichst kleinen Schritten an sein Ziel heran zu arbeiten, damit man jederzeit auf neu entstandenes Wissen oder Veränderungen reagieren kann. Ein Problem, das dabei für Sponsoren und Produktverantwortliche entsteht ist, dass es sehr schwierig wird, Vorhersagen über die Fertigstellung von Milestones oder gar des gesamten Produktes zu treffen.

Wir nutzen dazu in unserer Produktentwicklung einer eCommerce-Plattform sogenannte Burn-up Charts, um stets über unseren Fortschritt zu reflektieren und Forecasting für unsere Sponsoren zu ermöglichen. Wie das geht, beschreiben wir nachfolgend.

Was ist ein Burn-up Chart?

Wer sich schon einmal mit agilen Vorgehensweisen, wie z.B. Scrum, beschäftigt hat, kennt sicher sogenannte Burn-down Charts. In einem Burn-down Chart trägt ein Team auf täglicher Basis ab, welche Aufgaben vom Gesamtumfang einer Iteration erledigt sind.

Wie man in Beispiel 1 sieht, bewegt sich ein ideales Burn-down (rote Linie) nahe der (grauen) Ideallinie. So erhält das Team während der Iteration ein Gefühl, ob es das was es sich vorgenommen hat, auch schaffen kann.

Das funktioniert gut, weil zu Beginn der Iteration der Scope festgelegt wurde und weil die Dauer einer Iteration – in Scrum Sprint genannt – ebenfalls feststeht. Üblicherweise dauert eine Iteration zwischen einer und vier Wochen, also ein gut überschaubarer Zeitraum. Was aber wenn wir im Zuge der Produktentwicklung weder den genauen Scope kennen, noch die Abarbeitungsgeschwindigkeit des oder der Teams?

Hier kommen Burn-up Charts ins Spiel: Ein Burn-up Chart ist im Prinzip ein umgedrehtes Burn-down Chart. Mit fortschreitender Zeit wird die erledigte Arbeit aufgetragen. Die entstehende Kurve verläuft also von unten nach Oben. Die Steigung der Kurve spiegelt die Abarbeitungsgeschwindigkeit wider. Soweit so gut, aber der eigentliche Trick entsteht nun dadurch, dass auf einer zweiten Kurve stets abgetragen wird, wie groß aktuell der Gesamtscope ist. Typischerweise wird der Gesamtscope am Anfang sehr klein sein, und mit der Zeit größer werden.

Das ist in Beispiel 2 dargestellt. Wie man dort sieht, läuft die rote Kurve der erledigten Arbeiten auf die blaue Kurve, die den Gesamtscope zu einem Zeitpunkt darstellt, zu.

Zum einen wird sehr gut visualisiert, wie sich die erledigte Arbeit im Vergleich zum Gesamtscope entwickelt. Zum anderen, wird so ein Forecasting möglich. Ein Release des Produktes ist fertig, sobald die rote Kurve die blaue erreicht hat.

Forecasting in der agilen Produktentwicklung

Wir verwenden Trendlinien, die wir möglichst frühzeitig einzeichnen und mit jeder Iteration anpassen, um Vorhersagen zu treffen, wann die rote Linie die blaue schneiden wird. Dabei treffen wir die Annahme, dass sich die Abarbeitungsgeschwindigkeit der Teams linear entwickelt. Typischerweise ist die Geschwindigkeit – Velocity – von neuen Teams anfangs etwas geringer und stabilisiert sich dann auf einem bestimmten Niveau. Im Mittel kann sie also als gleichbleibend angenommen.

Beispiel 3: Burn-up Chart mit Forecast-Trend

Beispiel 3: Für die blaue Kurve verwenden wir einen logarithmischen Trend. Das spiegelt die Annahme wider, dass sich der Scope anfangs sehr schnell entwickelt. Es ist in der Produktentwicklung normal, dass zu Beginn wenig über den genauen Scope bekannt ist, die Menge der Aufgaben dann stark zunimmt und sich dann stabilisiert. Mit fortschreitender Zeit wird meist sehr klar, was im Release Scope sein wird und was nicht. 

In unserem Beispiel kann man eine Lieferung des geplanten Release-Scope mit Sprint 6 erwarten. Handlungsspielraum ergibt sich dadurch, dass entweder Scope reduziert werden kann oder aber Maßnahmen ergriffen werden, die Velocity der Teams zu erhöhen. Letzteres ist aber bekanntermaßen meist der deutlich kleinere Hebel („The Mythical Man-Month“, Frederick P. Brooks) und kurzfristig ohnehin meist unmöglich.

Warum keine Storypoints?

Wer genau hingeschaut hat, entdeckt im Burn-down Chart oben „Story Punkte“ auf der vertikalen Achse während im Burn-down Chart die „Anzahl Vorgänge“ aufgetragen sind. Mit Story Punkten zu arbeiten ist im Scrum Umfeld nahezu allgegenwärtig. Story Punkte sind ein abstraktes Maß, welches User Stories verschiedener Größe ins Verhältnis setzt, was Teams wiederum helfen soll, ihre Sprints besser zu planen.

Wir verwenden in unseren Burn-up Charts keine Story Punkte, sondern arbeiten mit der Anzahl an Stories, denn:

• Story-Punkte wären genauer aber würden aber sogenanntes Gaming erlauben (vgl. Goodhart’s Gesetz: „Wenn ein Maß zum Ziel wird, ist es kein gutes Maß mehr“).
• Story-Punkte bräuchten ein stets vollständig geschätztes Backlog, um die blaue Kurve abbilden zu können.
• Die gröbere Genauigkeit über Anzahl Vorgänge reicht vollkommen aus für einen Forecast. Größere Genauigkeit bringt keine neue Information.
• Die Tatsache dass Stories unterschiedlich groß sind, spielt ebenfalls keine Rolle, da es nur um die Frage geht: „Ist noch Arbeit zu tun oder nicht?“. Dies bedeutet, dass sich die Größe der Stories über ein große Anzahl sowieso mittelt und damit nicht ins Gewicht fällt. 

Release Management

Durch die Visualisierung des bekannten Gesamtscope gegen den aktuellen Stand in der Abarbeitung der Aufgaben wird sehr gut sichtbar, an welchen Stellschrauben man in der Produktentwicklung drehen muss, um zu einem bestimmten Datum etwas liefern zu können.

Stück für Stück

Wir verwenden Milestones, also festgelegte Etappenziele auf unserer Roadmap, die einen bestimmten Funktionsumfang des Gesamtproduktes liefern sollen. Also frühe Produktversionen sozusagen.  Der Vorteil dabei ist, dass der Scope eines Milestones schneller gegen einen stabilen Zustand konvergiert als der Gesamtscope. Dadurch können wir sehr früh ein gutes Gefühl bekommen, wann wir konkrete Ziele erreicht haben werden.

Vorteile

Klare Stakeholderkommunikation

Auf einen Blick werden die wesentlichen Informationen und die (teils) harte Realität vermittelt. Auch willkürlich illusorisch angesetzte Deadlines werden schnell als unrealistisch entlarvt. Was möglich ist, wird sichtbar.

Gaming – Schummeln ist nicht

Ob gewollt oder ungewollt, Teams können kaum manipulativ auf ein solches Fortschrittstracking einwirken. Sogenanntes Gaming wird sehr erschwert. Dies liegt daran, dass zusätzlich erstellte Stories irgendwann später auch wieder geschlossen werden müssen. Oder umgekehrt: wenn Stories dafür genutzt würden, um einen großen Fortschritt vorzugeben, würden sie vorher im Scope schon gezählt worden sein. Der Abstand zwischen den beiden Linien verringert sich durch dieses Gamen also nicht. Auf der anderen Seite könnte man die Stories kleiner schneiden. Das wird aber dadurch ausgeglichen, dass in einer Iteration entsprechend mehr Stories abgearbeitet werden können.

Continuous Improvement eingebaut

Zwar ist die Vorhersage anfangs sehr ungenau aber schon nach wenigen Wochen vermittelt sie ein gutes Verständnis davon, was möglich sein wird und was nicht. Man lernt sein Team bzw. seine Teams und das wirkende Gesamtsystem recht schnell gut kennen und kann Rückschlüsse auf mögliche strukturelle Probleme ziehen. Mit fortschreitender Zeit wird die Vorhersage immer verlässlicher und genauer.

Fokus auf das Wesentliche

Durch die Visualisierung wird der Blick auf die wesentlichen Wirkfaktoren gelenkt, nämlich Umsetzungsgeschwindigkeit und Scope. Die wichtigsten handlungsleitenden Informationen sind so sehr klar greifbar.

Fazit

Durch die Arbeit mit Trendlinien und Annahmen, die sich als Datenpunkte einzeichnen lassen, können gut verschiedene Szenarien der Produktentwicklung durchgespielt und bewertet werden. Jedes Team wird eine andere konkrete Lösung entwickeln müssen. In unserem Projekt hat es sehr geholfen, einen angenommenen Scope bei 600 Stories anzunehmen, um den asymptotisch ablaufenden Scope zu visualisieren (siehe Beispiel 4). Wir sind dadurch in der Lage, einen Lieferzeitpunkt, der erst in etwa einem Jahr sein wird, im Auge zu behalten.

Als Product Owner ist man daher besser in der Lage dazu, mit seinen Stakeholdern „Verhandlungen“ zu führen, weil man die Auswirkung von Featurecreep auf das Lieferdatum sehr schön veranschaulichen kann. Manchmal gehe ich als P.O. in ein solches Gespräch mit der Ansage rein, dass nur 20 Stories „erlaubt“ sind. Das klärt die Erwartungshaltung sehr deutlich, ohne dass aufwendig geschätzt werden muss.

Final versetzt uns dieses Vorgehen dazu in die Lage, agil zu arbeiten und trotzdem einen Gesamtfortschritt in Prozent zu ermitteln. Durch die asymptotische Scopekurve weiß man, wie viele Vorgänge insgesamt zu bearbeiten sind – und das ohne das Backlog gefüllt haben zu müssen. Daraus lässt sich sehr elegant der Gesamtfortschritt des Inkrements ableiten.

Als wir diese Art des Reportings unseren Sponsoren und dem kaufmännischen Geschäftsführer gezeigt haben, waren diese sofort von der Systematik überzeugt. Eine weitere Bestätigung dafür, dass das Vorgehen sehr nützlich ist.

This article has also appeared in English:

• https://splsg.com/2021/01/15/burn-up-forecasting-in-agile-product-development/
• Burn-up! Forecasting in agile Product Development

Über die Autoren

Dr. Timo Volkmer ist Betreiber dieser Webseite und begann seine Laufbahn als Informatiker und IT-Berater. Er ist Systemischer Coach, sowie Experte für Organisationsentwickung und agile Produktentwicklung. Aktuell bei DER Touristik Online tätig hat er freiberuflich zuvor bereits zahlreiche, namhafte Unternehmen im Rahmen von agilen Transformationen beraten. Besonders am Herzen liegt Timo die gemeinsame Arbeit an Produkten, die von Kunden geliebt werden.

Jörg Malang arbeitet seit 2008 als Product Manager, darunter einige Positionen als Chief Product Officer in Unternehmen unterschiedlicher Größenordnungen. Seit 2018 berät er freiberuflich unter der Marke „Senior Product Leadership Group (SPLSG)“ Unternehmen dabei, ihre Produktentwicklung effektiv und effizient aufzustellen. Jörgs Leidenschaft ist neben der Entwicklung von Produktstrategien die kundenzentrierte agile Produktentwicklung. Aktuell ist Jörg als P.O. freiberuflich für die DER Touristik Online tätig