Warum Story Points? Warum Fibonacci?
Der Sinn dahinter ist: Durch die Abstraktion weg von realen Zeitschätzungen – z.B. 10 Stunden versus 12 Stunden – trägt man dem Umstand Rechnung, dass kein Mensch wirklich schätzen kann, ob man für eine auch nur einigermaßen komplizierte/komplexe Aufgabe 10 oder 12 Stunden braucht bis zur Fertigstellung. Viel besser kann man vergleichend schätzen, ob eine Aufgabe umfangreicher ist als eine andere, z.B. doppelt so groß. Also: Wenn das da eine 1 ist, ist das ungefähr eine 2 – oder noch mal viel größer – wenn das eine 3 ist, dann ist das viel mehr, vielleicht eine 8...
Story Points sind “Töpfchen”
Insofern bildet man “Töpfchen”, z.B. das 8er-Töpfchen, in das gedanklich Schätzungen mit 8 oder 7.5 oder 6.27 oder 5.5 kommen. Diese Range statt punktuellen Schätzungen ist sinnvoll, weil man eh nicht weiß, was am Schluss tatsächlich rauskommt. Die Fibonacci-Reihe benutzt man, weil es realistisch ist, abzuschätzen, ob die Aufgabe eine 2 oder 3 ist, aber nicht eine 13 oder 14. Je größer die Aufgabe, desto ungenauer die Schätzung, bis hin zu 40 versus 100: Wenn es mehr ist als eine 40, dann nehmen wir gleich 100, weil größer als 40 in der Regel und im Grunde heißt “Wir wissen es nicht so wirklich.”
Nun kann man mit diesem einfachen Ansatz auch viel Unsinn treiben. Jedes der hier genannten ist ein Realwelt-Beispiel aus der freien Wildbahn des agilen Arbeitens in der großen Welt da draußen, beobachtet mit Schmunzeln oder mit Grauen.
Anti Pattern 1: Die gesamte Poker-Skala verwenden
Schätz-Poker-Karten umfassen meist die Größen 1,2,3,5,8,13,20,40,100. Manchmal noch eine Karte mit ½ dazu und ein Fragezeichen für “Weiß nicht.” Ziel der Schätzung ist, Aufgaben im Vergleich zueinander zu schätzen. Sagen wir nun, dass die 1 eine sinnvolle Größe ist, also eine Aufgabe, deren Lösung wertschöpfend ist und (mehr oder weniger) für sich stehen kann, also nicht allein gestellt sinnloser Teil eines sinnvollen größeren Ganzen ist. Was ist dann die 100?! Eine 100 ist dann nicht etwas 100 mal eine 1, sondern einfach: Etwas ganz, ganz Großes. Etwas unschätzbar Großes. Ich zeige jedem, der mich herausfordert, anhand seiner Daten: Wenn die 100 eine statistisch sinnvolle Schätzung ist, dann gibt es zwischen 1, 2 und 3 keinen statistischen Unterschied. Umgekehrt, wenn die 1, 2, und 3 sinnvolle Unterscheidungen sind, ist die 100 so weit jenseits unseres Verständnisses und annähernd zuverlässiger Schätzung, dass 100 für uns nur heißen kann: Aufgabe kleiner hacken und die Teile neu schätzen. (Viele Teams benutzen tatsächlich nur fünf oder sechs verschiedene Story-Point-Werte, etwa von der 1 bis zur 13, alles was drüber ist, muss gesplittet werden.)
TIPP: Fangt mit fünf oder sogar nur vier verschiedenen Werten an, z.B. 1, 3, 8, 20. Prüft dann, ob das Schätzen überhaupt was bringt. Sind also die 1er statistisch tatsächlich von den 3er unterscheidbar uws.
Anti Pattern 2: Komplexität schätzen
Irgendwann kam auf, dass man mit Story Points eigentlich Komplexität schätzt. Also nicht, wie viel Aufwand eine Aufgabe darstellt, sondern wie komplex sie ist. Ganz deutlich, ganz hart: Das ist Blödsinn. Der Sinn von Schätzung ist, die Entscheidung “soll ich es überhaupt machen” zu ermöglichen und zu planen. Zum Beispiel benutzen viele Scrum Teams ihre Velocity, also die Zahl der Story Points, die sie pro Sprint abarbeiten können, um zu planen, wie viel sie in den nächsten Sprint nehmen. Unsere Velocity ist 20 (plus/minus x, sie schwankt natürlich), also nehmen wir Aufgaben für 20 Story Points in den Sprint. Dabei geht es um den Aufwand, nicht die Komplexität. Wenn das Team dem Produktmanager oder Product Owner sagt, das Feature “kostet” ihn geschätzt 13 Story Points, heißt das, er bezahlt Aufwand. Nämlich Aufwand, den das Team betreibt, im Wert von geschätzt 13 Story Points. Jetzt kann er entscheiden: Ist ihm das Feature 13 SP wert? Wenn wir Komplexität schätzen, hieße das, dass wir sehr einfache Arbeiten (keine Komplexität), die aber viel Zeit brauchen, mit 1 Story Point bewerten. Das hat weder für die Entscheidung noch für die Planung einen Sinn. Mike Cohn, Gründungsmitglied der Scrum Alliance und bekannter Autor hat deshalb schon 2010 in einem Blogpost klar und deutlich festgehalten: It’s effort, not complexity.
TIPP: Diskutiert im Team, was ihr eigentlich schätzt. Aufwand? Komplexität? Risiko? Wie hängen die Faktoren alle zusammen?
Anti Pattern 3: Äpfel mit Birnen vergleichen
Es gibt tatsächlich Menschen, die die Leistung von Teams vergleichen, indem sie betrachten, wie viel Story Points Team A im Vergleich zu Team B schafft pro Sprint. Mit Menschen meine ich Manager. Niemand, der Story Points verstanden hat, würde das tun. Was passiert, wenn mein Team erfährt, dass es “nur” 20 Story Points Velocity hat, im Vergleich zum viel tolleren Team B, das 35 (!!!) Story Points Velocity hat?! Also, wäre ich Mitglied von Team A, würde ich einfach die Schätzungen ändern. Ab jetzt sind einfache Aufgaben keine 1 mehr, sondern gleich mal eine 3. Kummulierte Burndowns über alle Teams in einem Projekt sind der logische Folgefehler: Sie sagen nicht das aus, was suggeriert wird. Kummulierte Burndowns über mehrere Teams müssen auf Story-Anzahl-Basis gemacht werden. Eine vermeintlich gute Lösung für das Äpfel-Birnen-Problem ist es, festzulegen, dass ein Story-Point-Töpfchen einem Zeitbetrag entspricht: 1 SP heißt bei uns ungefähr einen halben Tag. Diese Idee geht aber völlig an den Prinzipien hinter Story Points vorbei und ist unser nächstes Anti Pattern.
TIPP: Velocity ist eine Team-Metrik und sollte nicht ohne weiteren Kontext kommuniziert werden.
Anti Pattern 4: Points auf Zeit mappen
Die Idee ist so naheliegend wie schlecht: 1 SP heißt bei uns ungefähr einen halben Tag. Oder zwei Stunden. Oder ein Tag. Dadurch passieren drei Dinge: Erstens wird nicht mehr vergleichend geschätzt, also Task A (eine 2) ist doppelt so groß wie Task B (eine 1), sondern es wird Zeit geschätzt. Wenn PO und Team in die Diskussion gehen, ob der halbe SP noch in den Sprint passt oder nicht, ist das entwürdigend, wahnwitzig und v.a. Verschwendung von Zeit und Nerven. Hier sind wir beim fünften Anti Pattern, aber erst noch ein Tipp...
TIPP: Verwendet statt Zeit eine Referenz-Aufgaben (egal ob Story, Task…) um festzulegen, was eine 1 oder 5 oder 20 ist. Also zum Beispiel: Die Story mit der Formular-Änderung für das Dings, das ist unsere 1.
Anti Pattern 5: Tetris spielen
POs, die unter Druck stehen (und das tun sie alle) und verschiedenen Stakeholdern verantwortlich sind, Wert zu liefern (und das sind sie alle), greifen evtl. zu einem Mittel, das man Management nennt. Sie managen über den Scope des Sprints hinaus auch die Kapazität des Teams, sie bauen sich eine Excel-Tabelle, in der die Velocity des Teams (wie viele Story Points macht das Team pro Sprint) eingetragen wird und alle Stories und Tasks, die mit in den Sprint sollen nach ihren Wünschen, und die Schätzungen werden aufaddiert und es wird hin und her geschoben und getüftelt, bis man die Velocity ausgereizt hat. Denn von den 25 Punkten Velocity nur 22.5 zu verwenden, wäre ja Verschwendung.
Das scheint rechnerische auf den ersten Blick vielleicht sinnvoll, ist jedoch, wie gesagt, wahnwitzig und entwürdigend. Erstens handelt es sich um Schätzungen, die einen Unschärfebereich mitbringen (siehe “Töpfchen”), das Ausreizen auf 0.5 Punkte genau ist Unsinn. Beispiel: Du lädst fünf Kumpels zum Junggesellenabschied ein. Du weißt, dass jeder mind. 5 Halbe trinkt, durchaus auch ein paar mehr. Also rechnest du mit 8 (wegen der Fibonacci-Reihe;). 6*8 = 48. Du denkst also, 48 Halbe werden es tun. Blöderweise hast Du nur 47 im Kühlschrank. Jetzt noch ein Bier zu kaufen und deshalb zu meinen, man hat die Punktlandung vorprogrammiert, ist natürlich völlig unsinnig, da werden sich Biertrinker und Abstinenzler einig sein.
Sprint-Planung ist keine Mathematik
Dazu kommt: Das Team soll sich auf einen selbst gemanagten Sprint Scope committen, das funktioniert bei Management by Numbers von dritter Seite (= PO) psychologisch viel schlechter. Und drittens verführt das Story-Point-Tetris POs dazu, nach Passung in den Sprint zu priorisieren, was den Blick auf die Wertschöpfung verstellt. Zugegeben, das Motto “Mach, was noch rein passt” widerspricht nicht zu 100% dem Motto “Mach, was den bestmöglichen nächsten Wertschöpfungsschritt bedeutet”... aber es ist gefährlich. Wenn die Sprints degenerieren zu einer Aneinanderreihung von Backlog Items, die alle schon fertig im Backlog warten, dann driften wir in Richtung Projektplan auf User-Story-Ebene. Wozu dann agiles Vorgehen?