Wie Du mit Story Points Deinen Sprint planst

30.09.2020

Scrum-Teams stehen bei jeder Sprint-Planung vor der Herausforderung, den Enwicklungsaufwand der umzusetzenden User Stories im Voraus abzuschätzen. In diesem Post zeigen wir Dir, wie Story Points dabei helfen können und was es bei Schätzungen mit Story Points zu beachten gibt.

Warum sollte der Aufwand von User Stories überhaupt geschätzt werden?

Für die Priorisierung des Backlogs ist der Product Owner verantwortlich, allerdings kann er den für die Umsetzung der einzelnen User Stories nötigen Aufwand meist nicht selbst einschätzen, da hierfür oft das technische Wissen fehlt. Deshalb schätzen die Entwickler im Team gemeinsam den Aufwand und helfen der Product Ownerin oder dem Product Owner dadurch, ein besseres Verständnis für die User Stories zu entwickeln und ggf. Unklarheiten zu beseitigen. Zum Beispiel kann sich durch eine gemeinsame Schätzung herausstellen, dass eine User Story zu groß ist und besser in kleinere User Stories aufgeteilt werden sollte oder dass die Akzeptanzkriterien genauer formuliert werden müssen.

Im Wesentlichen werden mit diesem Vorgehen zwei Ziele verfolgt:

Das Team findet heraus, wie viel Arbeit es in einem Sprint schaffen kann. Die Menge der Arbeit, die ein Team pro Sprint erledigen kann, wird auch “Velocity” genannt und zeichnet sich bereits nach wenigen Sprints ab.
Ein Backlog, in dem ausreichend viele User Stories geschätzt wurden, ermöglicht eine langfristige Planung über mehrere Sprints hinweg, z. B. für die Release-Planung.

Es ist dabei aber für alle Beteiligten – auch die Kunden – wichtig zu beachten, dass Schätzungen immer mit Unsicherheit verbunden sind.

Was sind Story Points?

Aber wie genau wird nun der Aufwand von User Stories geschätzt? Jeder User Story wird ein Wert einer vorher festgelegten Skala zugewiesen. Die sogenannte “modifizierte Fibonacci-Sequenz” wird dafür am häufigsten eingesetzt und besteht aus den Story Points 0, 1, 2, 3, 5, 8, 13, 20, 40 und 100. Manche Teams nutzen aber auch andere abstrakte Skalen, z. B. T-Shirt-Größen (S, M, L, XL, usw.) oder Tiere (Ameise, Maus, Katze, Löwe, Elefant, Blauwal).

An dieser Stelle ist es wichtig zu betonen, dass Story Points nicht den für die Umsetzung nötigen Zeitaufwand widerspiegeln. Es wird also nicht in Stunden geschätzt! Stattdessen fließen verschiedene Faktoren in die Schätzung ein: Größe, Komplexität, Risiko und Unsicherheit. Zum Beispiel kann ein großes neues Feature, das noch nicht ganz klar definiert ist, unvorhergesene (technische) Schwierigkeiten bei der Umsetzung verursachen, weshalb das Team eine solche User Story eher mit einem hohen Story-Point-Wert bewerten würde.

Als Faustregel kann man festhalten: Je kleiner die User Story, desto geringer die Komplexität und das Risiko bzw. die Unsicherheit. Diese Idee zeigt sich auch in der modifizierten Fibonacci-Sequenz. Im unteren Bereich sind die Abstände zwischen den Werten gering, was feinere Abstufungen in den Schätzungen ermöglicht. Im oberen Bereich kann hingegen nur grob geschätzt werden, da Feinheiten bei großen und komplexen User Stories nicht so sehr ins Gewicht fallen.

Deshalb ist es sinnvoll, dass nur solche User Stories in einen Sprint aufgenommen werden, die sich im unteren Bereich befinden. Ist eine User Story hingegen mit beispielsweise 40 Story Points bewertet, ist das ein Hinweis für den Product Owner, dass die User Story zu komplex ist und daher aufgeteilt und anschließend neu bewertet werden sollte.

Einer der Vorteile von Story Points ist, dass im Vergleich zu genauen Schätzungen in Arbeitsstunden Detailsdiskussionen vermieden werden, die die Planung unnötig in die Länge ziehen würden. Story Points “Pi mal Daumen” zu schätzen geht schneller und ist für den Zweck der Sprint-Planung völlig ausreichend. Außerdem können Faktoren wie Unsicherheit nicht gut in Stunden ausgedrückt werden.

Story Points haben aber noch eine weitere wichtige Eigenschaft: Sie sind innerhalb des Teams vergleichbar, aber in ihrer genauen Bedeutung individuell für jedes Team. Das bedeutet, dass eine User Story, die z. B. mit zwei Story Points bewertet wurde in etwa doppelt so aufwändig sein sollte wie eine User Story mit einem Story Point. Wie viel Aufwand in Stunden am Ende tatsächlich benötigt wird, ist aber von Team zu Team unterschiedlich. Man sagt deshalb auch, dass Story Points ein “relatives Maß” sind.

Wie läuft eine Story-Point-Schätzung in der Praxis ab?

In der Praxis wird meistens “Planning Poker” gespielt um Story Points für User Stories zu ermitteln. Im Refinement- oder Sprint-Planning-Meeting erhält dafür jedes Mitglied des Entwicklerteams einen Stapel von Karten mit aufgedruckten Story Points. Jedes Mitglied wählt verdeckt eine dieser Karten, je nach geschätztem Aufwand der User Story. Wenn jedes Teammitglied eine Karte gewählt hat, decken alle gleichzeitig ihre Karten auf und können sofort Übereinstimmungen oder Unterschiede in den Einschätzungen sehen und gemeinsam diskutieren. Anschließend einigt sich das Team auf einen Story-Point-Wert und fährt mit der nächsten User Story fort.

Da Story Points ein relatives Maß sind, kann es vor allem am Anfang hilfreich sein, während einer Runde Planning Poker ein paar zuvor geschätzte User Stories (z. B. aus dem letzten Sprint) als Vergleich heranzuziehen.

Aber wie starten, wenn es keine Referenzen zum vergleichen gibt, z. B. in einem neuen Projekt oder wenn bisher keine Story Points genutzt wurden? Eine einfache Möglichkeit loszulegen funktioniert wie folgt: Wähle eine gut ausgearbeitete User Story aus, die Dein Team als gut umsetzbar einschätzt und weise ihr einen Wert aus dem unteren Bereich der Story-Point-Skala, z. B eine Drei oder eine Fünf, zu. Wir haben ja bereits gesehen, dass im unteren Bereich der Fibonacci-Skala kleinere Abstufungen und damit genauere Schätzungen möglich sind und niedrige Werte eine geringere Unsicherheit repräsentieren. Solche User Stories sind also gute Kandidaten für den nächsten Sprint. Erfahrungsgemäß entwickeln Teams sehr schnell ein Gefühl dafür, wie User Stories einzuschätzen sind. Daher gilt: Auch wenn es am Anfang noch ungewohnt scheint, lasst Euch einfach darauf ein und Du wirst sehen, wie Dein Team schon nach kurzer Zeit ein gemeinsames Gefühl für die Schätzung entwickelt.

Wir hoffen, dieser Post hilft Dir dabei, Deine Sprints mithilfe von Story Points besser und effizienter zu planen.

Referenzen

Mike Cohn. Agile Estimating and Planning. Upper Saddle River, NJ, USA: Prentice Hall, Nov. 2005.

Stephanie Porschen-Hueck, Marc Jungtäubl, Margit Weihrich. Agilität?: Herausforderungen neuer Konzepte der Selbstorganisation. Rainer Hampp Verlag: Apr. 2020.