Story Points sind eine beliebte Methode in Scrum Teams, um den Aufwand einer User Story einzuschätzen. Wie viele Techniken und Methoden sind auch Story Points lediglich eine weit verbreitete Praktik und keine Vorgabe aus dem Scrum Guide. Falls sich Dein Team also dazu entscheiden sollte, seine Aufwände anders als mit Story Points zu schätzen (oder vielleicht auch gar nicht), ist auch das vollkommen in Ordnung.
Da es dabei immer wieder zu Diskussionen kommt, habe ich hier einmal alles Wissenswerte zu Story Points für Dich festgehalten. Ich hoffe, es hilft Dir und Deinem Team dabei, sich die eine oder andere Herausforderung zu ersparen.
Warum gibt es überhaupt Story Points?
Im klassischen Projektgeschäft steht das Abarbeiten konkreter Aufgaben durch einzelne Entwickler im Vordergrund. Ein Auftraggeber bucht bei einem Dienstleister Zeit, die dann in die Entwicklung von Software investiert wird. Deshalb werden im Rahmen eines Projektes auch häufig Personentage verkauft. Man gibt sich der Illusion hin, dass man einzelne Personentage einfach zusammenrechnen kann, etwas Puffer aufaddiert und man so abschätzen kann, zu welchem Zeitpunkt man mit dem Projekt fertig sein wird.
Wenn Projekte mit Scrum umgesetzt werden, stimmen die meisten Grundannahmen hinter diesem Vorgehen nicht mehr.
Personentag ist nicht gleich Personentag
Zunächst einmal ist eine Aufwandsschätzung in Personentagen ungenau. Denn abgesehen davon, dass in einem Scrum Team ein Entwickler nicht mehr alleine an einer Aufgabe arbeitet, gibt es natürlich auch Unterschiede in den Fähigkeiten der Entwickler. Ein erfahrener Softwareentwickler benötigt für eine neue Funktion weniger Zeit als ein dualer Student oder Azubi.
Personentage geben nicht an, wann eine Aufgabe fertig sein wird
Zweitens sind Personentage hinsichtlich einer anstehenden Deadline im Grunde vollkommen irrelevant. Wenn Du selbst Kunde bei einem Dienstleister bist, interessiert Dich nicht, wieviel Aufwand Dein Auftragnehmer dabei hatte, ein Feature zu entwickeln, sondern wie lange es dauert, bis Du es nutzen kannst. Die Aufwandsschätzung in Personentagen gaukelt uns aber vor, man könne damit beides errechnen. Dem ist aber nicht so.
Stell Dir vor, Du möchtest ein Feature entwickeln lassen und Dein Dienstleister sagt Dir, dass der dazu nötige Aufwand 2 Personentage beträgt. Dann gehst Du auf Basis von Personentagen davon aus, dass Dein Feature übermorgen fertig ist. Das mag zutreffen, wenn sich sofort am gleichen Tag ein Entwickler an die Umsetzung Deines Features macht und gleichzeitig nichts anderes zu tun hat. Der Realität entspricht das jedoch nicht. Vielmehr wird es so sein, dass er morgen die ersten vier Stunden investiert und Dein Feature dann eine Woche liegen bleibt, bevor er weitermacht. Am Ende hat der Entwickler vielleicht sogar genau 2 Personentage benötigt, aber die Entwicklung Deines Features hat insgesamt drei Wochen gedauert.
Scrum kennt nur das Team als kleinste Größe
Die kleinste Einheit, die Scrum kennt, ist das Scrum Team und nicht mehr der einzelne Entwickler. Anstehende Aufgaben oder ganze User Stories werden nicht (mehr) durch einen einzelnen Entwickler umgesetzt, sondern kollaborativ. Der Hintergrund hierbei ist natürlich, dass die Aufgaben eines Scrum Team komplex sind und ein Mensch alleine nicht mehr den genauen Überblick darüber hat, was alles zur Umsetzung einer User Story gehört. (Nein, auch ein Super-Projektmanager kann das nicht.)
Es daher ziemlich sinnfrei, Aufwände in Stunden oder Personentagen zu schätzen, wenn ohnehin nur das gesamte Team dazu in der Lage sein wird, ein Feature umzusetzen.
Scrum Teams arbeiten mit Sprintzielen
Ein weiterer Grund aus dem Personentage für die Aufwandsschätzung in agilen Teams keinen Sinn (mehr) ergeben, ist der gemeinsame Fokus auf ein Sprintziel. Für Scrum Teams steht im Vordergrund, bis zum Ende des nächsten Sprints ein nutzbares Inkrement zu liefern oder eine neue Funktion zur Verfügung zu stellen. Wer innerhalb des Teams wieviel Zeit für diese oder jene Aufgabe benötigt ist aus dieser Perspektive betrachtet irrelevant.
Es kann sogar häufig der Fall eintreten, dass ein Sprintziel auch erreicht wird, wenn einige User Stories sich im Verlaufe einer Iteration als irrelevant herausgestellt haben und gar nicht erledigt werden müssen.
Menschen können schlecht in absoluten Maßstäben schätzen
Der jedoch wichtigste Grund, Story Points zur Schätzung von Aufwand zu nutzen, ist: Wir Menschen sind einfach total schlecht darin, in absoluten Einheiten zu schätzen. Und das unabhängig davon, ob es Zeit, Gewicht oder Längenmaße sind. Story Points umgehen dieses Problem, indem sie die Möglichkeit einer relationalen Schätzung bieten.
Wie funktionieren Story Points?
Um den Aufwand an Arbeit abzuschätzen ist es allerdings gar nicht notwendig, in absoluten Einheiten zu schätzen. Es reicht vollkommen aus, wenn wir abschätzen können, ob eine bestimmte Aufgabe größer oder kleiner ist als eine andere Aufgabe.
Hier rechts siehst Du ein Beispiel zur Funktionsweise von Story Points. Wir können zwar nicht genau sagen, wie viele Quadratzentimeter jedes einzelne Viereck hat, aber wir können relativ leicht sagen, dass die Fläche des zweiten Quadrats in der Reihe doppelt so groß ist wie die Fläche des ersten. Und dass das Quadrat ganz rechts auf dem Bild ungefähr 5x so groß ist wie das Quadrat ganz links.
Dieses Verhältnis zueinander lässt sich dann simpel mit Story Points abbilden. Heißt also: Wenn wir dem linken Quadrat in der Reihe 1 Story Punkt zuordnen, vergeben wir für das zweite 2 Punkte, 3 Story Points für das dritte Quadrat und für das letzte 5 Story Points.
Die (angepasste) Fibonacci-Folge
Hier kommt noch ein weiterer Punkt ins Spiel. Denn wir können vielleicht noch die Quadrate 1,2 und 3 gut auseinanderhalten, aber je größer die Quadrate werden, desto schwieriger wird es, Schätzungen abzugeben. Außerdem kommt hinzu, dass die Größenunterschiede immer unwichtiger werden, je größer eine Aufgabe wird, die wir mit Story Points schätzen. Was soll beispielsweise der Unterschied zwischen 100 und 101 sein?
Deshalb hat es sich bei den meisten Scrum Teams eingebürgert, eine angepasste Fibonacci-Folge für die Schätzung mit Story Points zu nutzen:
1, 2, 3, 5, 13, 20, 40 und 100
Der immer größer werdende Zahlenraum ist für Scrum Teams ein guter Indikator dafür, dass es unnötig viel Komplexität und Risiko eingeht, wenn es eine derart große User Stories in seinem Sprint umsetzen möchte.
Pro-Tipp: Behandle die Fibonacci-Folge wie Wassereimer
Häufig sind Teams die Abstände zwischen 20, 40 und 100 Story Points zu groß. Nicht selten entsteht dann der Wunsch, 25, 65 oder 75 Story Points mit in die Schätzung aufzunehmen. Grundsätzlich ist das natürlich möglich. Aber die größeren Einheiten haben vor allem den Vorteil , ein Team dazu zu animieren, größere User Stories in kleinere zu zerteilen und damit – auch wenn es in einem Sprint mal knapp wird – trotzdem etwas Nutzbares abzuliefern. (Wenn ein Team drei von vier User Stories abschließt, ist das immer besser als eine große User Story, die nicht fertig wurde und keinen Nutzen stiftet.)
Deshalb solltet Ihr die Fibonacci-Zahlen wie Wassereimer behandeln: 6 Liter Wasser passen auch nicht in einen 5l-Eimer, sondern eben nur in einen 8-Liter-Wassereimer.
Was schätzt man mit Story Points eigentlich?
In vielen Scrum Teams herrscht immer wieder eine rege Diskussion darüber, ob mit Story Points Aufwand oder Komplexität geschätzt wird. (Selbst Tim Themann vertritt in seinem aktuellen Beitrag die Ansicht, es sei ausschließlich Komplexität.) Grundsätzlich ist es nicht falsch, Komplexität bei der Vergabe von Story Points zu berücksichtigen. Dazu musst Du Dir aber Folgendes verdeutlichen: Komplexität kann für die Vergabe von Story Points relevant sein, muss sie aber nicht.
Denn Komplexität ist für Story Points immer dann irrelevant, wenn sie keinen Einfluss auf den Aufwand einer User Story hat. Umgekehrt kann eine Aufgabe sehr einfach (also wenig komplex) sein, aber gleichzeitig riesigen Aufwand verursachen.
Das Ganze wird relativ schnell offensichtlich, wenn wir eine andere Metrik näher betrachten, die eng mit Story Points zusammenhängt: die sogenannte Velocity.
Velocity & Story Points
Wie der Name schon besagt, geht es bei Velocity um Geschwindigkeit. Sie gibt uns einen Maßstab an die Hand, mit dem wir zwei Dinge besser einschätzen können: Zum einen wissen wir durch Velocity (relativ) gut, wie viele User Stories wir innerhalb eines Sprints umsetzen können. Und zum anderen wissen wir (relativ) genau, wie lange es dauern wird, alle User Stories aus unserem Product Backlog umzusetzen.
Stell Dir ein Product Backlog vor, für dessen User Stories wir insgesamt 220 Story Points vergeben haben und dessen Scrum Team eine durchschnittliche (historische) Velocity von 20 Punkten hat. Beim aktuellen Stand gehen wir deshalb davon aus, dass es 11 Sprints dauern wird, bis alle User Stories umgesetzt sind. Außerdem wissen wir, dass wir pro Sprint ungefähr 20 Story Points umsetzen können. Das können 20 User Stories mit 1 Story Point sein oder 1 User Story mit 20 Story Points. (Oder ein beliebiger Mix aus User Stories mit unterschiedlichen Story Points.)
Velocity funktioniert daher genauso wie die Geschwindigkeitsangabe km/h. Nur sind es bei der Velocity eines Scrum Teams eben keine km/h, sondern Story Points/Sprint.
Wann Komplexität relevant ist (und wann nicht)
Wir können uns sehr leicht Aufgaben vorstellen, die zwar nicht sonderlich komplex sind, aber sehr (zeit-)aufwändig. Umgekehrt gibt es Aufgaben, die sehr komplex sind, aber nicht aufwändig. Und es gibt natürlich auch Aufgaben, die komplex und und aufwändig sind.
Beispiel 1 – Nicht-komplexe, aber aufwändige Aufgaben
Stell Dir vor, Deine Aufgabe ist es, jedem Mitarbeiter Deines Unternehmens die Post an den Schreibtisch zu bringen. Jeden Morgen erhältst Du eine Tasche mit Briefen und Päckchen, die bereits anhand eines festen Laufplans vorsortiert wurden. Das ist eine ziemlich einfache Aufgabe: Du folgst einfach Deiner Route und legst jedem Kollegen die Post auf den Schreibtisch. Trotzdem ist das sehr aufwändig, denn Dein Unternehmen hat insgesamt 500 Mitarbeiter.
Würdest Du bei der Vergabe von Story Points nun lediglich Komplexität zugrunde legen, würde diese Aufgabe in Deiner Planung relativ gering bewertet werden.
Beispiel 2 – Komplexe, aber nicht aufwändige Aufgaben
Jetzt stell Dir vor, bei der Verteilung der Post wäre es wichtig, dass jeder Brief, jedes Paket und jedes Päckchen persönlich an den Empfänger übergeben wird. Noch dazu arbeiten alle Deine Kollegen in einem Großraumbüro, das keine festen Sitzplätze hat. Eine Vorsortierung Deiner Post ist also nicht mehr möglich, denn jeder Kollege sitzt jeden Tag an einem anderen Schreibtisch.
Allerdings kannst Du von (fast) jeder Position im Büro sehr gut sehen, wo jemand am heutigen Tag sitzt und arbeitet. Außerdem hat Dein Unternehmen nicht 500 Mitarbeiter, sondern lediglich 20. Wenn Du jetzt Deine Post verteilst, ist Deine Aufgabe zwar deutlich komplexer als im ersten Beispiel, aber der Aufwand sie zu bewältigen, ist viel geringer.
Würdest Du Story Points ausschließlich nach Komplexität vergeben, bekäme diese Aufgabe aber mehr Story Points als die Aufgabe aus Beispiel 1.
Beispiel 3 – Komplexe und aufwändige Aufgaben
Selbstverständlich ist es auch denkbar, dass die Komplexität einer Aufgabe auch ihren Aufwand beeinflusst. Leg einfach die gleiche Situation wie in Beispiel 2 zugrunde und stell Dir zusätzlich vor, dass in Deinem Großraumbüro Schallwände zwischen den Schreibtischen aufgestellt wurden, die Deine Sicht einschränken. Jetzt kannst Du nicht mehr alle Plätze im Büro gut einsehen. (Wenn Du magst, kannst Du auch zusätzlich die Anzahl Deiner Kollegen wieder von 20 auf 500 erhöhen.)
Durch die eingeschränkte Sicht ist Deine Aufgabe nun komplex und aufwändig. Du würdest bei der Planung von Aufgabe 3 mehr Story Points vergeben als für Aufgabe 2. Allerdings nicht allein deshalb, weil sie komplexer als Aufgabe 2 ist, sondern weil diese höhere Komplexität Einfluss auf den Aufwand der Aufgabe hat.
Unsicherheit und Risiken
Neben der Komplexität können auch noch andere Faktoren den Aufwand einer Aufgabe beeinflussen. Nimm noch einmal das erste Beispiel, von dem wir gesprochen haben. Du verteilst Post an Deine 500 Kollegen anhand einer festgelegten Route. Allerdings ist die Sortiermaschine, die die Post für Dich vorsortiert, nicht sonderlich zuverlässig. Wenn Empfängeradressen nicht sonderlich leserlich beschriftet sind, macht sie gerne Fehler bei der Sortierung. Dann tritt für Dich der Fall ein, dass Du plötzlich einen Brief für einen Kollegen in den Händen hältst, bei dem Du schon warst. Du musst also noch einmal zurückgehen.
Deine Aufgabe wird dadurch nicht komplexer, aber der Aufwand, sie zu erledigen, steigt durch Unsicherheiten und Risiken im Prozess. Auch hier würde man so einer Aufgabe in der Planung mehr Story Points geben als der Aufgabe aus Beispiel 1.
Story Points messen Aufwand
Story Points messen also den Aufwand einer User Story, der durch Größe der Aufgabe, Komplexität und Unsicherheiten & Risiken entsteht.
Wann und wie werden Story Points geschätzt?
In agil arbeitenden Scrum Teams ist das Schätzen von User Stories, Features und Epics Teil des Product Backlog Refinements. Für das Schätzen selbst gibt es zwei weit verbreitete Methoden.
Planning Poker
Magic Estimation
Fazit
Ich hoffe, mein Artikel hat Dir dabei geholfen, die Funktionsweise von Story Points besser zu verstehen und sie nun (noch) erfolgreicher in Deinem Team einzusetzen. Sollten noch Fragen offen geblieben sein, schreib mir doch gerne einen Kommentar unten auf der Seite!
