Story Points machen immer Ärger und lösen ständig Diskussionen aus. Nicht nur darüber was sie eigentlich sind oder repräsentieren, sondern auch darüber, wozu sie überhaupt nützlich sind und schließlich darüber, wie sie ermittelt werden.
In der Tat ist die Sache mit den Story Points nicht ganz so trivial, wie sie für viele auf den ersten Blick aussieht. Und genau das erklärt auch die vielen – teils merkwürdigen – Diskussionen, die man in den Communitys so wahrnimmt.
Sie werden überrascht sein, was alles in ihnen steckt.
Grund genug also, ihnen einen eigenen Artikel zu widmen.
Übrigens: Wenn Sie es bevorzugen Story Points zu berechnen statt zu schätzen, dann können Sie sich hier unseren kostenlosen Story Point Kalkulator als Excel Template herunterladen. 🙂
Dein kostenloser Story Point Calculator
Lade dir jetzt den kostenlosen Story Point Calculator im Excel Template, inklusive Anleitung herunter.
Warum Story Points?
Zunächst mal das wozu. Wofür werden Story Points verwendet?
Story Points sind ein Hilfsmittel, um die Velocity von Teams zu bestimmen.
Velocity – auch schon wieder so ein komischer Begriff. Die Geschwindigkeit von Teams, so so. Wie schnell schafft es ein Team, einen bestimmten Scope zu implementieren? Das „wie schnell“ ist erst mal nicht so das Problem. Das sind wir gewohnt in Zeiteinheiten auszudrücken.
Aber was heißt schon Scope? Und wie sollte man diesen objektiv – also vergleichbar – messen?
Hier kommen die Story Points ins Spiel. Aber dazu gleich mehr. Wir bleiben noch einen Moment beim Zweck, nämlich der Bestimmung der Velocity eines Teams.
Wozu wollen wir überhaupt die Velocity bestimmen?
Wozu und wie, das sind hier die Fragen. Zunächst das wozu.
Alles für die Organisationen
Organisationen haben ein natürliches Interesse, den ökonomischen Impact aller ihrer Aktivitäten im Auge zu behalten. Wenn ein Projekt gestartet wird – idealerweise noch vorher – möchte eine Organisation ganz gerne wissen, was es kosten wird. Time-to-Market sei Dank, wissen sie in der Regel jedoch ziemlich genau wann das Projekt live gehen soll. Bei Kosten und detailliertem Scope existieren in der Regel nur vage Wunschvorstellungen.
Denn unglücklicherweise wird Scrum immer dann als Methodik gewählt, wenn – aus welchen Gründen auch immer (z.B. zu hohe Komplexität der Anforderungen, time-2-market Anforderungen) – eine hinreichende Spezifikation des zu erstellenden Gegenstandes nicht vorliegt, aber die Zeit drängt.
Nichts da also, worauf man jetzt eine valide Schätzung und ein schönes Projekt-Controlling mit hübschen Gantt-Chart und Meilensteinen nebst Ressourcenplanung usw. aufbauen könnte. Organisationen mögen das nicht.
Wenn man den Gegenstand schon nicht kennt, wäre es aber zumindest hilfreich zu wissen, welche Verarbeitungsgeschwindigkeit mein Team hat.
Oder metaphorisch: Wenn ich die Route zu meinem Ziel nicht kenne, wäre es zumindest hilfreich, die Geschwindigkeit des Autos zu kennen, mit dem ich gerade fahre. Ich weiß dann zwar immer noch nicht genau, wann ich ankomme, aber die einzelnen Streckenabschnitte die unmittelbar vor mir liegen, könnte ich schon mal planen. Ich tappe also nicht mehr völlig im Dunkeln und je mehr sich die Gesamtroute erhellt, desto genauer wird meine Planung.
Spätestens nach 20 bis 30 Prozent der Projektlaufzeit sollte sich dieser Umstand einstellen. Ca. 80 Prozent Sicherheit sollte man schon deutlich früher haben: am „Point of no Return“, aber das erörtern wir an einer anderen Stelle.
Den hier beschriebenen Zusammenhang hat die Autoren von SAFe sogar bewogen, normalisierte Story Points zu fordern. Auf diesen Punkt komme ich später noch zu sprechen. Jetzt klären wir überhaupt erst mal die Story Points und ihre Anwendung.
Alles für die Teams
Selbstverständlich haben auch Scrum Teams ein hohes Interesse daran zu wissen, ob sie als Team besser werden oder stagnieren, um dann in Retrospektiven geeignete Maßnahmen ergreifen zu können.
Auch das ist ein nicht zu unterschätzender Umstand, dem wir hier noch etwas Aufmerksamkeit schenken müssen. Denn ich habe jetzt öfter schon die Meinung gelesen, dass die Velocity von stabilen und erfahrenen Teams ohnehin nicht schwankt. Zuletzt auch gerade wieder bei den oben erwähnten Autoren von SAFe aber auch anderswo.
Ich weiß ja nicht in welcher Realität diese Leute so leben, die Realität der Organisationen die ich so berate (Deutsche Bank, Lufthansa, Conrad Electronics, Deutsche Bahn und andere) und auch die unserer eigenen Entwicklerteams war das nicht gerade. In dieser Realität gibt es Projektlaufzeiten von 9 Monaten bis 3 Jahren, dann gibt es neue Projekte mit neuen Teams.
In dieser Realität bestehen Teams nicht nur aus erfahrenen Senior- oder Leadentwicklern, sondern integrieren wenige Seniors mit mehreren Intermediate- und Juniorentwicklern und wir tun viel dafür, dass deren Velocity gerade nicht stabil bleibt.
Und in der Realität ist nicht schon immer alles da und fertig eingerichtet, sondern die Teams kämpfen um ihre CI- und Dev-Umgebungen, Tools und Frameworks. In der Realität müssen sich Entwicklungsteams ständig mit neuen Technologien und Technical Debts auseinandersetzten, sehen neue und manchmal unerfahrene PO‘s und Scrum Master, etc.
Velocity unter solchen Bedingungen ist eher fragil, denn stabil und es ist ein täglicher Kampf, sie hochzuhalten, wenigstens aber stabil oder ideal leicht steigend. Ein Selbstverständnis, welches man einfach mal so voraussetzen kann, ist es jedenfalls nicht.
Wenn das alles so stabil – und keinesfalls in Gefahr – wäre, bräuchte man die meisten Teile der Scrum Methodik übrigens auch gar nicht.
Wer also meint, Story Points wären nur dafür da, um ein Gefühl dafür zu bekommen, was in einen Scrum Sprint passt, um sich dann immer auf die gleiche Anzahl von Story Points zu committen, der könnte sich die Mühe sparen. Dafür gäbe es einen einfacheren Weg. Man könnte als PO das DevTeam vor oder im Planning einfach fragen: „Passen diese drei Stories in den Sprint oder kann ich noch eine mit hinzunehmen?“. Die Antwort wäre nicht weniger präzise.
Was sind Story Points?
Wenn wir nun also wissen, welche Rolle Story Points in Scrum oder SAFe spielen, dann wird es nun Zeit, sich an die Definition und Beschreibung zu machen.
Und die hat es leider in sich, auch wenn es auf den ersten Blick so gar nicht danach aussieht. Aber die Mühe wird sich lohnen.
Story Points sind ein Maß für die Komplexität einer Story. Diese in Beziehung gesetzt zum Implementierungsaufwand dieser Story ergibt die Velocity.
Soweit ganz einfach. Was aber genau ist die Komplexität einer Story und wie bestimme ich sie? Da wird die Sache kurz etwas schwieriger – um nicht zu sagen „komplexer“.
Wenn Sie „Komplexität“ googeln bekommen wir schon eine Reihe recht unterschiedlicher Definitionen, die ich hier aus naheliegenden Gründen nicht alle zitieren und diskutieren möchte. Zwei erschienen mir für unsere Zwecke hier kurz und sinnvoll:
„Die Anzahl von Elementen und Verbindungen zwischen ihnen innerhalb eines Systems“
oder
„Der Informationsgehalt von Daten“
Letztere könnte man streng philosophisch genommen wohl auch umgekehrt definieren. Denn Daten aggregieren sich zu Informationen und enthalten sie nicht, aber das ist eine andere, etwas spitzfindige Diskussion.
Wenn Teams nun aber die Komplexität einer Story schätzen, dann haben sie ganz natürlich und in Ermangelung anderer objektiver Kriterien lediglich den Aufwand im Kopf, den sie für die Implementierung brauchen. Dieser lässt sich leichter Bestimmen und ist auch irgendwie naheliegend.
Auch wenn das Verfahren nicht ganz falsch ist – wie ich später noch zeige – tappen die Teams damit in eine böse Falle.
Da der Aufwand individuell ist, überträgt sich automatisch diese Eigenschaft dann auch auf die Komplexität.
Und wenn wir zurück nach oben schauen, wozu Story Points verwendet werden – nämlich für die Velocity – dann wird die Falle schnell sichtbar: Es wird praktisch Zeit mit Zeit verglichen und das führt natürlich zu nichts.
Denn wenn die Velocity Komplexität in Beziehung zum Aufwand setzt, kann ich die Komplexität NICHT mit Aufwand beschreiben, weil ich sonst Aufwand mit Aufwand in Beziehung setze, also Zeit mit Zeit vergleiche.
Sehr ungünstig.
Zudem ist Komplexität eine Eigenschaft der Story. Aufwand wiederum deutet eher auf eine Eigenschaft des DevTeams.
So kommen wir aber nicht weiter. Die Situation ist verzwickt, denn es steht uns kein objetives Kriterium für die Bestimmung von Komplexität zur Verfügung. Jedenfalls keines, welches sich einigermaßen praktikabel und mit überschaubarem Aufwand aus einer Story ableiten ließe.
Die Lösung ist ein Workaround über die „Relativitätstheorie“. Das wiederum klingt kompliziert, ist aber einfacher. Und so gehts:
Wie werden Story Points berechnet?
Wir nehmen folgende Definition für Story Points an:
Story Points repräsentieren die Komplexität einer Story in Bezug zu ihrem Aufwand.
Sie sind damit weder ganz Komplexität (zu schwierig zu bestimmen), noch ganz Aufwand (wir wollen ja nicht Zeit mit Zeit vergleichen), sondern irgendwas dazwischen.
Wie berechne ich Story Points?
- Definition of Ready anpassen
Wir verwenden gerne die angepasste Fibonacci Folge, sagen wir mal in der Skala bis 20. In der Definition of Ready steht, dass alle Storys über 20 gesplittet werden müssen, also reichen uns die Zahlen bis 20. Macht die Sache ohnehin etwas einfacher.
- Erste Story als Benchmark setzen
Die erste Story bekommt 5 Story Points. Meinetwegen 8. Warum? Weil’s egal ist. Die erste Story dient nur als Benchmark.
- Storys im ersten Sprint vergleichen
Jede andere Story für diesen Sprint wird mit der ersten Story verglichen. Wir stellen uns die Frage: Ist diese Story aufwändiger zu implementieren oder nicht? Ja, in dieser Phase geht es noch rein um Aufwand. Sagen wir mal die zweite Story ist viel aufwändiger, also 13 Story Points. Macht für beide 18 Story Points. Soweit so gut.
- Implementierungsaufwand in Zeit bestimmen
In einer zweiten Planning-Phase bestimmen wir nun den tatsächlichen Implementierungsaufwand in Zeit, indem wir feingliedrige Subtasks erstellen und diese in Stunden schätzen. Das ist ein wirklicher technischer Workshop, in dem für diesen Sprint der konkrete Implementierungsplan erstellt wird. Nehmen wir mal an, für die erste Story waren das 2 Tage, für die zweite 5 Tage. Da beide Schätzungen unterschiedliche Skalen verwenden, ist die Ratio zwischen erster und zweiter Story in beiden Schätzungen natürlich nicht linear. Wir haben also 2 Storys mit 18 Story Points und insgesamt 7 Tagen Aufwand.
Strenggenommen kommt es nicht so sehr darauf an, ob Sie die tatsächliche Implementierungszeit im zweiten Teil des Plannings schätzen, oder nach dem Sprint pro Story feststellen. Letzteres wäre sogar objektiver. Aber Sie brauchen die Schätzung für ein valides Commitment sowieso und Sie müssten dann nicht während des Sprints die aufgewendete Zeit pro Story ganz genau tracken, sondern können sich mehr auf die Remaining Time konzentrieren. - Sprint starten
Mit diesen Werten gehen wir jetzt in den Sprint.
- Den Vorgang einige Sprints wiederholen
Im nächsten Sprint verfahren wir genauso, wobei immer mit der ersten Story des ersten Sprints verglichen wird. Im folgenden Sprint das Gleiche und wieder und wieder. Irgendwann landen wir mal im 5., 7., oder 10. Sprint. Es ist also Zeit vergangen. Zeit, die Teams genutzt haben, sich mit der Technologie vertraut zu machen, die Juniors zu schulen, sich besser kennenzulernen, Retrospektiven gehabt zu haben und Verbesserungen im Prozess vorgenommen haben, etc.
- Komplexität mit der allerersten Story vergleichen
Jetzt machen wir wieder das Gleiche. Wir nehmen die aktuelle Story jetzt im 5., 7., oder 10 Sprint und vergleichen diese mit der ersten Story des ersten Sprints. Aber wir stellen uns jetzt eine andere Frage: „Wenn wir damals im ersten Sprint – als wir noch jung und schön, ähh unerfahren waren – diese Story implementieren sollten, wie lange hätten wir gebraucht im Vergleich zur allerersten Story?“. Hier wirkt jetzt die Relativitätstheorie, denn wir haben uns mit der Zeit verändert, die Komplexität der Story aber nicht. Einzig brauchen wir für die Implementierung der Story heute weniger Zeit, als wir damals gebraucht haben, was die zweite Phase des Plannings, in der wir die konkrete Implementierungszeit schätzen, dann gleich zeigen wird. Die Story hat z.B. wieder 5 Story Points, denn damals wäre es der gleiche Aufwand gewesen. Aber heute brauchen wir keine 2 Tage mehr, sondern nur noch 1,5. Heißt, wir sind besser geworden, unsere Velocity ist gestiegen.
Dein kostenloser Story Point Calculator
Lade dir jetzt den kostenlosen Story Point Calculator im Excel Template, inklusive Anleitung herunter.
Fazit
Mein Gott, warum dieser Aufwand? Nun ja…
Das Besserwerden von Teams ist ein Grundprinzip von Scrum.
Denn Teams starten immer unter sehr schwierigen Bedingungen. Neues Team, keine Spezifikation, neues Thema, unerfahrener Product Owner, neue Technologie, es gibt so viele Gründe, alle ungemütlich.
Die Velocity ist am Anfang eines Projektes natürlich sehr niedrig. Das müssen die Teams möglichst schnell aufholen.
Die Stakeholder dürfen in dieser frühen Phase nicht zu schnell nervös werden und ins Micromanagement einschwenken (ein sehr verbreiteter Managementfehler).
Das Besserwerden muss also faktisch institutionalisiert werden. Und dafür brauchen wir zwei Dinge:
Ein Forum, das genau ist der Sinn der Sprint Retrospektive, das am meisten unterschätzte Meeting. Und einen Maßstab, der uns anzeigt, ob die Velocity steigt, sinkt oder konstant bleibt, damit wir in der Retrospektive geeignete Maßnahmen ergreifen können deren Effekt sich beobachten lässt: die Velocity, generiert aus den Story Points und in Beziehung gesetzt zum tatsächlichen Implementierungsaufwand.
Es ist nicht ganz trivial, aber doch die einzige Chance, einigermaßen genau zu bestimmen, wo das Team so steht.
Natürlich veranstalten wir den ganzen Zirkus nur deshalb, weil ein objektives Verfahren mit guten Kriterien zur Bestimmung der Komplexität nicht da ist. Mit so einem Verfahren wären allerdings Teams auch sofort miteinander vergleichbar.
SAFe möchte das gerne, daher auch die Forderung nach normalisierten Story Points. Scrum wollte das eigentlich nie. Beide haben gute und nachvollziehbare Gründe für ihre Position.
Alle, die sich schon mal mit „agile Contracting“ beschäftigt haben, werden die SAFe Position sicher verstehen. Scrum Puristen werden es aber nicht mögen, denn Competition ist kein guter Motivator.
Finden Sie ihre eigene Wahrheit.
Update: Inzwischen haben wir bei scagile ein Verfahren entwickeln, Story Points zu berechnen. Wenn Sie möchten, schauen Sie in diesem Artikel nach, wie das funktioniert:
