Bei einem meiner ersten Kundenaufträge fand ich sehr schnell einige Dinge, die verbessert werden mussten. Einige dieser Dinge waren den Teammitgliedern durchaus bewusst (weshalb sie überhaupt nach einem Agilen Coach suchten). Einiger anderer Dinge waren sich Teams überhaupt nicht bewusst. Eines der letzteren soll das Thema dieses Beitrags sein: Wie man Agile Aufwandsschätzung einsetzt und wie man es besser nicht tut.
Agile Aufwandsschätzung: Eine Einführung
Wer mit dem Thema Agile Aufwandsschätzung schon vertraut ist, überspringe diesen Absatz oder lese ihn zur Unterhaltung.
Agile Teams möchten verschwenderische Gespräche über subjektive Dauer von Aufgaben vermeiden, daher schätzen sie in abstrakten Zahlen. Unsere „Einheit“ heißt Story Points, was wörtlich „die Anzahl der (abstrakten) Punkte, die wir für eine User-Story schätzen“ ist. Das ist nur Terminologie. Wir könnten die Einheit einfach Äpfel oder Punkte nennen. Mit meinem ersten Scrum Team habe ich in „Pfannkuchen“ geschätzt, weil es wirklich keine Rolle spielt, wie die Einheit heißt. So funktioniert es:
Teams einigen sich auf eine abstrakte Schätzung des Aufwands für eine sehr kleine User Story, idealerweise eine, die bereits erstellt wurde und daher vom Team vollständig verstanden wird. Von da an werden alle anderen User Stories in Vielfachen dieser Story oder in Aufwandssummen zuvor geschätzter Storys geschätzt.
Die bewährte Methode verwendet Fibonacci-Zahlen in ihrer normalen Folge und extrapoliert sie der Einfachheit halber ab 20:
0 | 1 | 2 | 3 | 5 | 8 | 13 | 20 | 40 | 100 |
Warum sind Fibonacci-Zahlen eine hiflreich für diese Aufgabe? Aus mehreren Gründen können Menschen schlecht einschätzen. Wir sind schlecht im Schätzen von Mengen, Entfernungen etc. Überraschung: Wenn wir die Zeit für die Erledigung von Aufgaben schätzen, schneiden wir noch schlechter ab (hier mehr zum Planungsfehlschluss, für den sogar der Berliner Flughafen BER als gutes Beispiel angeführt wird). Die Fibonacci-Zahlen zielen darauf ab, die Zeit aus der Gleichung zu entfernen. Zeit ist nicht, wonach wir suchen: Wir wollen den Aufwand einer Aufgabe abschätzen und ihn ins Verhältnis zu anderen Aufgaben setzen. Fibonacci-Zahlen ermöglichen das ganz natürlich:
„Ich denke, diese Funktion ist genauso aufwändig wie diese beiden Funktionen zusammen.“
Warum ist es eine schlechte Idee, große Features anzugehen?
Viele Teams haben inzwischen realisiert: Es ist eine schlechte Idee, zu versuchen sehr große Funktionen innerhalb eines Sprints umzusetzen. Hauptsächlich ist es die inhärente Unsicherheit großer Features, die es unwahrscheinlich macht, sie innerhalb eines Sprints fertigstellen zu können. Wo große Unsicherheit herrscht braucht es mehr Kommunikation, mehr Klärungsbedarf und all das stellt Aufwand dar.
Um es ganz konkret zu machen: Nehmen wir an, wir haben ein Team mit einer Durchschnittsgeschwindigkeit von 25 Story Points pro Sprint. Dieses Team setzt Funktionen im Wert von 25 Story Points pro Sprint um. Was ist wahrscheinlicher?
- Das Team schafft es, 6 User Storys mit jeweils 5 Story Points fertigzustellen oder
- Das Team schafft es, 1 User Story mit 20 Story Points und eine weitere mit 8 Story Points fertigzustellen?
Die meisten Teams erkennen schnell: Es ist Option a. Der organisatorische Aufwand, der mit den Unsicherheiten der größeren Storys einhergeht, und die mögliche Nacharbeit, nachdem erst aufwendig das Falsche gebaut wurde, sind die größten, aber nicht die einzigen Hürden, die verhindern, dass große Features innerhalb eines Sprints fertiggestellt werden.
Aus diesem Grund haben sich die meisten Teams die Regel gesetzt, keine Funktionen zu übernehmen, die eine bestimmte Aufwandsschätzung überschreiten. Diese Teams nehmen sich vor, diese großen Funktionen zuerst zu zerlegen und dann umzusetzen. Das empfehle ich natürlich auch nachdrücklich. Jeff Sutherland hat eine Metrik dafür definiert: Er nennt sie “Success at Scale” und sie bezeichnet die Wahrscheinlichkeit, eine User Story bestimmter Größe innerhalb eines Sprints fertigzustellen.
Die Situation vor Ort: Teams begrenzen ihre Skala und warum das ein Problem ist
Einige der Teams hatten auch erkannt, dass sie nicht erfolgreich waren, wenn es darum ging, große Features umzusetzen. Ihr “Success at Scale” war einfach unwahrscheinlich. Sie haben sich zu oft Dinge vorgenommen, die zu groß waren, um sie in einem Sprint zu bewältigen. Um darin besser zu werden, hatten sie beschlossen, ihren Maßstab zu verändern! Sie haben ihre Skala auf 13 begrenzt. Der Fehler, den sie damit gemacht haben bestand darin, dass die Begrenzung der Skala nicht dazu führt, dass User Stories besser zerlegt werden. Im Gegenteil: Die Begrenzung der Skala führt nur zu relativ unterschiedlichen (kleineren) Schätzungen, was wiederum zu einem tatsächlich schlechteren Ergebnis führt.
Hier ist eine kleine Metapher dafür, warum die Begrenzung Ihrer Skala eine so schreckliche (jeglicher Logik widersprechende) Idee ist:Nehmen wir an, wir messen die Wassertemperatur. 100°C ist kochend heiß, aber schon 60°C tut ziemlich weh. Nehmen wir an, wir begrenzen unsere Skala auf 40°C, um das Maximum zu erreichen. Schön, oder? Jetzt können wir uns nicht mehr verbrennen! Falsch! Was früher 60°C gekennzeichnet war, ist jetzt 24°C. Wir haben nur die Etiketten geändert, aber wir haben die Fakten der Natur nicht geändert (und können es auch nicht): Offensichtlich werden wir uns weiterhin verbrennen.
Wenn Teams die Aufgabe haben, die Größe von User Stories im Product Backlog auf einer Skala von 1 bis 13 Story Points zu schätzen, werden sie sich höchstwahrscheinlich an die Realität der neuen Skala anpassen: Plötzlich wird 13 zum absoluten Maximum, zum Siedepunkt. Dies bedeutet wiederum: Die späteren, weniger gut verfeinerten Backlog-Einträge mit niedrigerer Priorität weiter unten im Backlog werden als dieses neue Maximum geschätzt: 13!
Lasst uns genauer hinschauen, warum das einer guten Planung im Wege steht:
Der erste Nachteil ist der Verlust von Genauigkeit
Ein Aspekt der agiler Aufwandsschätzung besteht darin, Schätzungen zu erleichtern, indem subjektive Einschätzungen einzelner, unterschiedlich erfahrener Personen (zeitlich geschätzt, gefolgt von langen Argumenten über „Wer hat Recht?“) durch relative Schätzungen ersetzt werden. Hierbei wird jeder Backlog-Eintrag mit anderen Funktionen im Backlog in Beziehung gesetzt wird.
Die Verwendung der Fibonacci-Sequenz hat sich als bewährte Methode herausgestellt: Sie ist ein guter Kompromiss zwischen „genau“ und „schnell“. Die Verwendung aller natürlichen Zahlen zwischen 0 und 100 wäre viel genauer, aber eben deutlich langsamer: Es würde lange Diskussionen darüber geben, ob ein Backlog-Eintrag nun eine 6 oder eine 7 ist oder ob ein gewisser Aufwand 95 oder 96 beträgt.
0 – 1 – 2 – 3 – 5 – 8 – 13 – 20 – 40 – 100
0 – 1 – 2 – 3 – 5 – 8 – 13
Die erste Sequenz besteht aus 10 Zahlen, die zweite aus nur 7. Das Team verliert automatisch 30% an Genauigkeit, wenn es versucht Aufwände innerhalb der Skala von 7 Zahlen zu schätzen.
Der zweite, größere Nachteil ist, dass Beziehungen weniger sichtbar sind
Die kleinere Skala hat einen viel geringeren Faktor (eine andere Beziehung) zwischen den Elementen auf der Skala:
0 – 100: Diese Sequenz hat einen Durchschnitt von 19,2 und einen Median von 6,5. Die Beziehung zwischen dem Maximum und dem Medianwert ist ein Faktor von 15,4
0-13: Diese Sequenz hat einen Durchschnitt von 4,6 und einen Median von 3. Die Beziehung zwischen dem Maximum und dem Medianwert ist ein Faktor von 4,3
Backlog-Einträge, die maximal groß geschätzt wurden, repräsentieren sehr oft spätere, größere Multi-Sprint-Teilprojekte und sollte auf jeden Fall im Laufe der Zeit zerlegt werden. In der Anfangsphase eines Projekts habe ich persönlich sehr oft einen großen Unterschied zwischen den gut verfeinerten User Stories der ersten Sprints und den Elementen weiter unten im Backlog gesehen. Der Faktor zwischen diesen war weit größer als 4,3. Der Faktor/das Verhältnis zwischen diesen verdeutlicht gut, wie viel Unsicherheit diese Elemente mit sich bringen und wie sie behandelt werden sollten (noch mehr Verfeinerung, noch mehr Aufschlüsselung).Die Skala zu begrenzen bringt nicht nur nichts. Es ist absolut schädlich, da es sowohl die Genauigkeit als auch die Klarheit von Backlog-Einträgen verringert. Auf der begrenzten Skala bleiben nur Aufwände von 1, 2 und 3 als unterdurchschnittliche Größen für User Stories. Seien wir ehrlich: Auf der Skala eines großen Projekts ist das zu wenig Differenzierung, um unterschiedliche Komplexitäten zu bewältigen.
Die Lösung ist einfach: Schätzt mit der ganzen Skala (und am besten mit Planungs-Poker).
Ein Aspekt des Problems bestand darin, dass das oben genannte Team keine Planungs-Pokerkarten hatte (oder einen Chief Bastel Officer, der einfach selbst Karten bastelt). Also hatten diese Teams einfach mit Händen und Fingern geschätzt. Aufgrund der natürlichen Begrenzung der Anzahl der Finger sind sie automatisch unter 13 geblieben.
Mittlerweile gibt es Hunderte von Apps für Planning Poker / Agile Aufwandsschätzung:
- Agile Estimation
- Agile Planning Poker
- Planning Poker
- Ich verwende diese und mag sie sehr: Scrum Time Planning Poker
Damals wollte ich dem Team schnell ein paar Planungs-Pokerkarten schenken. Ja, echte, physische Spielkarten. Also ging ich zu jedermanns Lieblings-Online-Händler und war schockiert: Es gibt mehrere Produkte, die tatsächlich den gleichen Fehler machen! Das hier zum Beispiel: Agile-Estimation-Poker-Cards-Fibonacci – reicht nur bis 21. Die Teams laufen also genau in die oben beschriebene Falle. Gleiches hier: Ein weiteres Set mit begrenztem Maßstab. Niemand sollte die kaufen! Eine großartige Möglichkeit, Team daran zu hindern, erfolgreich große Features umzusetzen. Was ist mit größeren Dingen, die erst später im Backlog auftauchen? Wir schätzen sie einfach nicht? Je weniger detailliert unsere Skala ist, desto schlechter wird unsere langfristige Planung sein.
Zum Glück gibt es auch positive Beispiele: Agile Planning Poker Cards von Ulassa – die volle Größe und ein tolles Design. So wird’s gemacht!
Mit einem geeigneten Kartensatz, befreit von den Fesseln einer begrenzten Skala, schätzte das Team das gesamte bekannte Backlog. Die erhöhte Granularität mit der vollständigen Fibonacci-Skala führte zu realistischeren Aufwandsverhältnissen zwischen Backlog-Einträgen. Dies machte es wiederum einfacher vorherzusagen, wann wir Dinge fertigstellen konnten. Die Verwendung des vollen Umfangs hat endlich wieder wichtige Gespräche angeregt: Gespräche über das Zerlegen dieser User Stories, über verschiedene Wege der Umsetzung. Dies war (unter anderem), was das Team brauchte, um wieder Dinge fertig zu kriegen.
Weiterführende Literatur:
- https://www.tempo.io/blog/why-we-are-so-bad-at-time-estimation
- Best of Mike Cohn on Agile Estimation:
- Should Story Points Be Assigned to a Bug Fixing Story? (Hier stimme ich nicht zu, aber das ist ein Thema für einen anderen Blogpost.)
- Why I Don’t Use Story Points for Sprint Planning
- Story Points Estimate Effort Not Just Complexity