Story Points entsprechen Zeit (und passen trotzdem auf keinen Zeitstrahl)

Bild: Pixabay / Geralt - Lizenz

Zu den am häufigsten missverstandenen Elementen agiler Arbeitsweisen gehören Story Points. Von klassischen Projektmanagern werden sie häufig in Zeiteinheiten umgerechnet, was bei den meisten agil arbeitenden Teams zu heftigen Abstossungsreaktionen führt. Auf die Frage was diese Punkte denn dann sein sollen, wenn nicht Zeit wird häufig erklärt, dass sie die Komplexität der geschätzten Arbeit anzeigen, was nicht in Stunden oder Tage umrechenbar wäre. Für alle, die dieser Meinung sind, dürfte die letzte Woche ein unangenehmes Erwachen gewesen sein.

Quelle: Twitter

Der Herr der diese (rhetorische) Frage stellt, ist Ron Jeffries, und was er andeutet stimmt - er gehörte in den 90ern zu den Erfindern von Extreme Programming und damit auch der Story Points. Er weiss also tatsächlich, wie sie gemeint sind und was sie bedeuten sollen. Auch zum Thema Komplexität hat er eine Meinung - und es ist keine gute.

Quelle: Twitter

Für ihn ist also klar, dass Story Points Zeit bedeuten und nicht Komplexität. Und wie gesagt, er ist der (Mit)Erfinder. Haben die oben genannten Projektmanager demnach recht, wenn sie einen Punkt mit einer Stunde gleichsetzen? Nun - nein. Auch nicht. Es ist (Ironie der Geschichte) komplexer als das.

Zunächst ist ein Story Point eine neutrale Schätzgrösse. Die ist nötig, da unterschiedliche Menschen für die selbe Aufgabe unterschiedlich viel Zeit brauchen. Je nachdem wer an ihr arbeitet dauert es also mehr oder weniger lang (siehe hier). Zur Ermittlung der Umsetzungsdauer einzelner Aufgaben sind Story Points demnach unbrauchbar. Genau diese Einzelfallschätzung ist es aber, die häufig verlangt wird - und dass das nicht funktionieren kann ist dann Ursache der oben genannten Abstossungsreaktionen.

Was aber machbar ist, ist die Verwendung von Story Points für die Planung grosser Mengen von User Stories. Bei 50, 100 oder mehr User Stories mitteln sich die verschiedenen Abweichungen, so dass die so genannte Velocity entsteht: der durchschnittliche Durchsatz von Story Points pro Sprint. Basierend darauf kann man Prognosen über die zukünftige Arbeitsgeschwindigkeit eines Teams machen (wichtig an dieser Stelle: grosse Mengen von User Stories sind nicht das Selbe wie einzelne grosse Arbeitspakete).

Aber ist denn damit zumindest langfristig eine Planungssicherheit möglich? Nun - immer noch nicht. Die Durchschnittsleistung eines Teams wird mit grosser Wahrscheinlichkeit sinken, wenn einzelne Mitglieder ausgetauscht werden, wenn neue Technologien eingesetzt werden, wenn neue fachliche Herausforderungen anstehen oder wenn mit neuen Schnittstellen oder Kunden umgegangen werden muss. Umgekehrt kann Stabilität in Teamzusammenstellung, Technologie, Aufgabenstellung oder Umgebung auch die Velocity stabilisieren oder sogar steigern.

Hier könnte man letztendlich den Silberstreifen am Horizont vermuten. Es ist also nur nötig Teamzusammenstellung, Technologie, Aufgabenstellung und Umgebung stabil zu halten und schon kann verlässlich und sicher prognostiziert geplant werden? Ja, tatsächlich, das wäre theoretisch möglich. In der Realität dürften derartige Rahmenbedingungen aber selten bis nie auftreten. Und damit kommen wir zum vielleicht grössten der Missverständnisse rund um Story Points.

Story Points haben gar nicht den Zweck berechenbare Arbeit zu planen. Sie sollen helfen, Annahmen zur Umsetzungsdauer unberechenbarer (und damit unplanbarer) Arbeit zu machen (mehr dazu hier). Das findet zwar in Zeiteinheiten statt (mit den oben genannten Einschränkungen), da einige der Annahmen sich aber als falsch herausstellen werden wird das Gesamtergebnis immer anders sein als die initiale Annahme. Das Fazit kann daher nur lauten: Story Points entsprechen zwar Zeit - passen aber trotzdem auf keinen Zeitstrahl.


Nachtrag 23.05.:
Ron Jeffries hat seine Gedanken in einem Artikel zusammengefasst. Verkürzt gesagt - statt Story Points empfiehlt er #NoEstimates.