Führt man bei einem Team das Schätzen in Story Points ein, kommen oft Diskussionen in gang wie: Was ist Komplexität? Was bringt uns das Schätzen? Warum schätzen wir in Story Points und nicht gleich in Zeit? Dieser Artikel bietet einen Überblick warum wir in Story Points schätzen und was die Vorteile dessen sind.

Was sind Story Points?
Story Points sind eine abstrakte Einheit, welche die Größe einer User Story beschreiben.

Was ist nun diese Größe von Story Points?
Es geht bei der Größe nicht um die benötigte Zeitdauer zur Umsetzung der Story, sondern um die Eigenschaft der „Struktur“ der User Story – also ihrer Komplexität.

Jedes Team kann Komplexität anders definieren. Komplexität kann zum Beispiel bedeuten ob und wie oft welche Schichten unseres Architekturmodells durchstoßen werden.

Das heißt, dass die wachsende Erfahrung eines Teams und die daraus resultierende schnellere Abarbeitung einer Story keinen Einfluss auf deren Größe hat, da die Eigenschaften der Story sich dadurch nicht verändern. Dadurch steigern erfahrenere Teams mit der Zeit ihre Velocity.

Was bedeutet der Begriff Velocity?
Unter dem Begriff Velocity versteht man innerhalb von Scrum die Geschwindigkeit, die ein Scrum Team im Verlauf eines Sprints erreicht.
Diese Velocity ist der Durchschnitt über die Summe aller vom Team erledigten Story Points pro Iteration.

Was bedeutet der Begriff Geschwindigkeit?
Im englischen wird, anders als im deutschen, der Begriff Geschwindigkeit in speed und velocity unterschieden. Machen wir nun eine kleine Exkursion in die Physik, ist der Unterschied einfach zu erklären:

speed ist der Betrag der Geschwindigkeit, also eine skalare Größe.
velocity gibt zusätzlich die Richtung an, ist also eine vektorielle Größe.

Das „Richtige“ entwickeln
Was bedeutet das für die Software-Entwicklung und die Schätzung in Story Points?
Ein Team, das nur aus schnellen Entwicklern besteht resultiert vielleicht in einer hohen Geschwindigkeit – speed – aber nicht unbedingt einer hohen velocity. Betrachten wir nun zusätzlich die Richtung, haben wir nur dann eine hohe Velocity,
wenn wir auch das Richtige entwickeln. Damit wir das Richtige entwickeln, müssen wir bei der Planung Diskussionen generieren in denen das Verständnis und die inhaltliche Richtigkeit der User Stories hinterfragt werden. Dies gelingt, indem wir für die Schätzung der User Story eine abstrakte Größe verwenden. Denn kommen beim Schätzen stark abweichende Werte heraus, existiert im Team vielleicht noch kein einheitliches Verständnis über das betreffende Feature in welche Richtung die Umsetzung erfolgen sollte.

Warum tun wir uns so schwer diese Diskussionen zu generieren, wenn wir in Zeiten schätzen?
Hierzu ein kleines Beispiel:
Du, als guter Jogger, benötigst du für eine bestimmte Strecke 30 Minuten. Als schlechterer Läufer benötige für die gleich Strecke 60 Minuten. Wir diskutieren am Ende über 30 – 60 – 30. Das bringt uns nicht weiter. Ein Kompromiss wären 45 Minuten. Wir hätten am Ende aber gerne eine Schätzung die uns beiden dient. Wir könnten auch weiter argumentieren, anstatt einen Kompromiss zu schließen. Das Problem ist jedoch, dass wir beide recht haben. Du benötigst 30 Minuten ich aber 60 Minuten. Wenn wir versuchen mit Zeiten zu schätzen werden wir keine Lösung finden, da wir mit unterschiedlichen Geschwindigkeiten laufen (arbeiten).
Wenn wir aber eine abstraktere Messmethode verwenden, werden wir uns schnell einig, dass der Weg 5 km lang ist. Wir sind uns nur nicht einig, wie lange wir dafür benötigen.

Wie die Läufer können sich Entwickler über 5 Story Points einig werden.
Die schnellen Entwickler denken „das schaffe ich an einem Tag“. Die langsameren denken „dafür benötige ich zwei Tage“. Aber sie sind sich einig, dass der Aufwand für die User Story 5 Story Points beträgt.

Des Weiteren können wir einfach feststellen, dass die neue User Story doppelt so lange dauert wie eine bereits abgearbeitete User Story mit einem Story Point. Das heißt wir werden die neue Story mit zwei Punkten schätzen. Dennoch denkt der eine es sind 5 Stunden Arbeit wogegen der andere von 10 Stunden Arbeit ausgeht. Story Points sind sicher eine Zeiteinheit (Aufwand), aber die Anzahl der Zeit pro Story Point unterscheidet sich je nach Teammitglied.

Zudem ist das Schätzen nachweislich genauer, wenn wir in Relation zueinander schätzen (größer / kleiner / gleich). Am einfachsten funktioniert das Schätzen der Größe, wenn man die PBIs in Größenkategorien einteilt.
Das können genauso T-Shirt Größen wie S, M und L sein. Es geht also nicht darum, einen genauen Wert zu erhalten, sondern nur eine Kategorie. Die Nutzung der Velocity zur Prognose kompensiert die Ungenauigkeiten relativ gut.
Alles andere wäre Scheingenauigkeit.

Würden wir nun Story Points mit Zeit gleichsetzen, nähmen wir dem Team die Möglichkeit auf diese Weise zu schätzen.
Würde also jemand das Team beispielsweise instruieren, dass 1 Story Point 8 Stunden entspricht, ginge der Vorteil der abstrakten Schätzung verloren.

Bis jetzt wurde nur erläutert welche Vorteile es für das Entwicklungsteam hat mit einer abstrakten Größe zu schätzen.

Aber auch für den Product Owner ist die Größe der Velocity relevant.
Beispielsweite um Release-Planungen erstellen zu können. Hier könnte beispielsweise die Frage auftauchen ob eine identische Anzahl an Story Points stets die gleichen Kosten (Zeit) verursacht.

Hierzu ein kleines Rechenbeispiel:
Würde ein Team bei einem 20 Arbeitstage andauernden Sprint (4 Wochen) mit einer durchschnittlichen Velocity von 50 Points arbeiten, bekäme man
(50 Points / 20 Tag = 5/2 =) 2,5 Story Points pro Tag. Daraus ließe sich umgekehrt errechnen, dass das Team für ein Projekt mit einem Umfang von 450 Points etwa (450/2,5 =) 180 Arbeitstage brauchen würde, also etwa 9 Monate.

Rein rechnerisch ist das nachvollziehbar. Aber wie verlässlich ist diese Prognose in der Praxis?

Betrachten wir das oben Gesagte, liegt die Antwort auf der Hand:
Mehr oder weniger verlässlich. Denn trotz Scrum ist auch die Velocity nur eine Planzahl, die sich aus einem Mittelwert (Median) der bisherigen Sprints errechnet.

Wir behaupten jedoch auch, dass mit ansteigender Anzahl an Sprints, die für die Berechnung der durchschnittlichen Velocity verwendet werden, die Genauigkeit der Zeit (Kosten) die pro Story Point angesetzt werden kann zunimmt.
Möchte man eine größere Release-Planung, zum Beispiel für die nächsten 9 Monate, ist dies das bestmögliche Vorgehen, das im Moment bekannt ist.
Es gilt zu berücksichtigen, dass die Releaseplanung immer zyklisch anzupassen ist.
Scrum bietet durch seine „kurzen“ Iterationen eine gute Möglichkeit dazu.

  • Die Verlässlichkeit der Velocity wird unter anderem durch die folgenden Faktoren beschränkt:
    Hindernisse, Impediments
  • Motivation → was treibt uns an
  • Wissen / Expertise / Kompetenz der Entwickler
  • Entwicklungsumgebung (lokal wie auch TFS Infrastruktur etc.)
  • Transparenz
  • Zielvorstellungen
  • Prozess
  • Das Ziel (das Produkt)
  • Krankheit
  • Unvorhergesehene / ungeplante Ereignisse

Zusammenfassung

  • Aus unserer bisherigen Erfahrung ist das Schätzen in einer abstrakten Größe genauer als eine rein zeitbasierte Schätzung.
  • Bei größeren Release-Planungen ist die Planung immer zyklisch anzupassen und es gilt zu beachten, dass auch die Velocity nur eine Planzahl ist.
  • Scrum bietet zusätzlich den Vorteil, dass die Planungen nach jedem Sprint (alle 2-4 Wochen) angepasst werden können und somit eine gute Reaktionsfähigkeit gegeben ist, die es ermöglicht die wichtigen Dinge zuerst zu implementieren.