Nicht immer scheint etwas Sinn zu ergeben – so wie zum Beispiel die Verwendung eines Laubbläsers auf nasser Strasse, direkt nach einem Regenschauer. Egal wie stark der Luftstoss ist, die Blätter bleiben auf der Strasse kleben, es kommt keine Bewegung rein, die Arbeit ist ineffizient. Mehr Bewegung würde oft auch agilen Projekten, die mit Scrum organisiert werden, nicht schaden! Eine Ursache davon sehe ich darin, dass Story Points zwar oft angewendet werden, aber der Sinn dahinter vom Team nicht verstanden wird. Geht es dir oder deinem Umfeld ähnlich? Dann hast du dir oder wurden dir sicher schon folgende Fragen gestellt:
Warum überhaupt in Story Points und nicht in Tagen schätzen?
… weil Story Points ein gemeinsames Verständnis schaffen. Ein Scrum Team setzt sich aus Entwicklern zusammen mit unterschiedlichen Fähigkeiten und Hintergründen, oft eingestuft als Junior, Professional und Senior. Bei jeder Story im Backlog sind im Refinement jedoch alle Entwickler unabhängig davon mit der gleichen Frage konfrontiert: Wie viele Tage dauert die Umsetzung? 
Ein Junior denkt sich vielleicht: “Das habe ich zwar noch nie auch nur ansatzweise gemacht, aber mir kommt ein Lösungsansatz aus dem Studium in den Sinn, den ich mal ausprobieren könnte”. Er schätzt deshalb vier Tage. Der Senior schätzt einen Tag, weil er ähnliche Problemstellungen schon kennt und dadurch die Umsetzung bereits im Kopf hat. Die Unterschiede der Schätzungen sind gross. Entsprechend schwierig ist es, damit umzugehen. Meiner Erfahrung nach führen Schätzungen in Manntagen oft dazu, dass sich Teams zu viel zutrauen und der Sprint mit Stories vollgepackt wird, die am Schluss nicht alle abgearbeitet werden können.
Schätzungen mit Story Points beruhen darauf, dass es für uns Menschen einfacher ist, etwas zu vergleichen, als etwas ein- oder abzuschätzen. Das zeigt sich zum Beispiel bei einem Kind, dem man fünf verschieden grosse Haufen Smarties zeigt und es auffordert, das Grösste auszuwählen. Das Kind wird vermutlich in wenigen Sekunden den grössten Haufen ausgewählt haben. Zeigt man dem Kind nur einen Haufen und fragt es, zu sagen wie viele Smarties darin sind, so wird es bedeutend länger haben für eine Antwort und vermutlich auch falsch liegen. Das zeigt, dass bei Schätzungen nicht die Frage nach dem ‘Wieviel’ im Vordergrund stehen sollte, sondern der Vergleich. Und genau dies berücksichtigt Scrum, indem bei Schätzungen Referenzstories ins Spiel kommen und neue Stories damit verglichen werden.
Eine Referenzstory ist eine Story, die das Team bereits einmal gemacht hat oder aus Erfahrung sehr gut einschätzen kann. Das Team definiert nun eine Story Point Anzahl für diese Referenzstory, z.B. 1. Die Frage am Refinement ist nun aber nicht: Wieviele Story Points ist die Umsetzung sondern eher: Ist der Aufwand oder die Komplexität der aktuell zu schätzenden Story höher oder tiefer im Vergleich zur Referenzstory und wie viel? So ist es wahrscheinlicher, dass Senior und Junior sich bei der Schätzung auf drei Story Points einigen können. Ob man beim Schätzen der Story primär wie im Scrum Guide beschrieben die Komplexität oder doch traditionell den Aufwand berücksichtigt, spielt aus meiner Sicht eine untergeordnete Rolle – wichtig ist, dass sich das Team einig ist wie es gemacht wird.
Warum überhaupt Scrum Poker spielen und nicht den erfahrensten Entwickler schätzen lassen?
… weil Scrum Poker den Austausch und die Transparenz fördert. Scrum Poker in einem Refinement funktioniert klassischerweise so: Jeder Entwickler im Scrum Team erhält ein Set von Karten mit unterschiedlichen Zahlenwerten. Jede Story wird vorgestellt und diskutiert. Sobald die Story einem Entwickler klar ist, legt er verdeckt diejenige Karte auf den Tisch, deren Story Point Zahl für ihn die Komplexität der Story am besten abbildet. Dann werden alle Karten gemeinsam aufgedeckt. Bei unterschiedlichen Schätzungen werden die Hintergründe und Gedanken abgeholt, die zu einer einzelnen Schätzungen geführt haben und im Team diskutiert. Danach einigt sich das Scrum Team auf eine gemeinsame Schätzung. Und dies ist bereits ein grosser Vorteil von Scrum Poker gegenüber Einzelschätzungen erfahrener Entwickler: Den dadurch geförderten Austausch 
des gesamten Scrum Teams. Ein weiterer Vorteil von Scrum Poker liegt darin, dass jeder unbeeinflusst seine eigene Schätzung abgeben kann, da die Schätzungen erst fürs Team aufgedeckt werden, wenn alle geschätzt haben. Würde man die Schätzungen offen auf den Tisch legen, hätte man mit grosser Sicherheit das Verhalten, dass z.B. sich ein Junior nicht traut seine gedachten 5 zu legen, sondern sich der bereits auf dem Tisch liegenden Schätzung 2 des Seniors anpasst. So hätte man zwar Einstimmigkeit in der Schätzung, aber nie die Gelegenheit, über die Differenz von 2 und 5 zu diskutieren und dadurch ein besseres gemeinsames Verständnis der zu schätzenden Story zu erhalten! Durch die Diskussionen werden oft auch zusätzliche Risiken und Abhängigkeiten aufgedeckt, die sonst vergessen gegangen wären.
Warum nach der Fibonacci Reihe schätzen und nicht in beliebigen Ganzzahlen?
… weil Schätzungen dadurch einfacher und fehlertoleranter werden. Stehen für eine Schätzung alle Zahlen zwischen 1 und 100 zur Verfügung, hat man ganze 100 Möglichkeiten, den richtigen Wert zu treffen. Verwendet man aber die Fibonacci Reihe, so bleiben von diesen 100 Möglichkeiten noch zehn übrig, nämlich die Folge (1,2,3,5,8,13,21,34,55,89). In der Praxis wird 34, 55 und 89 oft als 40 und 100 zur Verfügung gestellt. Der Vorteil der Fibonacci Reihe liegt also schon auf der Hand: Durch die kleinere und grösser abgestufte Auswahl wird es einfacher, die passende Zahl auszuwählen. Vergleichbar mit dem Einkauf in einer Bäckerei: Es ist einfacher aus zwei verfügbaren Broten auszuwählen, als aus zehn. Zusätzlich sind in der Fibonacci Reihe die Zahlen gegen oben breiter abgestuft. Das berücksichtigt die Tatsache, dass unsere Schätzung ungenauer wird, je höher die Komplexität und der Aufwand einer Aufgabe ist. Die Fibonacci Reihe erhöht hier die Fehlertoleranz. Zusätzlich beschleunigt die beschränkte Auswahlmöglichkeit die Schätzgeschwindigkeit – entsprechend kürzer wird das Planning. Die Fibonacci Reihe ist übrigens benannt nach dem Mathematiker Leonardo Fibonacci, der damit im Jahr 1202 das Wachstum einer Kaninchenpopulation beschrieb.
Warum brauchen wir eine Velocity?
… um dem Kunden eine Termin- und Budgetplanung zu ermöglichen. Die oben beschriebenen Konzepte sind nicht schwer zu verstehen und anzuwenden, aber es braucht ein Umdenken von der traditionellen Denkweise weg, hin zu einer agilen. 
Nicht jeder Kunde interessiert sich aber für Scrum, ihm ist im Prinzip egal, wie das Entwicklungsteam arbeitet. Er möchte einfach das Resultat und zwar qualitativ hochstehend, zu einem fixen Zeitpunkt, für eine definierte Menge Geld. Fast in jedem Projekt prallen diese beiden Welten und Denkweisen aufeinander. Um hier zu vermitteln, unterstützt die Velocity. Obwohl nicht im Scrum Guide erwähnt, ist sie DAS Mittel, um mit einem agil mit Scrum zusammenarbeitenden Team die Frage zu beantworten, wieviel ein Feature kostet und bis wann es fertig ist.
Die Velocity eines abgeschlossenen Sprints wird berechnet, indem die Summe aller Story Points, die Ende Sprint abgeschlossen sind, addiert werden. Die Summe der Arbeitstage aller Entwickler kann dann durch diese Velocity geteilt werden (oder umgekehrt). Dadurch ergibt sich eine Zahl, die das Verhältnis der Arbeitstage zu Story Points abbildet, basierend auf Erfahrungswerte in der Vergangenheit. Erst diese Zahl bezeichne ich jedoch in der Praxis als Velocity und verwende sie für zukünftige Sprints, um aufgrund der zur Verfügung stehenden Arbeitstage zu prognostizieren, wie viele Story Points im Sprint abgeschlossen werden können. Hat das Scrum Team schon mehrere Sprints abgeschlossen, verwende ich den Durchschnitt der Velocities der letzten 5-10 Sprints für die Berechnung. Das untenstehende Beispiel zeigt schön, wie die Velocity dazu führt, dass der Kunde dank ihr Sicherheit erhält bezüglich seines Termins.
Versteht ein Scrum Team den Sinn von Story Points, führt dies automatisch zu einem anderen Mindset, in dem Story Points nicht er- sondern gelebt werden. Damit ist bereits ein grosser Schritt getan zu einen Burndown Chart nahe der Ideallinie. Oder anders formuliert: die zu Beginn dieses Artikels erwähnte nasse Strasse mit Blättern ist nun trocken und die Anwendung eines Laubbläsers macht Sinn. Entsprechend werden Blätter aufgewirbelt und die Arbeit ist effektiv!
