Die Verwendung von Story Points im agilen Umfeld ist weit verbreitet. Sie versetzen Teams in die Lage, Schätzungen vorzunehmen, die von der Zeit entkoppelt sind, da sich alle Teammitglieder auf eine gemeinsame Schätzbasis beziehen können, die die Komplexität und den Aufwand einbezieht.

Planning Poker

Die populärste Methode, Schätzungen mit Story Points durchzuführen, ist Planning Poker. In den Schätzrunden erhält jedes Teammitglied einen Satz an Karten, die verschiedene Story Point Werte aufweisen. Für gewöhnlich wird hier eine an die Fibonacci-Reihe angelehnte Skala verwendet (1,2,3,5,8,13,20,40,100). Der exponentielle Anstieg der Werte verdeutlicht, dass je größer die Story ist, desto ungenauer sie auch abgeschätzt werden kann.

Zudem gibt es noch ein paar Sonderkarten, die je nach Team unterschiedliche Bedeutungen haben können. Zum einen gibt es zumeist eine Fragezeichen-Karte. Diese signalisiert, dass jemand sich nicht in der Lage sieht, eine Story zu schätzen, da ihm noch wichtige Informationen fehlen. Die meisten Teams vereinbaren, dass wenn diese Karte gelegt wird, die Story so weit besprochen wird, dass das Teammitglied in die Lage versetzt wird, in der Wiederholung der Schätzrunde eine Abschätzung abzugeben.

Und schließlich gibt es auch noch die Kaffeetasse, die signalisiert, dass eine Pause angebracht ist, weil der Kopf schon raucht.

Bevor die erste Runde Planning Poker durchgeführt werden kann, muss sich das Team auf eine gemeinsame Referenzstory einigen. Auch hier ist es jedem Team überlassen, diese Story zu finden und zu definieren. Als klare Empfehlung kann man aber sagen, dass es sich als hilfreich erwiesen hat, Stories mittlerer Komplexität auszuwählen, die das gesamte Team bezüglich Aufwand und Komplexität gut kennt. Diese sollte dann Bereich von 3-5 Story Points verortet werden. Ausgehend von dieser Story werden dann die neuen Stories eingeschätzt.

Dafür wird die zu schätzende Story kurz vorgestellt. Nun wählt jeder Teilnehmer verdeckt eine Karte aus, die seiner Einschätzung widerspiegelt. Wichtig ist hier, dass die Karte noch verdeckt bleibt und alle gleichzeitig ihre Einschätzung aufdecken. Dies stellt sicher, dass jeder unbeeinflusst von anderen seine Einschätzung geben kann.

Wenn die aufgedeckten Werte sehr weit auseinanderliegen (auch hier muss jedes Team wieder für sich schauen, was Sinn macht), dann legen diejenigen, die den höchsten und den niedrigsten Wert geschätzt haben dar, warum sie die Story so einschätzen.

Wenn große Uneinigkeit besteht, dann wird die Schätzrunde wiederholt, bis das Team sich auf einen gemeinsamen Wert geeinigt hat.

Doch durch den Einsatz von Story Points kann man eine ganze Reihe von unterschiedlichen Zielen erreichen.

1. Priorisierung

Story Points können als Hilfsmittel für den Product Owner dienen, wenn es darum geht, dass Product Backlog zu priorisieren. Die Information, wie viel es das Team kosten wird, ein Item fertigzustellen ist eine hilfreiche Information um Wert und Aufwand in ein Verhältnis zu stellen. Optimalerweise sind die oberen Einträge eines Product Backlogs schon abgeschätzt, bevor das Team mit dem PO ins Sprint Planning geht, doch auch im Sprintplanning kann es noch hilfreich für den PO sein, den Aufwand der Stories zu kennen und in die Überlegungen mit einzubeziehen.

2. Kapazitätsplanung

Die Velocity eines Teams wird oft in Story Points angegeben. Kennt man die durchschnittliche Velocity eines Entwicklungsteams, dann kann man diesen Wert verwenden, um im Sprintplanning den Umfang des Sprint Backlogs damit zu bestimmen. Somit braucht das Team sich nicht auf sein Bauchgefühl alleine zu verlassen, sondern kann seine Einschätzung auch auf den Werten der vergangenen Sprints basieren lassen. Die Verfügbarkeit der Teammitglieder kann mit einbezogen werden, indem man die Anzahl der erreichten Storypoints durch die verfügbaren Mitglieder und die Sprintdauer teilt.

3. Vorhersagbarkeit

Auch die Vorhersagbarkeit macht sich die Velocity zunutze. Zum Beispiel kann man die Genauigkeit der Schätzung des Teams dadurch bestimmen, dass man die im Sprintplanning geplanten Storypoints durch die am Ende des Sprints tatsächlich fertiggestellten Storypoints teilt. Diese Aussage wiederum kann hilfreich sein, um längerfristige Voraussagen zu erleichtern, zum Beispiel indem man die durchschnittliche Velocity und die Vorhersagbarkeit nutzt, um Releasepläne zu erstellen.

4. Team-Entwicklung

Die in Story Points angegebene Velocity ermöglicht auch die Darstellung von Verbesserungen oder Verschlechterung innerhalb des Teams. Schaut man sich den Verlauf der Velocity über einen größeren Zeitraum an, so kann man erkennen, ob ein Team sich kontinuierlich steigert, stagniert oder sogar langsamer wird. Dies setzt natürlich voraus, dass in allen Messungen die gleiche Referenzstory verwendet wird.

5. Kommunikation

Zuletzt bietet das Schätze mit Story Points einen wunderbaren Einstiegspunkt für das Team, um über Stories zu diskutieren und sich auszutauschen. Dies ist wahrscheinlich der wichtigste Aspekt. Durch das gemeinsame Maß ist es den Teammitgliedern möglich, ein gemeinsames Verständnis für Stories zu bekommen, auch wenn sich der Kenntnisstand und die Erfahrung der Entwickler unterscheiden. Die erfahreneren Teammitgliedern helfen den unerfahreneren die Komplexität und die Aufwände besser zu erfassen, so dass am Ende neben einer gemeinsamen Einschätzung auch ein Wissenstransfer und größeres gemeinsames Verständnis vorherrscht.

Tool für die Teams

Ganz egal welches der Ziele man verfolgt, wie man Story Points bestimmt und was man auswertet, wichtig ist, dass Story Points als Hilfsmittel für die Teams gedacht ist und nicht für das Management. Wenn Zielerreichung oder Leistungsbeurteilung an Kennzahlen gebunden sind, wie zum Beispiel Velocity pro Sprint oder Steigerung der Velocity, dann besteht die Gefahr, dass die Teams Story Points nicht mehr als Hilfsmittel verwenden um ihre Arbeit zu erleichtern und verbessern, sondern dass sie ihren Umgang damit so gestalten, dass sie möglichst gute Werte für das Management ausweisen können. Dies ist in der Regel aber eher kontraproduktiv. Daher sollte man immer im Kopf behalten, dass es in erster Linie den Teams nutzen sollte und erst in zweiter Linie Transparenz für das Management.

Diskussion und Kritik

Story Points sind kein Bestandteil irgendeines (agilen) Frameworks. In vielen ScrumMaster Trainings werden sie als ein Standardtool vorgestellt und somit sind sie auch weit verbreitet. Es gibt allerdings auch einige Stimmen, die jegliche Art von Schätzung (da immer fehlerbehaftet) als Waste (Verschwendung im Lean Sinne) ansehen. Ganz prominent ist zum Beispiel die #noestimate-Bewegung, die vor einigen Jahren aufkam.

Story Points sind sicher nicht für alle Teams und alle Anwendungsfälle geeignet. Und für sehr reife agile Teams kann auch der #noestimate-Ansatz viel sinnvoller sein. Für den Einstieg in agile Methoden bei Teams, die gerade aus klassischem Projektmanagement kommen bieten die Story Points aber einige Vorteile. Hier sollte man einfach nach dem Grundsatz von INSPECT&ADAPT experimentieren und schauen, was man braucht.

Der agile Werkzeugskoffer ist reichhaltig, wählen muss man die richtigen Werkzeuge aber immer mit Bedacht.