Der Tod der Story Points (und was danach kommt)

Der Cargo-Kult von Fibonacci

Story Points sind zum Cargo-Kult des modernen Engineerings geworden.

Teams weisen Tickets religiös Fibonacci-Zahlen zu. Sie streiten darüber, ob eine 3 wirklich eine 5 ist. Sie berechnen Velocity mit Dezimalpräzision. Sie projizieren zukünftige Sprints basierend auf historischen Durchschnittswerten. Und dann wundern sie sich, warum ihre Vorhersagen wie abstrakte Kunst aussehen.

Hier ist eine unbequeme Wahrheit: Story Points wurden für eine Welt entwickelt, die nicht mehr existiert.

Die ursprüngliche Prämisse war einfach: Entwickler arbeiten mit relativ konstanter Geschwindigkeit, also sollte die Messung relativer Komplexität (eine 5 ist ungefähr doppelt so schwer wie eine 3) im Laufe der Zeit vorhersagbare Velocity liefern. Etabliere eine Baseline, und du kannst mit angemessener Genauigkeit prognostizieren.

Diese Prämisse ist jetzt gebrochen.

Warum sterben Story Points?

Story Points setzen eine stabile Einheit voraus: dasselbe Team, das auf dieselbe Weise arbeitet, mit ungefähr derselben Geschwindigkeit. KI-Unterstützung hat diese Annahme auf drei Arten gebrochen – Schätzungen variieren jetzt stark pro Aufgabe, Velocity sagt Lieferung nicht mehr vorher, und historische Baselines lassen sich nicht mehr übertragen.

Das KI-Variabilitätsproblem

Wenn derselbe Entwickler am Montag (mit Copilot, einer klaren Spezifikation und einer vertrauten Codebasis) 10x schneller sein kann als am Dienstag (beim Ringen mit einem Legacy-System, beim Debuggen einer KI-Halluzination und beim Kontextwechsel zwischen drei Projekten) – was genau bedeutet dann eine „5-Punkte-Story"?

Es bedeutet nichts. Die Maßeinheit ist variabel geworden.

Betrachten Sie ein reales Beispiel: Ein Entwickler schätzt ein CRUD-Feature auf 5 Punkte basierend auf historischer Velocity. Mit KI-Unterstützung schließt er es in 2 Stunden ab. Die nächste 5-Punkte-Story beinhaltet das Debuggen einer Race Condition in Legacy-Code, wo KI nutzlos ist, und es dauert 3 Tage.

Beide waren „5 Punkte". Eine dauerte 2 Stunden, eine dauerte 24. Ihr Velocity-Graph enthält jetzt Datenpunkte, die um das 12-fache variieren bei derselben geschätzten Komplexität.

Das Problem bedeutungsloser Velocity

Der DORA-Bericht 2024 stellte fest, dass Teams, die KI-Coding-Assistenten einführten, einen Rückgang der Lieferung um 1,5 % und einen Rückgang der Lieferstabilität um 7,2 % verzeichneten¹: mehr Aktivität, weniger gelieferter Wert. Velocity misst Aktivität statt Ergebnisse, weshalb Teams mit hoher Velocity oft weniger Wert liefern als Teams mit moderater Velocity.

Wenn KI Aktivitätsmetriken aufbläht (mehr Commits, mehr PRs, mehr „abgeschlossene" Stories), wird Velocity zu reinem Rauschen. Die Zahl steigt, aber niemand weiß, was sie bedeutet.

Das Problem historischer Baselines

Story-Point-Schätzung basiert auf Kalibrierung: „Letzten Sprint haben wir 40 Punkte abgeschlossen, also committen wir uns diesen Sprint auf 40." Aber was passiert, wenn:

• Die Hälfte des Teams gerade KI-Assistenten eingeführt hat (Velocity könnte sprunghaft steigen)?
• Die Codebasis, an der Sie arbeiten, für KI unbekannt ist (Velocity könnte fallen)?
• Ihr bester Schätzer gegangen ist und seine Kalibrierung mitgenommen hat?

Historische Baselines setzen Konsistenz voraus. KI hat diese Annahme zerstört.

Was ersetzt Story Points?

Der Tod von Story Points bedeutet nicht den Tod der Schätzung. Drei Ansätze funktionieren im KI-Zeitalter: zeitlich begrenzte Experimente, Ergebnis-Commitments und kontinuierliche Neu-Schätzung.

Ansatz 1: Zeitlich begrenzte Experimente

Anstatt zu schätzen, wie lange etwas dauern wird, committen Sie sich darauf, was Sie innerhalb einer festen Zeitbox versuchen werden.

Der alte Weg: „Dieses Feature hat 8 Punkte, was historisch ~4 Tage bedeutet."

Der neue Weg: „Wir werden 2 Tage damit verbringen, dieses Feature zu erkunden. Am Ende wissen wir, ob wir es ausliefern können oder mehr Zeit brauchen."

Dieser Ansatz erkennt Unsicherheit im Voraus an. Sie tun nicht so, als könnten Sie das Unvorhersagbare vorhersagen – Sie committen sich darauf, schnell zu lernen.

Ansatz 2: Ergebnis-Commitments

Anstatt Aufwand zu schätzen, committen Sie sich auf ein Ergebnis bis zu einem Datum – und lassen Sie das Team herausfinden, wie es dorthin kommt.

Der alte Weg: „Dieses Epic hat 40 Punkte über 8 Stories, also dauert es 2 Sprints."

Der neue Weg: „Wir liefern Benutzerauthentifizierung bis Freitag. Hier ist die minimal lebensfähige Version, hier sind die Stretch-Ziele, und hier ist, was wir bei Bedarf kürzen."

Dieser Ansatz fokussiert auf das, was zählt (Ergebnisse), statt auf Proxys (Aufwand). Er schafft Ausrichtung über Prioritäten und bringt Risiken früh an die Oberfläche: „Wenn wir OAuth nicht bis Mittwoch zum Laufen bringen, liefern wir nur mit E-Mail/Passwort."

Ansatz 3: Kontinuierliche Neu-Schätzung

Anstatt einmal beim Sprint-Planning zu schätzen und nie wieder zu überprüfen, aktualisieren Sie Schätzungen, während Sie lernen.

Der alte Weg: „Wir haben beim Planning 5 Punkte geschätzt, also ist das die Schätzung."

Der neue Weg: „Wir haben am Montag 5 Punkte geschätzt. Am Mittwoch wissen wir, dass es tatsächlich eine 8 ist. Das ist wertvolle Information – lassen Sie uns unsere Commitments aktualisieren."

Dieser Ansatz behandelt Schätzung als Werkzeug für fortlaufende Konversation statt als einmalige Vorhersage. Die Schätzung entwickelt sich, während Wissen wächst.

Wie sich Planning Poker weiterentwickelt

Wir haben unser Planning Poker-Tool gebaut, um diese Ansätze zu unterstützen – nicht weil wir denken, dass traditionelle Schätzung immer falsch ist, sondern weil Teams Flexibilität brauchen.

Für traditionelle Schätzung

Ja, Sie können immer noch Fibonacci-Punkte zuweisen. Einige Teams und einige Arten von Arbeit profitieren immer noch von relativer Schätzung. Stabile Codebasen, erfahrene Teams, gut verstandene Domänen – Story Points können hier funktionieren.

Aber wir haben Sicherheitsvorkehrungen hinzugefügt:

• Anomalie-Erkennung: Sprint-Metriken durchlaufen Z-Score-Anomalie-Erkennung, sodass Sie es markiert sehen, wenn Velocity außerhalb ihres normalen Bereichs schwankt, anstatt in einem Durchschnitt begraben zu werden.
• Geplant-versus-abgeschlossen-Tracking: Sprint-Metriken vergleichen, wozu Sie sich committed haben, mit dem, was tatsächlich ausgeliefert wurde, sodass Schätzungsdrift Sprint für Sprint sichtbar wird statt bei der vierteljährlichen Abrechnung.
• Ergebnistrends, kein Tool-Tracking: Wir tracken nie, wer KI wofür verwendet hat. Sprint-für-Sprint-Vergleich zeigt, ob Ihre Schätzungen zuverlässiger oder weniger zuverlässig werden, unabhängig von der Ursache.

Für zeitlich begrenzte Experimente

Anstatt Punkte zuzuweisen, schätzen Sie in Zeitboxen. Die Zeit-Skala (Stunden) reicht von 1 Stunde bis 40, und benutzerdefinierte Skalen lassen Sie Ihre eigenen Checkpoints definieren:

• 2-Stunden-Spike
• Halbtägige Exploration
• 1-Tages-Prototyp

Am Ende der Zeitbox beantwortet das Team eine einfache Frage: „Können wir das ausliefern, oder brauchen wir mehr Zeit?" Dies schafft natürliche Checkpoints ohne falsche Präzision.

Für Ergebnis-Commitments

Ergebnis-Commitments brauchen kein spezielles Tooling. Definieren Sie das Ergebnis, setzen Sie ein Zieldatum und zerlegen Sie es in Meilensteine mit Go/No-Go-Checkpoints. Wo Tooling hilft, ist danach: Action-Item-Tracking und Health Scores zeigen, ob das Commitment ausgeliefert wurde und haften blieb.

Das Gespräch ist der Punkt

Hier ist, was die meisten Teams bei der Schätzung übersehen: Die Schätzung selbst spielt keine Rolle. Das Gespräch schon.

Wenn Ihr Team darüber streitet, ob etwas eine 3 oder eine 5 ist, liegt der Wert nicht darin, die „richtige" Zahl zu erreichen. Der Wert liegt darin, unterschiedliche Annahmen aufzudecken:

• „Ich denke, es ist eine 3, weil wir das bestehende Auth-Modul wiederverwenden können."
• „Ich denke, es ist eine 5, weil das bestehende Auth-Modul unsere neuen Anforderungen nicht abdeckt."

Dieses Gespräch hat ein Risiko aufgedeckt. Die Schätzung ist fast irrelevant; das gemeinsame Verständnis ist alles.

Deshalb bleiben Schätzungszeremonien wertvoll, selbst wenn die Schätzungen selbst verrauscht sind. Das Ziel ist nicht Vorhersage. Das Ziel ist Ausrichtung.

Die Veränderung kommunizieren

Wenn du überzeugt bist, dass traditionelle Story Points nicht funktionieren, musst du dies Stakeholdern kommunizieren, die „Velocity-Dashboards" erwarten. So geht's:

Für Engineering Leadership

Formuliere es um Vorhersagbarkeit, nicht um Prozesse. Führungskräfte interessiert, wann Dinge ausgeliefert werden. Erkläre, dass Velocity unzuverlässig geworden ist (zeige die Varianz), und dass ihr Praktiken einführt, die die Vorhersagbarkeit tatsächlich verbessern werden.

Zeigen, nicht erzählen. Führe ein paralleles Experiment durch: Verfolge zwei Monate lang traditionelle Velocity UND Outcome-Commitments. Lass die Daten sprechen.

Für Product-Partner

Fokussiere dich auf das, was ihnen wichtig ist: Liefertermine. Product Manager interessieren sich nicht für Story Points – sie interessieren sich dafür, wann Features fertig sein werden. Outcome-basierte Commitments geben ihnen bessere Informationen: „Wir liefern bis Freitag" ist nützlicher als „Wir haben 40 Punkte abgeschlossen."

Mache es zum Thema Risikoaufdeckung. Kontinuierliche Neuschätzung deckt Risiken früher auf. Das braucht Product: Frühwarnung, nicht falsches Vertrauen.

Für das Team

Erkenne die Dysfunktion an. Wenn Story Points zu einem leeren Ritual geworden sind, weiß das Team es. Es zuzugeben schafft Vertrauen.

Mache es zunächst freiwillig. Lass das Team mit Alternativen bei ein paar Stories experimentieren, bevor ihr euch auf einen vollständigen Übergang festlegt.

Die Zukunft der Schätzung

Hier ist, wohin wir uns bewegen:

Kurzfristig: Schätzung wird adaptiv. Teams verwenden unterschiedliche Ansätze für unterschiedliche Arbeitstypen: Story Points für stabile, gut verstandene Arbeit; Time-Boxes für Exploration; Outcome-Commitments für hochpriorisierte Features.

Mittelfristig: KI unterstützt bei der Schätzung selbst. Basierend auf historischen Mustern, Codebase-Komplexitätsanalyse und ähnlicher vergangener Arbeit kann KI Schätzungen vorschlagen – nicht als Wahrheit, sondern als Input für das Gespräch.

Langfristig: Schätzung wird weniger notwendig. Während sich Deployment-Zyklen verkürzen und Feedback-Schleifen enger werden, nimmt der Bedarf an Vorhersagen im Vorfeld ab. Du wirst wissen, ob etwas schwierig ist, indem du ein paar Stunden daran arbeitest, nicht indem du in einem Planning-Meeting über Punkte diskutierst.

Story Points haben uns zwei Jahrzehnte lang gute Dienste geleistet. Sie waren das richtige Werkzeug für ihre Zeit. Aber die Bedingungen, die sie nützlich machten, haben sich grundlegend geändert, und unsere Praktiken müssen sich mit ihnen ändern.

Was das für dein Team bedeutet

Wenn du Story-Point-Dysfunktion spürst, bist du nicht allein. Hier ist, wo du anfangen kannst:

1. Miss deine Velocity-Varianz. Wenn sie von Sprint zu Sprint um mehr als 25 % schwankt, sind deine Schätzungen nicht vorhersagend; sie sind Rauschen.

2. Probiere eine Alternative aus. Wähle im nächsten Sprint ein paar Stories aus und schätze sie mit Time-Boxes statt mit Punkten. Schau, wie es sich anfühlt.

3. Fokussiere dich auf Outcomes. Frage bei der Planung „Was wollen wir, dass am Ende des Sprints wahr ist?" statt „Wie viele Punkte können wir abschließen?"

4. Akzeptiere Unsicherheit. Die ehrliche Antwort auf „Wie lange wird das dauern?" ist oft „Ich weiß es noch nicht – lass mich einen Tag lang versuchen und ich sage dir mehr."

Das Ziel war nie, die richtige Zahl zuzuweisen. Das Ziel war, wertvolle Software auszuliefern. Wenn deine Schätzungspraktiken diesem Ziel im Weg stehen, ist es Zeit für sie, sich weiterzuentwickeln.

Quellen