Story Points sind Unsinn? Die Wahrheit über Agile Schätzungen

Survival-Kit für Entwickler Teil 2 von 8 Zur Übersicht

Es ist Montag, 10:00 Uhr. Planning Poker. Du starrst auf ein Ticket mit der Beschreibung „Refactoring der Authentifizierungs-Logik“. Du weißt, dass der Code an dieser Stelle seit drei Jahren nicht mehr angefasst wurde und vermutlich Schlingen aus Legacy-Code enthält, die dich tagelang binden könnten.

Der Product Owner fragt: „Und, was schätzt ihr?“

Du legst eine 8. Dein Kollege eine 2. Ein anderer eine 5. Nach zehn Minuten Diskussion einigt ihr euch auf die „goldene Mitte“: eine 5. Aber in deinem Kopf rechnest du längst: „5 Punkte? Das sind bei uns im Team-Schnitt etwa 2,5 Tage... wenn nichts schiefgeht.“

Genau hier fängt der Bullshit an.

Wenn Story Points in deinem Team nur ein Codewort für Zeit sind, dann spielt ihr Agile-Theater. Und du bist nicht allein mit deinem Frust: Sogar der Mann, der sie vermutlich erfunden hat, Ron Jeffries, bereut es heute.

Warum Entwickler Planning Poker hassen

Planning Poker sollte ein Werkzeug sein, um Wissenslücken aufzudecken. Wenn du eine 8 legst und dein Kollege eine 2, ist die Zahl egal. Wichtig ist das Gespräch darüber, warum ihr so unterschiedlich denkt.

In der Realität mischen sich drei andere Dinge hinein. Der PO, der die Schätzung nach unten drücken will („Geht das nicht schneller?“). Der Gruppenzwang, weil ihr euch auf den Durchschnitt einigt, um endlich wieder an den Schreibtisch zu kommen. Und der Rechtfertigungsdruck, wegen dem du defensiv schätzt, lieber eine 8 als eine 5, um Puffer für unvorhergesehene Meetings zu haben.

Das Ergebnis ist eine Zahl, die wenig mit der Realität zu tun hat, aber im Jira-Backlog wie in Stein gemeißelt wirkt.

Das Missverständnis: Komplexität und Zeit

Ron Jeffries, einer der Väter von Extreme Programming, sagt heute ganz offen:

I like to say that I may have invented story points, and if I did, I’m sorry now.

Ursprünglich sollten Points die Schätzung von der Zeit entkoppeln. Die Idee war, über Komplexität, Risiko und Aufwand zu reden. Warum? Weil unser Gehirn furchtbar darin ist, Zeit zu schätzen, aber ziemlich gut darin, Dinge zu vergleichen: Ist das Feature größer oder kleiner als das letzte?

Sobald jemand in deinem Team sagt „1 Point entspricht bei uns 4 Stunden“, ist das Konzept tot. Und aus meiner Praxis kann ich sagen: Das passiert immer.

Zeit ist eine Konstante. Komplexität nicht. Wenn du ein Ticket in einer neuen Sprache schreibst, ist die Komplexität hoch, auch wenn der Code nur zehn Zeilen lang ist. Schätzt du das in Zeit, lügst du dich selbst an.

Velocity ist kein Leistungsindikator

Das größte Verbrechen an der agilen Idee ist die Nutzung der Velocity als Performance-Metrik.

Wenn das Management fragt, warum Team A auf 40 kommt und Team B nur auf 20, passiert Point-Inflation. Team B schätzt im nächsten Planning alles höher. Ein 3er wird zur 5, ein 5er zur 8. Auf dem Papier ist das Team plötzlich produktiver, am Code hat sich nichts geändert.

Ron Jeffries warnt davor, dass dieser Druck bei der Qualität sparen lässt. Tests und Refactoring fallen weg, nur um die Punkte durch die Pipeline zu prügeln. Das Ergebnis sind technische Schulden, die euch zwei Sprints später einholen.

Alternative 1: T-Shirt-Größen für Grobes

Wenn ihr Schätzungen braucht, um dem Business eine Richtung zu geben, nutzt T-Shirt-Größen.

• S: machen wir im Vorbeigehen
• M: ein normales Feature
• L: groß, wir müssen es vermutlich schneiden
• XL: ein ganzes Epos, das wir noch nicht verstehen

Der Vorteil: Niemand kommt auf die Idee, ein L in Stunden umzurechnen. Es bleibt eine abstrakte Einordnung von Volumen, und die reicht für die Quartalsplanung völlig aus.

Alternative 2: Flow Metrics und Monte Carlo

Es gibt eine mathematisch fundiertere Lösung. Statt in die Glaskugel zu schauen, schaut ihr in die Vergangenheit. Throughput: Wie viele Tickets erledigen wir pro Woche, unabhängig von ihrer Größe? Cycle Time: Wie lange dauert es im Schnitt vom Start einer Story bis zum Deployment?

Wenn ihr genug erledigte Tickets in der Historie habt, könnt ihr eine Monte-Carlo-Simulation rechnen. Sie führt zum Beispiel zehntausend Durchläufe eures Projekts aus und würfelt dabei nicht zufällig, sondern nutzt die Verteilung eures echten historischen Throughputs. Ein Durchlauf nimmt an, ihr seid so schnell wie in eurer besten Woche, der nächste rechnet mit dem Sommerloch, und die restlichen kombinieren beides immer wieder neu.

Am Ende steht kein Datum, sondern eine Wahrscheinlichkeitsverteilung:

• 50 %: 10. Oktober, eine Münzwurf-Chance
• 85 %: 24. Oktober, das Niveau, mit dem man planen kann
• 95 %: 5. November, Sicherheit für kritische Deadlines

Statt „Wir schaffen das in drei Wochen“ sagst du: „Mit 85 Prozent Wahrscheinlichkeit sind wir in 22 Tagen fertig.“ Das ist kein Raten mehr. Und es nimmt den emotionalen Druck aus dem Planning Poker.

Zur Flow-Messung im Team habe ich eine Podcast-Folge gemacht, falls du mal reinhören willst.

Ich habe auch eine Flow Physics Landing Page gebaut, die dir die Prinzipien des Flows erklärt.

Wie du das Management ohne Schätzungen beruhigst

Das Management will Schätzungen meistens aus einem Grund: Angst vor Ungewissheit. Es will ein Datum, um ein Gefühl von Kontrolle zu haben, muss planen und sich im Zweifel vor anderen rechtfertigen.

Slice it down. Schneide Tickets so klein, dass jedes in einem bis zwei Tagen erledigt ist. Dann brauchst du keine Punkte mehr, sondern zählst Tickets.

Zeig die Varianz. Mach sichtbar, dass Schätzungen am Anfang eines Projekts immer falsch sind, und zwar systematisch, nicht aus Nachlässigkeit.

Versprich Flow, nicht Punkte. Eine stabile Cycle Time ist wertvoller als eine hohe Velocity. Ein stabiler Prozess erlaubt Vorhersagen, Schätz-Poker erlaubt nur Wunschdenken.

Weniger schätzen, mehr liefern

Story Points waren als Schutzschild für Entwickler gedacht, um nicht auf Stunden festgenagelt zu werden. Heute sind sie oft eine Peitsche.

Wenn dein Team unter dem Schätz-Zwang leidet, probiert No Estimates: Stories so klein schneiden wie möglich, höchstens ein Tag Arbeit, und dann einfach zählen, wie viele pro Woche durchgehen. Das spart Stunden an sinnlosen Diskussionen und liefert dem Management genauere Daten als jede Punktesumme.

Nimm dir eine einzige Sache aus diesem Artikel für das nächste Planning: Sag nicht mehr, wie lange etwas dauert. Sag, was daran unklar ist.