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

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 eigentlich ein Werkzeug sein, um Wissenslücken aufzudecken. Wenn du eine 8 legst und dein Kollege eine 2, dann ist die Zahl egal – wichtig ist das Gespräch darüber, warum ihr so unterschiedlich denkt.

Doch in der Realität ist Planning Poker oft eine Mischung aus verschiedenen Zutaten. Das ist der PO, der versucht sein kann, die Schätzung nach unten zu drücken („Geht das nicht schneller?“). Hinzu kommt der Gruppenzwang. Ihr einigt euch auf den Durchschnitt, um endlich wieder an den Schreibtisch zu kommen. Dann ist da noch der Rechtfertigungsdruck. Lieber schätzt du defensiv („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 vs. Zeit

Ron Jeffries, einer der Väter von XP (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 waren Points dazu gedacht, Schätzungen von der Zeit zu entkoppeln. Die Idee war, über Komplexität, Risiko und Aufwand reden. Warum? Weil unser Gehirn furchtbar darin ist, Zeit zu schätzen („Wie viele Stunden dauert das?“), aber ziemlich gut darin, Dinge zu vergleichen („Ist das Feature größer oder kleiner als das letzte?“).

Aber da entsteht dann auch ein Problem. Sobald jemand in deinem Team sagt „1 Point entspricht bei uns 4 Stunden“, habt ihr das Konzept getötet. Und ich kann aus meiner Praxis sagen, dass das immer passiert.

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 10 Zeilen lang ist. Wenn du es in Zeit schätzt, lügst du dich selbst an.

Velocity ist kein Leistungsindikator

Das größte Verbrechen an der agilen Idee ist die Nutzung der Velocity (die Summe der Points pro Sprint) als Performance-Metrik.

Wenn das Management fragt: „Warum hat Team A eine Velocity von 40 und Team B nur 20?“, dann passiert Folgendes: Point-Inflation. Team B wird im nächsten Planning einfach anfangen, alles höher zu schätzen. Ein 3er Ticket 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 dazu führt, dass Teams bei der Qualität sparen. Man skippt Tests oder Refactoring, nur um die Punkte „durch die Pipeline zu prügeln“. Das Ergebnis? Technische Schulden, die euch zwei Sprints später einholen.

Alternative 1: T-Shirt Sizes für Grobes

Wenn ihr Schätzungen braucht, um dem Business eine grobe Richtung zu geben, nutzt T-Shirt Sizes (S, M, L, XL).

• S: Das 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-T-Shirt“ in Stunden umzurechnen. Es bleibt eine abstrakte Einordnung von Volumen, die für die Quartalsplanung völlig ausreicht.

Alternative 2: Flow Metrics & Monte Carlo (Daten statt Raten)

Es gibt eine mathematisch fundiertere Lösung: Flow Metrics. Statt in die Glaskugel zu schauen, schauen wir in die Vergangenheit. 

Throughput: Wie viele Tickets erledigen wir pro Woche? (Egal wie groß sie sind).

Cycle Time: Wie lange dauert es im Schnitt vom Start einer Story bis zum Deployment?

Wenn ihr eine größere Anzahl an Tickets in der Vergangenheit hattet, könnt ihr auch eine Monte-Carlo-Simulation nutzen. Diese berechnet auf Basis eurer echten Daten die Wahrscheinlichkeit, wann ein Projekt fertig wird.

Im Detail: Eine Monte-Carlo-Simulation führt z.B. 10.000 Simulationen eures Sprints oder Projekts durch. Sie würfelt dabei nicht zufällig, sondern nutzt die Verteilung eures realen historischen Throughputs.

• Lauf 1: Die Simulation nimmt an, ihr seid so schnell wie in eurer besten Woche (z.B. 12 Tickets).
• Lauf 2: Sie nimmt an, ihr habt eine Woche wie im Sommerloch (z. B. 2 Tickets).
• Lauf 3 bis 10.000: Sie kombiniert diese Wahrscheinlichkeiten immer wieder neu.

Das Ergebnis: Keine Single-Point-Lüge, sondern ein Histogramm.

Am Ende erhältst du kein Datum („Wir sind am 12. Oktober fertig“), sondern eine Wahrscheinlichkeitsverteilung (Percentiles):

• 50 % Wahrscheinlichkeit: 10. Oktober (Sehr optimistisch, eine Münzwurf-Chance).
• 85 % Wahrscheinlichkeit: 24. Oktober (Das „Commitment“-Level, mit dem man planen kann).
• 95 % Wahrscheinlichkeit: 05. November (Sicherheit für kritische Deadlines).

Anstatt zu sagen „Wir schaffen das in 3 Wochen“, sagst du: „Mit einer Wahrscheinlichkeit von 85 % sind wir in 22 Tagen fertig.“ Das ist kein Raten mehr, das ist Wissenschaft. 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 man das Management ohne Schätzungen beruhigt

Das Management will Schätzungen meistens nur aus einem Grund: Angst vor Ungewissheit. Sie wollen ein Datum, um das Gefühl von Kontrolle zu haben.

Um dem entgegen zu kommen, habe ich folgende Tipps für dich.

Slice it down. Schneide Tickets so klein, dass jedes Ticket in 1–2 Tagen erledigt werden kann. Dann brauchst du keine Punkte mehr, du musst nur noch Tickets zählen (Throughput).

Transparenz über Varianz. Zeig dem Management, dass Schätzungen am Anfang eines Projekts immer falsch sind.

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

Fazit: Weniger schätzen, mehr liefern

Story Points waren als Schutzschild für Entwickler gedacht, um nicht auf Stunden festgenagelt zu werden. Heute werden sie oft als Peitsche benutzt. Wenn dein Team unter dem Schätz-Zwang leidet, probiert den No-Estimates-Ansatz: Schneidet die Stories so klein wie möglich (maximal 1 Tag Arbeit) und trackt einfach, wie viele ihr pro Sprint schafft. Das spart Stunden an sinnlosen Diskussionen im Planning und liefert dem Management am Ende genauere Daten. Denn am Ende des Tages zählt nicht, wie viele Punkte im Jira stehen, sondern dass funktionierender Code in Produktion ist, der einen Mehrwert schafft.

Schau als nächstes, was du noch im Entwickler Guide Agile für Entwickler für dich findest.