Artikel

Story Points sind kein Indikator für Performance

Geschrieben von Christoph Hochstrasser vor 9 Monaten

Story Points in Planning Poker oder Fast Estimation sind eine gute Art und Weise den Aufwand von Stories einer Product Owner mitzuteilen, damit sie sieht welche Backlog Items ein gutes Verhältnis zwischen Aufwand und Business Value aufweisen.

Nur das Problem mit Story Points ist, dass der Aufwand durch eine Zahl ausgedrückt wird.

Und viele Menschen glauben, dass man auf alles Statistik anwenden kann, wenn es wie eine Folge von Zahlen aussieht. Oder, dass es möglich ist, Story Points von mehreren Backlog Items aufzusummieren um von jemanden ein Commitment zum Abliefern genau dieser Summe zu fordern.

Ich finde das Irrsinn.

Was am meisten bringt, soll zuerst gemacht werden.

Kurzer Hintergrund zum Grundgedanken von Scrum: Was am meisten bringt, soll zuerst gemacht werden.

Estimations sind nur ein Mittel für Product Owners um herauszufinden, wie das erreicht werden kann.

Also um Folgendes auszudrücken:

  • „Ist dieses Item einfacher oder schwerer umzusetzen als dieses andere Item?“ bzw. „Warum?“
  • „Das ist unmöglich umzusetzen!“
  • „Das ist ganz einfach!“

Und selbst dort geht es nur um einen groben Schätzwert. „Besser ungefähr richtig als präzise falsch“ ist hier das Motto. Darum üblicherweise auch die Verwendung einer Fibonacci Reihe. Weil es eine bewusste Unschärfe geben soll. Weil wir Menschen grundsätzlich schlecht im schätzen sind[1]. Also fünf Story Points sagen in Wirklichkeit aus, dass der Aufwand zwischen drei und acht Story Points liegt.

Das Ziel möglichst viel Business Value zu liefern heißt auch, dass es nicht darum geht so viele Story Points pro Sprint wie möglich umzusetzen. Oder dass die Velocity so hoch wie möglich ist. Oder dass wir präzise Schätzungen abliefern.

Liefern tun wir nur eines: Business Value.

Schätzungen sind nie dazu da ein Performance Indikator zu sein.

Man kann nicht ungefähre Schätzwerte summieren und dann glauben, dass man das genau nehmen kann. Einem Team wird dann in der Praxis vorgeworfen, warum die Velocity niedriger war, oder warum man sich so verschätzt hat.

Es geht bei den Schätzungen nur darum, herauszufinden, was sich von den Items am meisten auszahlt. Niemand darf auf eine Schätzung festgenagelt werden.

Darum sagen dann viele Teams, dass Scrum ihre Situation nicht verbessert hat oder, dass man nichts mehr schätzen möchte.

Quick fix: T-Shirt Sizes zur Estimation

Eine vorübergehende Lösung kann jetzt die Verwendung von T-Shirt Sizes zur Estimation sein. T-Shirt Sizes sind nicht numerisch. Da kommt keiner auf die Idee eine Summe zu bilden. Auch beim Planning wäre es lächerlich, wenn man sagen würde: „Ihr habt mir 1 Story in L, 3 Stories in M, oder 6 Stories in S jedem Sprint zu liefern“ vs. dem gängigen „Ihr habt mir x Story Points zu liefern“ von manchen POs.

Man erfüllt also das Ziel der PO mitzuteilen, welches Backlog Item ungefähr wieviel Aufwand bedeutet. Ohne aber eine Genauigkeit oder Messbarkeit anzudeuten, die es gar nicht geben kann.

Langfristig können aber auch T-Shirt Sizes nicht messbare Indikatoren für Team-Performance ersetzen.

Team Performance Indikatoren

„Aber ich brauche doch einen Messwert, damit ich sehe ob mein Team Probleme mit der Performance hat!”

Ja, das versteh ich natürlich. Man soll natürlich auch Team Performance irgendwie steigern können, dafür muss man sie messen können. Das ist ja auch im Interesse des Teams, niemand arbeitet gerne ineffizient.

Aber dafür gibt es Dinge, die man präzise messen kann. Wie die Cycle Time. Das ist die Zeit zwischen dem ersten Eintreten der Story in das Sprint Backlog und dem Durchlaufen des Prozesses bis Done.

Das kann man präzise messen und kann in den meisten Tools auch einfach ausgewertet werden. Eine hohe Cycle Time kann auf Probleme hinweisen.

Etwas anderes, das wirklich unglaublich einfach, aber effektiv ist: Messen wie viele Stories über eine Zeitspanne pro Sprint umgesetzt wurden. Das kann genauso Probleme aufzeigen und der Durchschnittswert pro Sprint kann bei der Planung eines Releases helfen.

Man darf aber trotzdem nicht übersehen auch einen Indikator zu finden, der den Erfolg des Produktes beinhaltet. Weil am Ende des Tages ist unser Ziel ja nicht so effizient wie möglich zu arbeiten, sondern etwas zu schaffen, das erfolgreich ist. So ein Indikator könnte z.B. vom generierten Umsatz oder von der Anzahl der Monthly Active Users abhängig sein oder Total Cost of Ownership.


  1. http://evolution.berkeley.edu/evolibrary/news/110201_throwing ↩︎