Story Points – oder auch: Schätzen wie man Bier bestellt

Keiner mag Schätzungen, alle mögen akkurate Zusagen. Dummerweise bräuchte man für Letzteres eine Zeitmaschine, sodass uns nichts anderes übrig bleibt als hin und wieder zu schätzen, um irgendwie planen zu können. Dabei helfen uns Story Points und schließlich die Velocity.

Ein Story Point ist eine relative Angabe über den Umfang einer Anforderung.

„Relativ?“ wirst du vielleicht fragen und ich kann dir auch nicht verdenken, dass diese Aussage doch erstmal recht abstrakt klingt. Deshalb möchte ich zunächst mal die Idee einer praktischen Annäherung aus einem Standardwerk der agilen Planung aufgreifen.

Agiles Schätzen wie man Bier bestellt

Irgendwo in einer Bar

Du bist mit zwei Freunden in einer Bar. Während ihr euch noch über den absurd schlechten Film der gerade hinter euch liegenden Kinovorstellung sprecht, werdet ihr wirsch vom Barmann unterbrochen, der sowas sagt wie: „Was darf’s ’n sein?“

Unisono antworten deine Freunde und du: „Bier!“
(Oder Cola, Wasser, Apfelschorle oder was auch immer ihr eben so trinkt)

Der Barmann antwortet mit einer Handbewegung, die universell verstanden und von euch mit ähnlichen Handbewegungen beantwortet wird. Wenig später stehen Gläser auf dem Tresen: ein Großes, ein Mittleres und für „Ich muss noch fahren“-Joe ein Kleines.

Selbst ohne Gesten hättet ihr wahrscheinlich nicht in exakten Mengenangaben bestellt („Ich hätte gerne 20 Zentiliter Altbier!“) und trotzdem habt ihr ungefähr bekommen, was ihr haben wolltet.

So ähnlich kann man auch in agilen Projekten schätzen.

Wie aufwändig ist eine Aufgabe im Vergleich zu einer Anderen?

Wenn wir nun beispielsweise User Stories für die Beschreibung von Anforderungen verwenden, könnten wir ein ähnliches Verfahren anwenden. Dabei geht es gar nicht so sehr um den exakten Wert (wieviel Punkte eine Anforderung bekommt ist egal – wie sich später beim Blick auf die Velocity zeigen wird) sondern um Vergleichsgrößen.

In diese Vergleichsgröße kann und darf alles einfließen, was den Umfang der Story, Anforderung oder Aufgabe beeinflusst: Komplexität, Risiko, der geschätzte Aufwand. Keinesfalls sollte es ein reines Mapping von Punkten auf Zeit sein, denn das würde dem Sinn zuwider laufen.

Nun beginnt man entweder, indem man die kleinste Story raus pickt und ihr einen einzelnen Story Point zuweist oder indem man eine Skala festlegt und eine Story auswählt, die irgendwie „mittel“ ist. Der weist man dann beispielsweise 5 Story Points zu bei einer Skala von 1 -10.

Alle anderen Stories werden nun geschätzt und zwar im Vergleich zu der Referenzgröße. Ein mögliches Vorgehen hierfür ist das Planning Poker – das zwar verspielt klingt, aber seinen Nutzen gemäß einer Studie von 2007 empirisch unter Beweis gestellt hat. Planning Poker hilft einige typische Probleme von Schätzprozessen zu vermeiden (beispielsweise den Dunning-Kruger-Effekt).

Sind wir schon da?

Wenn das Team eine Iteration und hoffentlich ein paar Stories abgeschlossen hat, lässt sich die Velocity ermitteln. Dafür werden die abgeschlossenen und abgenommenen Stories herangezogen und deren Story Points zusammen gezählt.

Die rauskommende Velocity ist eine relativ gute Vermutung, was dasselbe Team in einer Iteration schaffen kann.

So kann ein Team mit einer Velocity von 10 im nächsten Sprint voraussichtlich zwei Stories mit 5 Story-Points oder fünf Stories mit 2 Story-Points abschließen. Die tatsächliche Größe der Story ist irrelevant, solang die Story-Points in Summe die Velocity nicht überschreiten.

Mit der Velocity haben wir nun ein ganz gutes Werkzeug in der Hand, um:

• Stories besser daraufhin bewerten zu können, ob sie klein genug für einen Sprint sind und somit im Endeffekt, welche Arbeit wir in einem Sprint einplanen können.

• Aufgrund der Schätzungen aller Stories eine Release-Planung machen zu können, indem man die Gesamtanzahl der Story Points durch die Velocity teilt und so eine Anzahl notwendiger Iterationen erhält.

• In Verbindung mit Burn Down Charts zu erkennen, wie sich bestimmte Entscheidungen auf die Team Performance auswerten: etwa ein Teammitglied für eine Zeit lang auf andere Aufgaben anzusetzen.

Eine richtige Regel bei agilem Schätzen ist: Wir schätzen Größen, aber leiten Zeitangaben (davon) ab und darauf aufbauend machen wir dann Zeitpläne.

Übrigens: Ob unsere Aufgaben wirklich in Stories vorliegen ist eigentlich völlig egal, solang eine Vergleichbarkeit gegeben ist. Dann könnte man die Storypunkte auch Gummipunkte, Schätzoletten oder was auch immer nennen. Nur die Anlehnung an reale Zeiteinheiten sollte man vielleicht vermeiden.