In den SAFe®-Schulungen gibt es eine Folie zu Story Points und Kapazität (engl. „Capacity“), die ziemlich knifflig ist. Diese Folie wird oft falsch interpretiert. Das führt zu zwei großen Fehlern: (1) Die Formel zur Berechnung der Capacity “8 Punkte für jeden Vollzeitentwickler” wird für jede Iteration/jeden Sprint verwendet. (2) Die Relation “Weisen Sie einer Story, die etwa einen halben Tag für die Entwicklung und einen halben Tag für das Testen und Validieren benötigt, einen Punkt zu” wird wiederholt verwendet – und nicht, um die Referenzstory für die Größe “1” zu finden. Noch schlimmer ist, dass viele Leute glauben, dass dies das ist, was SAFe vorschlägt. Lesen Sie diesen Artikel, um zu erfahren, was diese Folie ist, wie sie missverstanden wird und wie man sie richtig versteht.
TLDR: Eine zentrale Folie in den SAFe®-Schulungen führt oft zu großen Missverständnissen über Schätzungen und in der Folge zu schlechten Praktiken. Das muss nicht der Fall sein.
- Die Folie “Berechnung Ihrer Kapazität” in der PI-Planungssimulation sollte mit Vorsicht genossen werden.
- Auf der Folie ist von Story Points und Kapazität die Rede. Das sind zwei verschiedene Dinge.
- Auf der Folie steht: „Berechnung Ihrer Kapazität“. Aber es geht ausschließlich um die Berechnung einer initialen Kapazität.
- Nach der ersten Iteration wird die Kapazität (Capacity) anhand der gemessenen Geschwindigkeit (Velocity) prognostiziert.
- Man sollte die Annahmen, die hinter den “8 Punkten für jedes Vollzeitmitglied” stehen, verstehen und bei Bedarf Anpassungen vornehmen.
- Auf der Folie geht es darum, eine Referenz-Story zu finden, die “1” Story Point repräsentiert.
- Story Points haben eine Beziehung zum Aufwand, die sich mit der Zeit ändert.
- Alle Techniken auf der Folie sind optional.
- Der Iteration Planning Artikel auf der SAFe®-Website hilft beim Verständnis.
- Ein allgemeiner Ratschlag für die Umsetzung von SAFe®: Bleib den eingebetteten Frameworks treu und nutze die Fülle des agilen Wissens als Leitplanken.
Die Folie “Berechnung Ihrer Kapazität” in der PI-Planungssimulation sollte mit Vorsicht genossen werden.
Ein Schlüsselelement der SAFe-Trainings ist die Simulation der PI-Planung. Sie ist unter anderem Bestandteil der Schulungen Leading SAFe, Implementing SAFe und SAFe for Teams. In der Simulation der PI-Planung gibt es eine Folie, welche die “Berechnung Ihrer Kapazität” erklärt. Dies ist eine wichtige, aber auch heikle Folie, die dazu führt, dass viele Leute die Schätzung in SAFe missverstehen. Diese Folie sollte mit Vorsicht behandelt werden.
In diesem Artikel erkläre ich die Fallstricke der Folie, häufige Missverständnisse und wie man sie vermeiden kann.
Die vier Aufzählungspunkte auf der Folie unter der Überschrift “Berechnung der Iterationskapazität” lauten wie folgt (Text © Scaled Agile, Inc.):
- “Geben Sie dem Team für jedes Vollzeitmitglied des agilen Teams, das zur Solution-Entwicklung beiträgt, acht Punkte (für Teilzeitmitglieder entsprechend anpassen).
- Ziehen Sie für jeden Urlaubstag eines Teammitglieds und jeden Feiertag einen Punkt ab.
- Weisen Sie einer kleinen Story einen Punkt zu, die ca. einen halben Tag zur Entwicklung und einen halben Tag zum Testen und Validieren benötigt.
- Schätzen Sie die anderen Storys im Verhältnis zu dieser ab.”
Diese vier Punkte finden sich auch auf der SAFe-Website. Sie stehen im Story-Artikel unter dem Abschnitt “Starting Baseline for Estimation”. Die Aussagen in diesem Artikel gelten also nicht nur für das, was in SAFe Schulungen vermittelt wird. Sie gelten allgemein für SAFe.
Auf der Folie ist von Story Points und Kapazität die Rede. Das sind zwei verschiedene Dinge.
Schauen wir uns zunächst die beiden Begrifflichkeiten auf der Folie an. Alle vier Aufzählungspunkte der Folie stehen unter der Überschrift “Berechnung der Iterationskapazität”.
- In den ersten beiden Punkten geht es um die Kapazität, engl. Capacity. Dies ist die prognostizierte Geschwindigkeit, engl. „Velocity“. Die Einheit der Velocity oder Capacity ist „Story Points/Iteration“ oder allgemeiner gesagt: Elemente pro Zeit (siehe die Definition von Velocity und Flow Velocity in SAFe).
- In den letzten beiden Punkten geht es um Story Points. Die Einheit ist „Story Point (SP)“.
Wir sprechen also von zwei verschiedenen Einheiten und damit von zwei verschiedenen Dingen.
Auf der Folie steht: „Berechnung Ihrer Kapazität“. Aber es geht ausschließlich um die Berechnung der initialen Kapazität.
Die Überschrift der Folie lautet: „Berechnung Ihrer Kapazität“ und „Berechnung der Iterationskapazität“. Ohne Kontext könnte man denken, dass die Folie erklärt, wie man die Kapazität im Allgemeinen berechnet. Die Berechnung mit “8 Punkten für jeden Vollzeitentwickler” ist jedoch eine Ausgangsbasis für die Kapazität, wenn es keine historischen Daten gibt.
Daher die Klarstellung: Die Schritte auf dieser Folie werden nur einmal durchgeführt, und zwar vor der ersten Iteration, „wenn das Team neu und die Geschwindigkeit unbekannt ist“ (Zitat aus dem Artikel zum Iteration Planning).
Nach der ersten Iteration wird die Kapazität (Capacity) anhand der gemessenen Geschwindigkeit (Velocity) prognostiziert.
Die Berechnung der Kapazität nach der ersten Iteration basiert auf der gemessenen Geschwindigkeit. „Das Team prognostiziert seine Kapazität (Capacity) für eine kommende Iteration, indem es seine historische Geschwindigkeit (Velocity) als Ausgangspunkt verwendet“ (Zitat aus dem Artikel Iteration Planning). Die Teams müssen dies in der Praxis verstehen, spätestens in der SAFe for Teams-Schulung. Nach der ersten Iteration beginnen die Teams mit der Vorhersage der Kapazität auf der Grundlage der Velocity.
Es wäre ein großer Fehler, die Kapazität auf der Grundlage von “8 Punkten für jeden Vollzeitentwickler” in jeder Iteration zu berechnen.
Hier ist eine Möglichkeit, die Kapazität zu prognostizieren:
- Am einfachsten ist es, den gleitenden Durchschnitt der Geschwindigkeit der letzten n Iterationen/Sprints zu verwenden.
- Wenn die Arbeitstage in den Iterationen/Sprints sehr unterschiedlich sind, kann man den gleitenden Durchschnitt mithilfe des Dreisatzes anpassen: Man nimmt die durchschnittliche Geschwindigkeit, teilt sie durch die durchschnittlichen Vollzeitarbeitstage des Teams in den letzten n Iterationen/Sprints und multipliziert sie mit den verfügbaren Vollzeitarbeitstagen in den nächsten Iterationen/Sprints.
Kapazität und Geschwindigkeit sind eng miteinander verbunden: Geschwindigkeit (Velocity) ist die gemessene Geschwindigkeit in der Vergangenheit. Die Kapazität ist die prognostizierte Geschwindigkeit unter Berücksichtigung der Verfügbarkeit der Teammitglieder.
Der Story-Artikel in SAFe definiert Geschwindigkeit bzw. Velocity: “Die Velocity des Teams für eine Iteration ist gleich der Summe der Story Points für alle fertigen Storys, die der Definition von “done” (DoD) entsprechen”. Die durchschnittliche Velocity eines Teams in der Vergangenheit ist der beste Indikator dafür, wie viel das Team in zukünftigen Iterationen erreichen kann. Die Nichtverfügbarkeit von Teammitgliedern wird sich höchstwahrscheinlich negativ auswirken. Die anteilige Anpassung der Velocity ist eine Vereinfachung. Alles, was mit relativer Schätzung zu tun hat, ist eine Vereinfachung, denn wir wollen eine „gut genug zum Loslegen“-Einstellung und vermeiden es, Zeit mit perfekten Messwerten zu verschwenden.
Man sollte die Annahmen, die hinter den “8 Punkten für jedes Vollzeitmitglied” stehen, verstehen und bei Bedarf Anpassungen vornehmen.
Die Berechnung schlägt vor: „Geben Sie dem Team für jedes Vollzeitmitglied des agilen Teams, das zur Solution-Entwicklung beiträgt, acht Punkte“. Dies beruht auf mehreren Annahmen:
- Die Dauer einer Iteration/eines Sprints beträgt 2 Wochen (d.h. wir haben 10 Arbeitstage);
- 10 % unserer Zeit wird für Iterations-/Sprint-Ereignisse verwendet (wie im Scrum-Guide vorgeschlagen);
- 10 % der Zeit wird für das Product Backlog Refinement verwendet (wie in früheren Versionen des Scrum Guide vorgeschlagen);
- Unsere Referenzstory, die “1” Story Point darstellt, benötigt ca. einen halben Tag zur Entwicklung und einen halben Tag zum Testen und Validieren.
Wenn die tatsächliche Iterations-/Sprintlänge anders ist (z. B. eine Woche), müssen wir die Berechnung entsprechend anpassen. Wenn die Referenzstory, die “1” Story Point darstellt, von “einen halben Tag für die Entwicklung und einen halben Tag für Test und Validierung” abweicht, müssen wir die Berechnung ebenfalls anpassen.
Es ist nicht sinnvoll, sich zu viele Gedanken über die Berechnung der initialen Kapazität zu machen. Wir machen das nur einmal im Leben eines ART und die initiale Kapazität ist immer eine Schätzung. Wenn die Berechnung der initialen Kapazität länger als fünf Minuten dauert, schlage ich vor, die erste Iteration einfach Story für Story zu „laden“, bis das Team das Gefühl hat, dass es genug gezogen hat. Wir zählen dann die Story Points der gezogenen Elemente und verwenden dies als Schätzwert für die anfängliche Kapazität.
Auf der Folie geht es darum, eine Referenz-Story zu finden, die “1” Story Point repräsentiert.
Bei den unteren beiden Punkten auf der Folie geht es um die Schätzung mit Story Points (SP).
Der obere Punkt sagt „Weisen Sie einer kleinen Story einen Punkt zu, die ca. einen halben Tag zur Entwicklung und einen halben Tag zum Testen und Validieren benötigt.“. Damit werden zwei Dinge adressiert: die Festlegung einer Referenzstory für „1“ Story Point je Team und die Abstimmung der Größe „1“ zwischen mehreren Teams (weil alle den gleichen Algorithmus zum Finden der „1“-er Story nutzen).
Es kann nicht genug betont werden, dass die Referenz die gefundene Story ist, nicht ein „idealer“ Personentag. Der Text im Artikel zum Iteration Planning macht das deutlich: “Jedes Team findet eine kleine Story […]. Nennen Sie diese ‘Eins’.”
Ebenso wie die Berechnung der initialen Kapazität muss die Referenzstory für “1” SP nur einmal im Leben eines ART gefunden werden: vor dem ersten PI. Sobald wir eine Story gefunden haben, die “1” SP repräsentiert, verwenden wir diese Story und alle anderen Stories, die bereits geschätzt wurden, als Referenz. (Siehe meinen Artikel über „Schätzen in SAFe: Mythen und gute Praktiken“.)
Beachte, dass jedes Team seine eigene Referenzstory der Größe “1” findet. Man kann die Story Points zwischen den Teams angleichen, muss es aber nicht.
Story Points haben eine Beziehung zum Aufwand, die sich mit der Zeit ändert.
Obwohl wir den Algorithmus „Weisen Sie einer kleinen Story einen Punkt zu, die ca. einen halben Tag zur Entwicklung und einen halben Tag zum Testen und Validieren benötigt“ verwenden, um eine Referenzstory der Größe “1” zu finden, gibt es keine feste Beziehung zwischen Story Points und Aufwand.
Mit der Zeit, wenn sich etwas im Team ändert, ändert sich das Verhältnis „1 Story Point = 1 Tag Aufwand“. Das bedeutet: Außer in der ersten Iteration entspricht ein Story Point nicht einem Tag Aufwand. Wir brauchen die aktuelle Velocity, um die aktuelle Dauer bzw. den aktuellen Aufwand für eine Story vorherzusagen:
Dauert = Größe * Velocityt oder
Aufwandt = Größe * Velocityt * TeamgrößeEs wäre ein großer Fehler, den Algorithmus „Weisen Sie einer kleinen Story einen Punkt zu, die ca. einen halben Tag zur Entwicklung und einen halben Tag zum Testen und Validieren benötigt“ für etwas anderes zu verwenden als für das Finden der Referenzstory vor der ersten Iteration.
Die Folie kann leicht zu der Annahme verleiten, dass es eine feste Beziehung zwischen „Größe in Story Points“ und „Aufwand“ gibt. Es ist jedoch eine gute Praxis, die Größe von Dauer bzw. Aufwand zu entkoppeln. Die Story-Point-Schätzung tut dies und nutzt Velocity, um Dauer bzw. Aufwand auf der Grundlage aktueller und sich entwickelnder Daten vorherzusagen. Das gesamte Konzept und der Nutzen der Größenschätzung mit Story Points wird durch ein festes Verhältnis zwischen Größe und Aufwand zunichte gemacht. Deshalb können wir nicht vorsichtig genug sein, wenn wir den Algorithmus “1 Story Point = 1 Tag Aufwand” verwenden.
Warum wir Größe und Aufwand entkoppeln:
Zu jedem Zeitpunkt steht die Größe im Verhältnis zu Dauer und Aufwand. Der Faktor in dieser Beziehung ist die aktuelle Velocity (oder der Throughput). Die Velocity eines Teams ändert sich, wenn sich im Team etwas ändert (z. B. bessere Fähigkeiten, Einführung von Techniken wie Testautomatisierung). Wenn sich die Geschwindigkeit ändert, ändern sich auch die Dauer und der Aufwand. Während die Größe in der Regel stabil bleibt, ändert sich die Velocity tendenziell. Durch die Entkopplung von Größe und Aufwand können wir den Aufwand auf der Grundlage aktueller Daten vorhersagen, ohne dass wir die Elemente neu schätzen müssen. Die Entkopplung von Größe und Aufwand bedeutet, dass es keine feste Beziehung zwischen Größe und Aufwand gibt, sondern dass wir die aktuelle Geschwindigkeit nutzen, um eine aktuelle Vorhersage für den Aufwand zu treffen.
Auch SAFe tappt in die Falle eines festen Verhältnisses zwischen Größe und Aufwand. In der SAFe for Teams-Schulung heißt es auf Folie 4-16 mit dem Titel „Fibonacci is used for estimation“: „Typically, a 1-point story would take 1 day to develop and test“. Als allgemeine Aussage ist das falsch.
Alle Techniken auf der Folie sind optional.
Die initiale Kapazitätsberechnung auf der Folie ist eine mögliche Methode zur initialen Vorhersage der Teamkapazität (“one method“). Das bedeutet, dass die Berechnung nur ein Vorschlag ist und man andere Methoden wählen kann.
Das Angleichen von Story Points zwischen Teams („aligned“ oder „approximately normalized“) bedeutet, dass ihre Referenzstories der Größe “1” ungefähr gleich groß sind. Das Angleichen ist in SAFe eine Option, aber keine Voraussetzung (“can be”).
Auch der Algorithmus „Finde eine kleine Story, deren Entwicklung einen Tag dauern würde […]. Nenne sie ‚Eins‘.“ ist ein möglicher Ansatz („one approach“) und nicht verpflichtend.
Alle Zitate stammen aus dem Artikel über das Iteration Planning.
Der Iteration Planning Artikel auf der SAFe®-Website hilft beim Verständnis.
Eine ausführlichere Version der vier Aufzählungspunkte auf der Folie findet sich auf der SAFe-Website. Sie stehen im Story-Artikel unter dem Abschnitt “Starting Baseline for Estimation” und im Iteration Planning Artikelunter den Überschriften „Estimating Stories and Forecasting Team Capacity“ und „Creating a Shared Basis for Story Point Estimation“.
Der Text im Story-Artikel sagt eindeutig, dass es sich bei den vier Punkten um eine “Starting Baseline for Estimation”handelt, aber er vermischt immer noch Kapazität und Story Points. Ein genauerer Text findet sich im Iteration Planning Artikel. Deshalb verweise ich die Leute auf diesen Artikel.
Mit einem Augenzwinkern zu den Kritikern stimme ich zu, dass der Inhalt von SAFe zu Schätzung und Prognose verbessert werden könnte. Mehr Klarheit in den Folien und eine Synchronisierung der Abschnitte im Story-Artikel und im Iteration Planning Artikel wären gut. Hoffentlich werden wir das in Version 6.1 sehen.
Ein allgemeiner Ratschlag für die Umsetzung von SAFe®: Bleib den eingebetteten Frameworks treu und nutze die Fülle des agilen Wissens als Leitplanken.
Die Diskussion bezüglich der Folie sollte zeigen, dass eine echte, tiefgreifende Erfahrung nicht nur mit SAFe, sondern auch mit den eingebetteten Frameworks der Schlüssel zu einer guten Umsetzung von SAFe ist. Wenn Dinge im Widerspruch zu langjähriger agiler Erfahrung stehen, wird SAFe wahrscheinlich falsch umgesetzt. Gute SAFe-Implementierungen sind den Frameworks, die SAFe einbettet, treu. Die Fülle an Wissen rund um die eingebetteten Frameworks ist eine gute Leitplanke für die Anwendung von SAFe. Wenn man gegen diese Leitplanken stößt, sollte man zweimal nachdenken. In dem Fall gilt für mich: SAFe nochmal lesen. Das ursprünglich eingebettete Framework noch einmal lesen. Darüber nachdenken, was sich innerhalb der Leitplanken befindet. Und dann in diese Richtung gehen.
Danke, liebe Rezensenten.
Schätzung ist ein schwieriges Thema. Ich möchte mich bei meinen Reviewern bedanken, die diesen Artikel erheblich verbessert haben: Simon Porro, David Croome, Michele Lanzinger und das SAFe Framework Team.
Willst du mehr erfahren? Dann besuche einen unserer Trainingskurse.
Wir behandeln die oben genannten Themen in unserem Leading SAFe Training oder in unserem Implementing SAFe Training. Erlebe ein Training mit vielen praktischen Aktivitäten, guten Diskussionen und erfahrenen Experten. Triff die Leute mit den meisten praktischen Erfahrungen in der Skalierung von Agilität und der Einführung von Business Agility.
Lies meinen anderen Artikel zu SAFe Schätzen
Alle Zitate von der SAFe-Website sind © Scaled Agile, Inc.
