Story Points verständlich erklärt
Bei meiner Recherche im Internet und der gängigen Literatur habe ich gute Beispiele zur Vermittlung des Konzepts von Story Points gesucht.
Bis auf Mike Cohns Erläuterung in seinem Buch “Agile Estimation & Planning” habe ich wenig leicht verständliches gefunden. Auf die Gefahr hin, dass ich vielleicht einfach eine gute Quelle verpasst habe und das Rad nun neu erfinde, möchte ich meinen Beitrag zu dem Thema zu leisten, um Story Points nochmal auf den Punkt zu bringen:
Storypoints sind eine Einheit, die die Größe einer User Story beschreiben.
Wie ist nun diese Größe definiert? Diese Frage ist nicht pauschal zu beantworten. Es fließen viele Faktoren ein, die von den Individuen abhängen, die diese “Größe” definieren.
Ein Team könnte eine Größe zum Beispiel so definieren:
* Die Größe einer Story ergibt sich aus ihrer Komplexität. Die Komplexität hängt davon ab, ob und wieoft welche Schichten unseres Architekturmodells durchstoßen werden…
Ein anderes Team vielleicht so:
* Wie komplex sind die Interaktionen zur Umsetzung? Um diese Story umzusetzen müssen wir mehrere Abstimmungs- und Anpassungsrunden zwischen Designer, Interaction Designer und Frontend-Entwickler durchführen…
Wie auch immer ein Team diese Größe definiert, eines ist wichtig dabei: Es geht nicht um die Zeitdauer, die benötigt wird, um die Story umzusetzen, sondern um eine Eigenschaft der “Struktur” der User Story. Oder gleich um ein ganzes Bündel von diesen Eigenschaften.
Das ist ein wichtiger Unterschied. Das bedeutet, dass die wachsende Erfahrung eines Teams und schnellere Abarbeitung von Stories die Größe einer Story nicht verändert, denn die Eigenschaften der Story haben sich nicht geändert.
Ein erfahrenes Team schafft einfach mehr bzw. größere Stories in der selben Zeit als ein unerfahrenes Team, das beeinflusst die Größe nicht.
Was bedeutet das nun für Schätzungen:
Die Diskussionen darüber, wer eine Story umsetzt, sind nichtig. Ob erfahrener oder unerfahrener Entwickler: Es spielt keine Rolle für die Schätzung einer Story. Das unterstützt cross-funktionale Teams in ihrer Arbeit und macht Schätzungen leichter und schneller. Es müssen nur die Eigenschaften identifiziert werden und ein Vergleich mit schon bearbeiteten oder ähnlichen Stories angestrebt werden, dann hat man die Größe.
Wie kann man nun mit Story Points einen Releaseplan erstellen?
Der Zeitfaktor kommt in Scrum dann durch die Teamgeschwindigkeit in das System. Diese so genannte Velocity ist der Durchschnitt über die Summe aller vom Team erledigten Story Points pro Iteration, also:
V = ø (SUM(Story Points der erfolgreich abgeschlossenen Stories im Sprint))
Wenn ich jetzt für alle Product Backlog Items Story Point Werte schätze, sie in der Reihenfolge durch eine Form von Priorisierung sortiere und weiß, wieviele Storypoints mein Team je Iteration umsetzt (Velocity), kann ich die Aussage treffen, in welcher Iteration ich ein Feature liefern kann.
Während der Arbeit entstehen also gemessene Zeitwerte, die ich dann auf die Größe appliziere. Zeiten schätzen wird daher mit Story Points niemand mehr. Das ist eine gute Konsequenz, wenn man überlegt, wie schwer es ist, so etwas komplexes wie die Entwicklung von Softwarebausteinen durch Zerlegung zeitlich abzuschätzen. Es gibt ziemlich dicke Bücher über nur dieses Thema und eher weniger als mehr Projekte, die gute Schätzungen vorweisen können.
Kleinteilige Diskussionen vermeiden
Ein anderer Aspekt ist der, dass durch die Betrachtung der Charakteristika einer Story vermieden wird, zu tief in die für die Umsetzung notwendigen kleinteiligen Elemente hineinzugehen. Die Merkmale einer Story können auch ohne eine detaillierte Tätigkeitenanalyse identifiziert werden. Das ist bei Aufwandsschätzungen in Tagen häufig anders. Hier werden alle notwendigen Tätigkeiten identifiziert und deren Aufwände aufsummiert.
Einfacher in der Praxis
In der Praxis ist das Thema “Story Points” interessanterweise einfacher, als es tatsächlich zu erklären ist.
Nimmt man eine Referenzstory und einigt sich darauf, dass diese eine mittlere Größe hat, gibt das Team der Story zum Beispiel die Größe “5”. Andere Stories werden dann mit dieser verglichen und als gleich groß, kleiner oder größer eingestuft. Die Agilisten nehmen dann gerne die nach Mike Cohn angepasste Fibonacci-Reihe und verteilen die Elemente darauf: 1, 2, 3, 5, 8, 13, 20, 40, 100.
Die seltsame Skala dient unter anderem dazu, auszudrücken, dass um so komplexer die Story ist (also umso größer), die Genauigkeit der Schätzung in die Binsen geht.
De facto sollte man mit sehr großen Stories vorsichtig in der Releaseplanung sein, denn es herrscht hier eine hohe Unsicherheit in Bezug auf das korrekte Verständnis des Teams für dieses Story – aber das ist ein anderes Thema.
Update vom 05.03.2024: Mit meinen Kollegen von Agile Growth habe ich eine Podcast-Folge aufgenommen, die User Stories sehr anschaulich erklärt.
Zum Thema Referenzstory:
Wir haben bei HolidayCheck sehr gute Erfahrungen mit dem Team Estimation Game gemacht, was das Festlegen von Referenz-User Stories angeht.
Klarer Vorteil der Schätzmethode ist, dass die Entwickler keine Vorstellung von der Größe eines Story Points haben müssen und – wenn es richtig gespielt wird – die Stories wirklich relativ zueinander sind. Ausserdem hat man so für jeden Story Point Wert mindestens eine Referenz (mal abgesehen von 0, 0.5 oder 100).
Idealerweise stehen dabei beim ersten Schätzen User Stories in einem breiten Größenspektrum zur Verfügung. Dann ist eine 5 auch wirklich eine 5. 😉
Vielen Dank für das Teilen Deiner Erfahrung, Konstantin. Ich mag das Team Estimation Game auch gerne zur initialen Backlog-Schätzung.
“Es geht nicht um die Zeitdauer, die benötigt wird, um die Story umzusetzen, sondern um eine Eigenschaft der “Struktur” der User Story.”
Wie schätze ich dann den Aufwand, den mein Team wahrscheinlich haben wird, um eine bestimmte Story zu realisieren? (z.B. zur Angebotserstellung)
Letztendlich resultiert doch aus der Sprintdauer und der Anzahl der Teammitglieder eine Anzahl von PT, die benötigt wurden um eine gewisse Komplexität (Summe aller Story Points eines Sprints, bzw. Velocity) zu bewerkstelligen.
Beispiel: 3 Wochen Sprintdauer, 5 Teammitglieder, Velocity: 20 Story Points.
Das Team wird mit der aktuellen Velocity vier User Stories der Größe 5 realisieren können. D.h. eine dieser Stories wird ziemlich genau ein Viertel des Teamaufwands benötigen.
Umgerechnet auf PT ergibt aufgerundet:
15 Tage * 5 Personen / 20 * 5 = 19 PT
Ich sehe daher keinen wirklichen Unterschied zwischen der Größe einer Story und deren Aufwand in PT, wenn man eine gleichbleibende Velocity voraussetzt.
Ansonsten gefällt mir deine Zusammenfassung. Insbesondere die Warnung vor sehr großen Stories (die Grenze zu “sehr groß” wird jeder selbst finden müssen) deckt sich mit meiner Erfahrung: Regelmäßiges Grooming und Splitting von Stories führt zu kleineren, klarer abgegrenzten Stories und damit auch zu besseren Schätzungen.
Hallo Roman,
vielen Dank für Deinen Kommentar. Die Betonung des Unterschieds zwischen Größe und Zeitaufwand habe ich deswegen gewählt, weil ich bei manchen Kunden erlebt habe, dass das Denken in Manntagen eine oft seit Monaten und Jahren gepflegte Währung ist. Mit der Einführung von Story Points, hat man die Möglichkeit, hier ein Umdenken zu erreichen in Richtung “Teamgesamtleistung”.
In deinem Beitrag erkenne ich, dass diese Gesamtleistung respektiert und verwendet wird: In diesem Kontext kann man solch eine Berechnung, wie Du sie machst, als Angebotsgrundlage verwenden. Neue Erkenntnisse während der Berechnung, z.B. eine Vergrößerung des Arbeitsaufwands gehören dann ggf. zum einzupreisenden Risiko oder nivellieren sich eventuell durch Abweichungen in beide Richtungen.
Hallo
Vielen Dank für die gute Erklärung der Story Points. Ich finde es sehr einleuchtend, allerdings gibt es für mich bezüglich der Anwendung
1) Wir müssen für unsere Kunden vor Projektbegin eine Aufwansschätzung machen, daran führt meistens kein Weg dran vorbei. Wie kann ich eine Aufwandsschätzung machen ohne die Velocity zu kennen? Soll dann das Team auch die Velocity schätzen?
2) Man sagt in SCRUM sollten alle Teammitglieder 8h und 5 Tage in der Woche auf einem Projekt arbeiten. Die Realität sieht meistens anders aus und die Verfügbarkeit der Teammitglieder kann von Sprint zu Sprint variieren. Kann unter diesen Umständen überhaupt eine aussagekräftige Velocity des Teams gemessen werden?
Hallo Tobias,
klasse, dass der Artikel gefällt – zu den Fragen:
Zu 1) Solange nicht auch der Einkauf und Verträge agil gestaltet sind (mehr dazu z.B. im Buch “Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge“), gibt es verschiedene Strategien. Ich finde es sinnvoll, bei Schätzungen auf jeden Fall das Team einzubeziehen, denn die kollektive Intelligenz eines Teams weiß in der Regel mehr als ein Stellvertreter. Außerdem sollten Schätzwerte von den Mitarbeitern kommen, die es nachher umsetzen möchten.
In einer Schätzklausur kann der Product Owner das Projekt vorstellen, die Epics präsentieren und dann z.B. mit Planning Poker oder Magic Estimation gemeinsame Schätzwerte generiert werden. Ob man in Personentagen oder Story Points schätzt hängt dann von der Situation ab. Mit passenden Risiko / Sicherheitsaufschlägen ist es zwar nicht optimal agil aber ein Kompromiss, bis Kunden sich auf eine agile Vertragsgestaltung einlassen.
zu 2) Meiner Erfahrung nach bildet sich eine recht stabile Velocity heraus, wenn die Abwesenheiten der Teammitglieder sich im Mittel ausgleichen. Besondere Situationen kann man z.B. im Velocity Chart festhalten, um diese dann entsprechend bei einer Prognose anders zu werten. Um daraus dann eine tragfähige Release-Vorhersage zu machen, hat Mike Cohn etliche Tipps in seinem Buch “Agile Estimating and Planning (Robert C. Martin)“.
Viel Erfolg weiterhin auf dem Weg zur Agilität!
Hallo,
schöne Webseite! Ich möchte nur ein paar Ergänzungen machen. Die Story Points sind Verhältnisgrößen. Wenn also eine Story mit 5 Punkten 10 Tage dauern dann sollte eine Story mit 10 Punkten 20 Tage dauern. Dies muss so sein da man sonst keine Sprintplanung machen könnte. Wenn es nicht so wäre, dann wäre die Summe an Punkten von kleinen Stories mehr Aufwand als die gleiche Summe großer Stories. Also es geht darum zu sagen eine Story ist doppelt oder halb so große wie eine Referenz Story.
Zudem wird der Aufwand der Stories verglichen. Ob man über die Komplexität oder sonst einen Schnick Schnack die Werte schätzt ist egal. Eine doppelt so große Story, braucht doppelt soviel Zeit. Die Verhältnisgröße muss also analog der Zeit sein. Mit den Storypoints wird schließlich ein möglicher Releas Termin prognostiziert. Dies wäre nicht möglich wenn zum Beispiel eine verdoppelung der Story Point das 4-fache der Zeit bedeutete.
Ich hatte das Gefühl dies noch stärker heraus stellen zu müssen.
Grüße
Benjamin
Hallo Benjamin,
vielen Dank für Deinen Kommentar. Deinen Grundgedanken teile ich, dass Storypoints im Verhältnis zueinander stehen. Jedoch sind sie keine exakte Wissenschaft und um so ungenauer, je größer der Schätzwert ist. Eine Story mit 40 Story Points ist bei den meisten Teams zu groß, um überhaupt in einem Sprint umgesetzt zu werden. Insofern kann man in etwa sagen, dass statt einer 13er Story auch eine 5er und eine 8er Story umgesetzt werden kann. Bei größeren Werten wird diese Betrachtung immer ungenauer. Dies spiegelt ja auch die Verteilung als Fibonacci-Reihe wieder.
Den Faktor der Zeit, den Du ins Spiel bringst, verwende ich an dieser Stelle nicht, um nicht in die Denkweise einzusteigen, wieviele Personentage ein Storypoint sind – diese Betrachtung führt oft zu seltsamen Auswirkungen in der Qualität der Schätzung von Story Points, die ich nicht hilfreich finde.
Die Zeit kommt wie oben beschrieben erst in der Rückschau in die Gleichung durch die Durchschnittsgeschwindigkeit des Teams (namens Velocity). Ein exakt lineares Verhältnis zwischen Zeit und Story Points sehe ich nicht. Es ist eher eine Korrelation. Theoretisch kann man dann Story Points und Tage in ein Verhältnis bringen. Was wäre der Nutzen davon?
In puncto Releaseplanung bietet es sich an mit einem Korridor von Ungenauigkeiten zu arbeiten, also wie Mike Cohn es in Agile Estimating and Planning vorschlägt, sich an z.B. durchschnittlicher minimaler, normaler und maximaler Velocity zu orientieren und somit früheste und späteste Releaseende-Zeitpunkte zu ermitteln.
Interessante Posts und Meinungen.
Auch ich suche immer noch nach einer guten Auslegung (bzw. Definition), um Teams Story-Points zu erklären.
Meiner Meinung nach lassen sich mit Story-Points sehr gut die “Menge an Arbeit”, die zur Umsetzung einer Story erforderlich ist, beschreiben – natürlich immer in Relation zur Referenz-Story. Der Zeitfaktor bleibt auch bei dieser Definition erst einmal außen vor.
Haben wir bspw. eine Story mit 8 SP und eine Story mit 13 SP, so lässt sich grob sagen, dass für 13 SP ungefähr doppelt so viel Arbeit erforderlich ist, wie für 8 SP. Ob aber auch die Umsetzung ungefähr doppelt so lange dauert, ist hierdurch nicht gesagt, da sich bspw. einzelne Tasks im Team schlechter aufteilen lassen (z. B. Abhängigkeiten) oder weil gerade 3 Kollegen im Urlaub sind und nicht mitarbeiten können. Das ist auch ein Grund, warum im agilen Umfeld auf stabile Teamzusammensetzungen Wert gelegt wird. Variieren die Team-Mitglieder von Sprint zu Sprint, wird auch die Umsetzungsgeschwindigkeit stärker variieren, die Menge der Arbeit bleibt aber die Gleiche.
Zu einem gewissen Teil spielt aber auch “Komplexität” (Unsicherheit, Erfahrung des Teams oder Schwierigkeit der Umsetzung) eine Rolle. Wie im vorherigen Post beschrieben, steigt in der Regel mit der Größe einer Story auch die Komplexität bzw. die Abschätzbarkeit, was genau zu tun ist. Die Schätzung wird ungenauer.
Hi Kai,
Super Blog! Ich arbeite aktuell an meiner Masterarbeit zum Thema “Analysis Of User Stories And Effort Estimation In Agile Software Development” und beschäftige mich daher aktuell mit User Stories, Story points, Velocity, …
Zu diesem Absatz
“Das ist ein wichtiger Unterschied. Das bedeutet, dass die wachsende Erfahrung eines Teams und schnellere Abarbeitung von Stories die Größe einer Story nicht verändert, denn die Eigenschaften der Story haben sich nicht geändert.”
kommt mir ein Gedanke/eine Frage:
Szenario: Ich entwickle in einem kleinen Team eine Webseiten-Anwendung und habe zwei verschiedene User Stories, die du Umsetzung eines Formulars mit 2 Felder + Anhang fordern. User Story I ist in einem Epic, das zu Beginn der Projekts, umgesetzt werden soll & User Story II ist in einem Epic, welches relativ am Ende umgesetzt werden soll.
Zudem sind wir zu Beginn des Projektes noch nicht mit der neuen Technologie vertraut.
Wenn die Aussage von oben gilt und ‘es nicht um die Zeitdauer, die benötigt wird, um die Story umzusetzen, sondern um eine Eigenschaft der “Struktur” der User Story geht’, dann gehe ich davon aus dass die beiden User Stories gleich einzuordnen sind. So werden beispielsweise beide Stories mit 5 Story Points belegt.
Bei der Implementierung von US I braucht das Team nun 24 Stunden, da die Kenntnisse der neuen Technologie erst aufgearbeitet werden.
Gegen Ende des Projektes wird US II bearbeitet und auf Grund der gewonnenen Erfahrungen & des angeeigneten Wissens, fällt es dem Team nun viel leichter ein solches Formular umzusetzen. Daher braucht das Team dieses mal nur 4 Stunden.
Denkst du das ein solches komplexitätsbasiertes “Schätzen” der User Stories korrekt ist?
Wenn ja, wie erklärst du dann die Auswirkungen auf die Velocity? Das Team lernt dazu und schafft es so einige Stories schneller zu bearbeiten? Dadurch werden dann können mehr Stories & Story Points in den folgenden Sprints bearbeitet werden. Das heißt das die Velocity im Projektverlauf steigt…
Aber welche Auswirkungen hat eine solche steigende Velocity dann auf die Release/Projekt-Planung? Ist es dann noch möglich einen vernünftigen Zeitplan zu machen? Sowohl feature- als auch date-driven- Release-Planing basiert auf einer konstanten Velocity, richtig?
Grüße,
Rupert
Hallo Rupert,
Deine Auffassung in Bezug auf die Stabilität der Story Points ist prinzipiell richtig. Dennoch entscheiden sich manche Teams im Laufe des Projekts, ihr Schätzung manchmal zu aktualisieren, wenn sie dem Team nicht mehr konsistent erscheinen.
Das Team lernt also während des Projekts auch, besser mit den inhärenten Eigenschaften einer User Story umzugehen und somit ggf. später anders zu schätzen als zu Beginn. Das bedeutet eventuell sogar, dass ein großer Teil von Schätzwerten neu erzeugt wird mit einem effizienten Verfahren (wie Magic Estimation).
Releaseplanung ist ein kontinuierlicher Prozess. Der Kern dessen ist der andauernde Dialog mit dem Kunden. Ändert sich das Projektwissen über Technologie, Anforderungen oder Teamgeschwindigkeit fordert die Transparenz von Scrum, dies zu kommunizieren und mit der aktuellen Situation Entscheidungen für die Zukunft zu treffen. Der wiederholte Prozess der Planung ist wichtig, mehr als die Planung an sich. Softwareentwicklung ist nur sehr bedingt im Voraus planbar – deswegen brauchen wir Empirie – und die lebt vom Feedback seitens des Kunden.
Best Case und Worst Case Betrachtungen können dabei helfen, einen Umfang an Funktionen abzustecken, die der Kunde erwarten kann. Und dann ist der Product Owner gefragt, den Dialog aufrechtzuerhalten – und Änderungen seitens des Kunden und Erfahrungswerte des Teams einzupflegen.
Gruß
Kai