Seltsamerweise scheinen viele Agile Coaches zwar viel Energie auf die Scrum-Vorhersage eines Teams für den jeweils aktuellen zu legen (ich führe das in einem Folgeartikel detaillierter aus). Jedoch, die Kapazitätsplanung über die folgenden Monate verfolgen sie bei weitem nicht mit derselben Akribie.
Oft kommt sogar von den Coaches selber ein Scheinargument: „Wir sind agil, daher planen und priorisieren wir im Product Backlog nicht über den Folgesprint hinaus! Das wäre doch Wasserfall!“ Und gleichzeitig präsentieren der Scrum Master und der PO desselben Teams regelmäßig den Stakeholdern eine von diesen geforderte Roadmap für die nächsten 6-24 Monate… Erkennen Sie, lieber Leser, hier den Widerspruch? Ich zitiere dazu den Scrum Guide:
Dort steht nirgendwo: „Schreibt bloß nichts ins Product Backlog hinein, was erst in Zukunft wichtig wird!“. Und auch nicht „Plant keinesfalls im Product Backlog über mehr als einen Sprint hinaus!“. Das vernünftige agile Prinzip, die Menge nicht getaner Arbeit zu minimieren, sei dabei natürlich beachtet. Es gestattet jedoch ebenfalls die längerfristige Planung, sofern sie einen konkreten Nutzen hat und für unsichere Dinge im Verhältnis zur jeweiligen Unsicherheit nicht zu sehr ins Detail geht.
Im agilen Umfeld können wir Pläne jederzeit ändern. Aber Planung und Agilität widersprechen sind nicht. Planen ist sogar explizit Teil der agilen Werte, wie wir im agilen Manifest nachlesen können:
Daher, es ist ein falsches Verständnis von Agilität, wollte man alles, was mit Planung zu tun hat, im Product Backlog oder anderswo, als schlecht und möglichst zu vermeiden verdammen. Eher habe ich dies als Schutzbehauptung kennen gelernt, welche die Transparenz über die eigene potentielle nicht-Leistung verringert. Ferner heißt „Reagieren auf Veränderung“ nicht, im Nebel zu stochern und spontan auf alles zu reagieren, was da so kommt. Sondern vielmehr: Pläne ständig mit den jeweils aktuellen Bedingungen den Projektumfeldes abzugleichen. Dafür müssen diese Pläne aber erstmal da sein!
Die Glaskugel – was kommt nach dem nächsten Sprint?
Um eine tragfähige Umsetzungsplanung zu erstellen, ist es wichtig, auch einen Blick auf den möglichen Umfang und Inhalt zukünftiger Sprints zu werfen. Insbesondere dann, wenn wichtige Geschäfts- und Produktziele von deren Ausgang abhängen. Gemäß der häufigen Grundfrage vieler Stakeholder: „Wann wird das denn fertig?„
Dies beugt nicht nur Konflikten mit und Unsicherheiten bei den Stakeholdern vor. Sondern schafft nicht zuletzt die Möglichkeit einer realistischen, transparenten Produktziel-Planung. Ferner nimmt gerade das viel Druck aus dem Team. Denn eine gute Planung fängt potentiell unrealistische Erwartungen der Stakeholder rechtzeitig ab. Und sie gibt allen Parteien klare Risikohinweise und ermöglicht eine zeitnahe Gegensteuerung.
Der Umfang künftiger Scrum-Sprints ist in gewisser Weise sogar etwas einfacher einzuschätzen als der des direkt kommenden Sprints. Denn bei einzelnen Sprints kann es zu über einen kurzen Zeitraum schwer einschätzbaren Veränderungen kommen. Beispielsweise durch Urlaub, Krankheit, Infrastrukturausfälle oder dem Wechsel von Teammitgliedern. Auch weitere technische oder organisatorische Rahmenbedingungen des Projektes können sich unerwartet ändern.
Meine Hypothese: Über den Betrachtungszeitrum mehrerer Sprints gleichen sich diese wechselnden Effekte im Wesentlichen aus. Voraussetzung dabei ist zum Einen, über eine brauchbare Maßeinheit zu verfügen, um die typische Geschwindigkeit eines Teams zu messen und in die Zukunft vorherzusagen. Und zum Anderen, ein brauchbarer Planungszeitraum in die Zukunft, der weder zu groß, noch zu klein gewählt ist. Die These wird durch die Philosophie von Scrum unterstützt, möglichst viele Parameter über den Zeitverlauf möglichst gleich zu halten (Sprintlänge, Teamzusammensetzung, Schnitt der Backlog-Items etc). Ferner verifizieren wir die grundsätzliche Hypothese gerade in Langzeitstudien mit mehreren Teams, POs und Produkten.
Bei vielen Experten hat sich mittlerweile die Monte-Carlo-Simulation etabliert, um Scrum-Vorhersagen auf das Product-Backlog zu machen. Im Folgenden werde ich zeigen, wie diese von jedermann leicht angewandt werden oder bei Bedarf sogar durch eine noch einfachere „Hands-On-Methodik“ ersetzt werden kann.
Monte-Carlo macht Scrum-Vorhersage transparent
Über die mathematisch fundierte Monte-Carlo-Simulation (die Details dazu seien an anderer Stelle erläutert) lässt sich eine Wahrscheinlichkeit dafür herausfinden, wie viele Backlog-Items (oder nach Geschmack: wie viele „Story-Points“) sich in kommenden Sprints voraussichtlich vom Scrum-Team umsetzen lassen. Dabei wird auf die empirischen Daten vergangener Sprints zurück gegriffen. Für die Berechnung gibt es seit 2019 ein kostenlos verfügbares Web-Tool, das beispielsweise folgende Aufgaben liefert:
In meinen bisherigen Experimenten hat sich herausgestellt, dass die „realistische“ Annahme gemäß MCS eine gute Wahl ist, wenn man wie wir mehrere Sprints in die Zukunft rechnet. Wir arbeiten dabei aktuell mit dem aktuellen Sprint, plus sechs weiteren in die Zukunft (=7 Sprints insgesamt). Im Mittel wird damit tatsächlich eine realistische Aussage über die mittelfristige Teamkapazität erreicht.
Bei diesen Experimenten machte ich ferner eine bemerkenswerte Beobachtung: der „einfache“ Median aus den empirischen Daten vorangehender Sprints war immer identisch mit dem „realistischen“ Ergebnis aus der Monte-Carlo-Simulation. Zumindest für die Datengrundlage „Anzahl erledigter Stories je Sprint“. Daher, wem Monte-Carlo zu kompliziert ist (vielleicht ist auch der online-Service mal nicht verfügbar und man hat kein alternatives Tool zur Hand…), der kann auch mit dem Median „hands-on“ gut fahren.
Hinweis: Als alternative Grundlage für die Berechnung sowohl der Monte-Carlo-Vorhersage als auch der Scrum-Vorhersage auf Basis des Median könnte man auch andere Daten benutzen. Beispielsweise die „berechnete Takt-Zeit“ (siehe hier und hier), oder die reale Durchlaufzeit von Aufgaben in Sprints oder Tagen. Beides kann anschließend auf Sprints hochgerechnet werden. Wir experimentieren erstmal nicht mit diesen Details, sondern lagern deren Betrachtung und mögliche Wirkung auf eine Scrum-Vorhersage in einen zukünftigen Artikel aus. Die Erfassung und Berechnung wäre jedenfalls komplizierter und nicht unmittelbar für jeden nachzuvollziehen.
Realistisch, optimistisch oder lieber konservativ?
Die „optimistische“ Sicht hingegen wurde in meinen Experimenten bisher weder mittel- noch kurzfristig erreicht. Auch vor der konservativen Schätzung würde ich warnen: diese setzt die selbst gesteckten Ziele zu niedrig an, und kann daher die Motivation des Teams, des POs und der Stakeholder zu stark senken. Besser wäre es, wenn der PO bewusst Kapazitäten in seiner Planung frei lässt (siehe dazu meinen nächsten Blog-Artikel).
Beide „Abweichungen“ der realistischen Annahme haben jedoch ihre Berechtigung: sie können als maximale bzw minimale Abschätzung dafür dienen, wie sich spontane Veränderungen in den Rahmenbedingungen des Teams mittelfristig auswirken können. Beispielsweise wenn die Entwicklungsinfrastruktur für längere Zeit gestört ist. Oder wenn die Team-Zusammensetzung sich stark geändert hat. In beiden Fällen könnte man einige Sprints lang die konservative Schätzung annehmen. Und umgekehrt, wenn man beispielsweise durch neu eingeführte Technologien (AI, Automatisierung) deutlich mehr Performance erwartet, kann man den Erwartungswert für die Scrum-Vorhersage in Richtung „optimistisch“ erhöhen.
Voraussetzung: ein transparentes Sprint-Backlog
Damit eine solchermaßen berechnete Zahl auch wirklich eine brauchbare Scrum-Vorhersage für eine „Abarbeitungsgeschwindigkeit“ des Teams geben kann, gibt es wichtige Voraussetzungen: Nicht nur muss das Product-Backlog transparent sein. Sondern auch das Sprint-Backlog und die Planung dafür. Denn je mehr Tätigkeiten vom Scrum-Team durchgeführt werden, ohne dass diese direkt aus Product-Backlogs-Items, die in den Sprint eingeplant wurden, abgeleitet wurden, desto unzuverlässiger sind unsere Eingabedaten. Und damit auch die darauf basierende Scrum-Vorhersage.
Ich warne an dieser Stelle daher ausdrücklich vor Sprint-Planungs-Lanes wie „Sonstige Tasks“, „Fastlane“, „Stakeholder Tasks“ etc. Diese erledigt das Team in der Regel ohne explizite Berücksichtigung in der Sprintplanung „gemäß eigener Prio“. Also potentiell an der Priorisierung des PO vorbei. Ferner kann so etwas auch dazu führen, dass die DoD nicht eingehalten wird für solche Tätigkeiten. Geschweige denn eine DoR, die das Team damit ohnehin ignoriert. Und natürlich verzerrt es unsere empirischen Daten für das, was im Sprint tatsächlich geschafft wurde. Aus allen diesen Gründen sollte das Team Möglichkeiten finden, auf solche „Schattentätigkeiten“ zu verzichten. Besser ist es, sie als normale Product-Backlog-Items einplanen.
Auch das Auftreten von „Bugs“ kann die historische Daten verzerren – allerdings auf eher „natürlich“ Weise. Denn Bugs werden in der Regel indirekt die technische Schuld widerspiegeln, die sich das Team über die Zeit auflädt. Es kann nützlich sein, zu beobachten wie und ob die Zahl der Bugs über mehrere Sprints hinweg entwickelt. Und wie und ob sie die Geschwindigkeit des Teams über die Zeit tatsächlich beeinflusst. Dass dabei auch andere Parameter eine Rolle spielen, macht Schlussfolgerungen aber schwierig. Bei unseren ersten Versuchen mit der gewählten Vorhersage-Methodik ignorieren wir zunächst die Bugs für die Berechnungen. Wir loggen sie aber für spätere Auswertungen mit. Alle anderen Product-Backlog-Items außer Bugs, die in den Sprint eingeplant werden, fließen in die Berechnung ein.
Sprint-Daten sammeln für eine empirische Scrum-Vorhersage
Dies kann dann wie folgt aussehen:
Dieses Team verwendet drei Item-Typen, um „Wert“ innerhalb eines Sprints zu schaffen: „Story“, „Verbesserung“ und „Konzept“. Alle drei Typen werden im Planning bewusst und vom ganzen Team in den Sprint eingeplant. Daher zählen auch alle drei als „Eingangswerte“ für unsere Berechnungen der Scrum-Vorhersage. Wir zählen dabei nur die tatsächlich gemäß DoD im jeweiligen Sprint abgeschlossenen Items. Angefangene oder „fast fertige“ Items werden nicht gezählt.
Ferner sieht man, dass auch mit unterschiedlichen Sprint-Längen gearbeitet wurde: das Team arbeitet normalerweise in 2-Wochen-Sprints. Es hat hier aber einmalig einen 4-Wochen-Sprint durchgeführt (markiert mit „4W“). Wir haben es uns bei der Erfassung der Daten daraus einfach gemacht: 8 „Items“ wurden in 4 Wochen geschafft und nun wird geteilt durch zwei: schon sind wir wieder in der 2-Wochen-Rechnung. Würde dabei keine ganze Zahl entstehen, also beispielsweise 7/2=3,5, so würden wir „kaufmännisch“ runden. Bei einer Teilung durch „2“ also immer das Ergebnis aufrunden auf die nächste ganze Zahl, im Beispiel: 4
Was die Auswertung für eine Scrum-Vorhersage angeht, stehen wie oben beschrieben die MCS und der Median zu Verfügung. Ferner lassen sich unmittelbar zwei Dinge ableiten: Die Wahrscheinlichkeit, mehr als 7 Aufgaben in einem der kommenden Sprints zu schaffen, ist vernachlässigbar klein. Ebenso ist es mehr als unwahrscheinlich, dass dieses Team plötzlich weniger als 2 Aufgaben in einem Sprint fertigstellt.
Fertig! Das ist die ganze „Magie“ bei der Erhebung der empirischen Daten, die wir für die Scrum-Vorhersage für das Product Backlog benötigen. Wie oben schon geschrieben, kann man statt der reinen Anzahl geschaffter „Items“ in den historischen Daten alternativ auch eine Summe aus „Story Points“, „T-Shirt-Größen“ oder ähnliches wählen. Weshalb diese Alternativen für eine Planung über die jeweils folgenden 1-2 Sprints hinaus nicht unbedingt die beste Entscheidung ist, erläutere ich im nächsten Blogartikel – der Leser darf gerne gespannt bleiben!
Zusammenfassung
Es gibt gute und einfache Möglichkeiten, eine Vorhersage dafür zu treffen, was ein Scrum-Team in den nächsten Sprints voraussichtlich schaffen wird. Ausgangsdaten für die empirische Betrachtung sind die Product-Backlog-Items, die ein Team in den vergangenen Sprints nachweislich geschafft hat. Sowohl die Monte-Carlo-Simulation als auch der Median können brauchbare Aussagen über solchen einen Blick in die Zukunft treffen. Dabei wird die Annahme getroffen, dass die Rahmenbedingungen des Teams im Betrachtungszeitraum in etwa gleich bleiben. Und ferner, dass sowohl das Product-Backlog als auch das Sprint-Backlog die gemeinsam mit dem PO geplante Arbeit und Aufgaben des Teams transparent abbilden. In einem der nächsten Artikel wird die nutzenbringende Anwendung dieser Scrum-Vorhersagen näher beleuchtet.
WERBUNG in eigener Sache: Möchten Sie eine Unterstützung durch einen agilen Coach? Dies ist bereits ab ca einem Tag pro Woche möglich, durch Rolf Wendolsky & Partner. Wir bieten über unsere Digitalagentur JonDos ferner das Staffing und den Aufbau ganzer Entwicklungsteams für ihre Projekte an. Vorzugsweise organisiert als Scrum-Teams, aber nicht nur: wir haben auch viel Erfahrung in der agilen Organisation „kleiner“ „Teilzeit“-Projekte mit nur 2-3 Entwicklern.