Agile Punktlandung: Schätzen mit Story Points

von Marian Bosse

| zuletzt aktualisiert am 01.08.2024

|
• Insights •
• Technologien

Wer Zahlen nennt, geht eine Verpflichtung ein – das mit dem Schätzen ist also immer so eine Sache. Denn schätzen bedeutet keinesfalls wissen, sondern per Definition: "ohne exaktes Messen, nur auf Erfahrung gestützt näherungsweise bestimmen". Besonders da, wo solche stützenden Erfahrungswerte fehlen, kann Schätzen also ein heikles Unterfangen sein und falsche Erwartungen wecken.

Das Problem mit absoluten Werten oder: Wie viele Stunden braucht Ihr, um aus diesem Schaf einen Pulli zu stricken?

"Wieviel kostet dieses Feature?" Wenn man das als Team nur so genau wüsste, vor allem wenn wir für seine Entwicklung Neuland betreten! Die Antwort auf diese Frage kann also nur falsch sein und liefert gern viel Stoff für fruchtlose Diskussionen darüber, warum die Schätzung denn nicht präziser war. Viele Auftraggebende wünschen sich "belastbare", am liebsten "präzise" Schätzungen. Diese sind jedoch meistens zum Scheitern verurteilt und beeinflussen leider auch keineswegs die Realität: Sie machen ein Team nicht schneller und ein Feature nicht günstiger - haben aber im schlimmsten Fall zur Folge, dass an der Qualität gespart wird. Eine absolute Schätzung beinhaltet den Anschein von Faktizität, wird ihm aber in den seltensten Fällen gerecht. Als Folge davon werden absolute Schätzungen deutlich zeitaufwändiger, es müssen mehr Details vorliegen, kleine Änderungen beeinflussen die Schätzung wieder und der Projektplan muss immer wieder angepasst werden, um noch mit der Realität mithalten zu können. Viel geeigneter sind relative Schätzmethoden wie die Story Points, mit denen sich der Entwicklungsaufwand auf relative Weise beschreiben lässt.

Schätzen mit Story Points

Wie die meisten Scrum-Teams sind auch wir generell positiv gegenüber Schätzungen eingestellt, da sie uns bei der Organisation der Arbeit helfen. Durch schätzen wissen wir, ob eine Aufgabe schnell erledigt sein wird oder länger dauert und ob eine Sprintlänge dafür genügt. Wenn nicht, zerlegen wir die Aufgabe in kleinere Häppchen, die jeweils für sich einen Mehrwert generieren.

Dabei vermeiden wir absolute Zahlen, sondern schätzen vielmehr den Umfang einer Aufgabe relativ zu anderen uns bekannten Aufgaben. Statt zu sagen "Diese Aufgabe dauert X Tage", sagen wir: "Diese Aufgabe hier hat voraussichtlich den doppelten oder den dreifachen Umfang dieser Aufgabe dort." So machen wir die Aufgaben in unserem Backlog miteinander vergleichbar.

Einflussfaktoren der relativen Schätzmethodik

Beim relativen Schätzen betrachten wir nicht, wie oft angenommen, nur die Komplexität der Aufgaben. Eine derartige Einschränkung ergibt keinen Sinn. Ein Beispiel: Die Komplexität, einen Nagel in die Wand zu hauen, erhöht sich nicht, wenn ich statt einem Nagel hundert Nägel einschlagen muss. Es ist vielmehr der Aufwand, der sich erhöht. Und auch die Ungewissheit, etwa wenn ich nicht weiß, ob ich überhaupt noch hundert Nägel im Keller habe oder zum Baumarkt fahren muss. Außerdem erhöht sich die Gefahr, ein Kabel in der Wand oder unsere Daumen zu treffen, bei hundert Nägeln deutlich. Für solche schlecht kalkulierbaren Risiken planen wir besser einen Puffer ein.

Bei der Schätzung beziehen wir also verschiedene Aspekte mit ein:

• die Komplexität der zu erledigenden Aufgaben

• die Menge der zu erledigenden Aufgaben

• die Ungewissheit bei der Umsetzung der Aufgaben

• das Risiko bei der Implementierung neuer Techniken

Die reine Zeitdauer, um eine Aufgabe zu bewältigen, darf dabei keinen Einfluss auf die Schätzung der Story Points haben. Ein Junior wird wahrscheinlich länger an einer Aufgabe sitzen als eine erfahrene Entwicklerin - die Schätzung ist aber immer eine Team-Schätzung und sollte diesen Unterschied nicht berücksichtigen.

Beabsichtigt ungenau

Die Fibonacci-Folge 1, 2, 3, 5, 8, 13, 21 hat sich als Basis der Schätzung von Story Points bewährt, da es hierbei um Größenordnungen geht: Je komplexer, aufwendiger, unsicherer und riskanter die Aufgabe, desto weiter liegen die Schätzwerte auseinander. Damit wird die Unschärfe in der Schätzung, die sich aus den oben genannten Variablen ergibt, in der Schätzung direkt mit abgebildet: Wenn eine 1 die kleinste Schätzung ist, die wir verwenden und eine 2 bereits doppelt so groß ist, können wir wahrscheinlich ohnehin bei einer Aufgabe im Bereich einer 13 keine Aussage mehr treffen ob es eher eine 12 oder eine 14 wäre. Größer als 13? Dann ist es wohl eine 21.

Grundsätzlich wird davon ausgegangen, dass sich mit jeder Zahl in der Reihe der Umfang der Aufgabe in etwa verdoppelt - das gleiche gilt im übrigen auch für die Schätzungenauigkeit. In der Anwendung als Indikator für die Leistungsfähigkeit (Velocity) eines Teams kommen wir damit im Median der Realität deutlich näher als beim Versuch, in absoluten Größen zu schätzen.

Was kostet ein Story Point?

Da wir es hier mit einer non-linearen Reihung zu tun haben, lässt sich ein Story Point auch nicht in Zeit und damit Kosten umrechnen. Was wir allerdings sehr wohl können, ist basierend auf der Velocity des Teams ableiten, wie lange die Umsetzung einer Reihe von Aufgaben voraussichtlich dauern wird und welche Kosten anfallen.

Bei einer angenommenen Velocity von 18 schafft das Team also rechnerisch in 2 Wochen Sprint eine 13er- und eine 5er- oder auch drei 5er- und eine 3er-Story. Wenn sich in unserem Backlog Features im Umfang von ~35 Storypoints befinden, wissen wir also, dass wir aller Voraussicht nach in zwei Sprints unser Backlog abarbeiten können. Das Ganze multipliziert mit den Kosten des Teams pro Sprint und wir können gut einschätzen, was unser Produkt kosten wird.

Diese Art der Ermittlung von Kosten hat sich unserer Erfahrung nach gegenüber der herkömmlichen absoluten "Schätzung" als deutlich treffsicherer erwiesen - und das bei weitaus geringerem Aufwand für die Schätzung selber und gleichzeitig höheren Freiheitsgraden in der Umsetzung - everybody wins!

Was sollte man mit Story Points nicht machen?

Story Points sollen uns dabei helfen, unsere Planung mit relativ geringem Aufwand an der Realität auszurichten. Nothing more, nothing less! Da es aber in einigen Bereichen ab und zu mal zu Fehlinterpretationen kommt, hier zwei Dinge, die man mit Story Points nicht machen sollte:

Teams vergleichen

Story Points sind eine relative Metrik – relativ zu anderen Aufgaben, die das Team bearbeitet hat oder bearbeiten wird. Daher haben Story Points keine – wirklich NULL – vergleichende Aussagekraft über Teamgrenzen hinweg. Jedes Team baut auf Basis seiner relativen Schätzung eine eigene Schätzhistorie auf, die sich nicht mit anderen Teams vergleichen lässt.

Teams sollten sehr interessiert daran sein, ihre eigenen Bepunktungen immer wieder zu überprüfen und zu verfeinern, um die Aussagekraft ihrer Velocity als persönliches Planungsinstrument so hoch wie nur möglich zu halten. Sie treten mit ihrer Velocity aber nicht in einen Wettbewerb mit anderen Teams. Das Ergebnis wäre lediglich, dass Teams immer höhere Fibonacci-Zahlen verwenden, um "noch mehr Velocity" zu demonstrieren - über ihre Lieferfähigkeit sagt das aber nichts aus: You get what you measure.

Schätzungen überschätzen

Es gibt keine richtigen oder falschen Schätzungen. Eine Schätzung – ob in Story Points oder T-Shirt-Größen, in Äpfeln oder Birnen – bleibt eine Schätzung und dient unserer Planung vor dem Horizont von Unsicherheit. Wir können und sollten Teams dabei helfen, die Basis ihrer relativen Schätzungen breit aufzustellen und immer wieder zu hinterfragen, um im Mittel eine Vorhersage zu ermöglichen.

Dabei wird es immer wieder vorkommen, dass ein Team nach getaner Arbeit zu der Erkenntnis gelangt, dass dieses 3er-Ticket eigentlich ein 5er-Ticket war – und sollte dann überlegen, was man anfänglich übersehen hatte (z.B. das Risiko beim Einsatz einer neuen Technologie), um bei der nächsten Schätzung mit geschärftem Verstand zu Werke zu gehen.

Somit wird die Schätzung zum Werkzeug der kontinuierlichen Verbesserung - ohne den Anspruch, irgendwann ausschließlich "richtige Schätzungen" abzugeben, aber mit dem Anspruch, aus dem Erlebten zu lernen.

Wie planen wir mit Story Points?

Wenn sich die Anwendung von Story Points in einem Team etabliert hat und das Team seine Schätzungen immer wieder kritisch hinterfragt und verbessert, bildet sich nach einigen Sprints eine recht stabile Velocity aus - also die durchschnittliche Leistungsfähigkeit an Story Points, die das Team in einer Iteration abarbeiten kann. Bei der Berechnung der Velocity sollte allerdings nicht auf den Mittelwert, sondern auf den Median geachtet werden, da dieser Ausreißer deutlich besser verarbeiten kann und so eine genauere Vorhersage ermöglicht.

Die Velocity erlaubt es dem Team dann sehr gut, mit den bereits geschätzten Aufgaben im Backlog zu planen - wie oben bereits angedeutet, können wir auf Basis der Velocity unser Backlog sehr gut hinsichtlich voraussichtlicher Umsetzungszeiten begutachten und damit eine Vorhersage treffen, wie lange es dauern wird, die darin enthaltenen Aufgaben - bzw. den bereits beschätzten Teil des Backlogs - abzuarbeiten. Das erlaubt uns dann auch eine in der Regel ziemlich treffgenaue Aussage darüber, mit welchen Kosten für ein Produktziel oder ein Set an Features zu rechnen ist und wie sich aktuelle Arbeiten auf die weitere Abarbeitung einer Produkt-Roadmap auswirken werden.

Wie starten Sie mit Story Points?

Die Schätzung nach Story Points - und auch das Schätzen als Team - gelingt in der Regel am besten, wenn Teams, die damit beginnen wollen, die Zeit bekommen, die sie brauchen, um die Methode zu erlernen und die Anwendung sukzessive zu verbessern. Wir empfehlen, hierfür einen initialen Schätzworkshop durchzuführen und das Team mit der Kunst der relativen Schätzung vertraut zu machen. Gut eignen sich hierfür auch Planning-Poker-Karten, die oft ebenfalls auf einer Fibonacci-Folge (bzw. einer angepassten Folge aus 0, 1/2, 1, 2, 3, 5, 8, 13, 20, 50 und 100) aufbauen und den Prozess gut veranschaulichen. Der Rest ist Learning by Doing und endet in der Erkenntnis, dass relative Zahlen am Ende genauere Auskünfte geben als absolute - mit geringerem Aufwand und weniger Druck auf den Mitarbeitenden.