logo
Rückschauen
Planungspoker
Standups
Eisbrecher
Preise
Armaturenbrett

Beiträge

KI-Agenten in Ihrem Sprint: Wie Copilots die Bedeutung von Story Points verändern

Entwickler-Paar arbeitet mit einem KI-Coding-Assistenten, ein Bildschirm zeigt generierten Code, während der andere ein Sprint-Board mit Story-Point-Schätzungen zeigt und die Spannung zwischen KI-Geschwindigkeit und traditioneller Schätzung vermittelt
Matt Lewandowski

Matt Lewandowski

Zuletzt aktualisiert am 10/02/20267 Min. Lesezeit

Ein Backend-Entwickler in Ihrem Team übernimmt eine 5-Punkte-Story. Historisch gesehen sind das anderthalb Tage Arbeit. Mit Cursor und Claude liefert er sie in einer Stunde ab. Im nächsten Sprint schaut das Team auf ein ähnliches Ticket und jemand fragt: "Ist das immer noch eine 5?" Niemand hat eine gute Antwort. Das passiert gerade überall in Teams, und die meisten agilen Inhalte haben nicht aufgeholt.

Das Problem ist nicht die Velocity-Inflation

Die offensichtliche Reaktion ist "großartig, wir sind jetzt schneller." Aber das Problem geht tiefer als größere Velocity-Zahlen. Story Points sollen relative Komplexität messen. Eine 5 sollte ungefähr den gleichen Aufwand darstellen, unabhängig davon, wer sie übernimmt. KI bricht diese Annahme auf zwei Arten: Die Beschleunigung ist ungleichmäßig. Ein Junior-Entwickler, der Copilot verwendet, sieht möglicherweise eine 3-fache Geschwindigkeitssteigerung bei einem routinemäßigen CRUD-Endpunkt. Ein Senior-Entwickler, der an einer komplexen Integration mit unbekannten APIs arbeitet, sieht möglicherweise keine Verbesserung oder wird tatsächlich langsamer. Die METR-Studie von Mitte 2025 ergab, dass erfahrene Open-Source-Entwickler mit KI-Unterstützung bei realen Aufgaben 19% langsamer waren, während sie glaubten, 20% schneller zu sein. Dieselbe Person ist bei manchen Aufgaben schneller, bei anderen nicht. KI-Agenten bewältigen Boilerplate und gut dokumentierte Muster gut. Sie kämpfen mit Architekturentscheidungen und allem, was tiefes Kontextwissen über Ihre spezifische Codebasis erfordert. Ein Entwickler könnte an einem Morgen drei 3-Punkte-Stories durchhauen und dann zwei Tage für eine einzige 5-Punkte-Story aufwenden, bei der die KI plausible, aber falsche Lösungen generierte. Das macht die Schätzung extrem inkonsistent. Ihr Velocity-Chart beginnt wie ein Seismograph auszusehen.

Was Teams tatsächlich erleben

Sprechen Sie mit Engineering Managern, die Sprints mit KI-unterstützten Teams durchführen, und Sie hören die gleichen Muster: Velocity-Zahlen, die nichts bedeuten. Ein Team berichtete, dass es von konstanten 45-60 Punkten pro Sprint auf 55-65 ging, aber die erledigte Arbeit fühlte sich nicht proportional anders an. Schnelleres Coding übersetzte sich nicht in schnellere Lieferung, weil Code Review, QA und Deployment-Zeitpläne gleich blieben. Der Review-Engpass. GitHub-Daten zeigen, dass monatliche Code-Pushes bis Ende 2025 82 Millionen überschritten, wobei 41% des neuen Codes KI-unterstützt war. Pull Requests stapeln sich. Teams berichten von 4+ Tagen Wartezeit für Reviews. Der Entwickler schrieb den Code in einer Stunde, dann sitzt er eine Woche in der Review-Warteschlange. Technische Schulden, die sich anders zusammensetzen. KI-generierter Code funktioniert tendenziell, aber es fehlt ihm an Architekturbewusstsein. Studien zeigen 4-mal mehr Code-Duplizierung und 60% weniger Refactoring in KI-unterstützten Codebasen. Die 3-Punkte-Story wird schnell ausgeliefert. Sechs Monate später zahlen Sie dafür in der Wartung. Sprint-Board zeigt eine Mischung aus abgeschlossenen und steckengebliebenen Tickets, einige als sehr schnell erledigt markiert und andere im Code Review blockiert, was den ungleichmäßigen Ablauf der KI-unterstützten Entwicklung veranschaulicht Junior-Entwickler, die auf dem Papier wie Seniors aussehen. Ein Entwickler mit zwei Jahren Erfahrung kann jetzt die gleiche Ausgabe generieren wie jemand mit zehn Jahren. Aber sie verbringen 1,2 Minuten mit der Überprüfung jedes KI-Vorschlags im Vergleich zu 4,3 Minuten eines Seniors. Diese Qualitätslücke wird sich erst in der Produktion zeigen.

Story Points sind nicht kaputt, aber sie brauchen eine Neukalibrierung

Der Instinkt, Story Points komplett zu verwerfen, ist verfrüht. Punkte funktionieren immer noch für Team-Alignment und Sprint-Planning-Gespräche. Was sich ändern muss, ist, wie Teams sie kalibrieren.

Trennen Sie "Coding-Aufwand" von "Lieferaufwand"

Der Teil, den KI beschleunigt (Code schreiben), ist nur ein Stück des Lebenszyklus einer Story. Eine ehrlichere Aufschlüsselung:
PhaseKI-Einfluss
Anforderungen verstehenMinimal
Code schreibenHoch (2-10x schneller bei Routinearbeit)
Code ReviewNegativ (mehr Code zu reviewen, oft geringere Qualität)
TestenModerat (KI kann Tests generieren, aber jemand muss sie verifizieren)
Integration und DeploymentMinimal
Wenn Ihr Team Stories hauptsächlich basierend auf Coding-Zeit geschätzt hat, sind Ihre Punkte jetzt falsch kalibriert. Wenn Sie basierend auf dem gesamten Lieferaufwand geschätzt haben, sind sie wahrscheinlich genauer.

Kalibrieren Sie Ihre Referenz-Stories neu

Jedes Team hat Anker-Stories: "Erinnern Sie sich an diese Zahlungsintegration? Das war eine 8." Diese Anker wurden vor der KI gesetzt. Aktualisieren Sie sie. Führen Sie eine Neukalibrierungssitzung durch, bei der Sie 5-10 abgeschlossene Stories aus den letzten zwei Sprints neu schätzen. Verwenden Sie Ihr Planning Poker Tool und fragen Sie: "Wenn wir wissen, was wir jetzt darüber wissen, wie KI diese Art von Arbeit beeinflusst, wie würden wir das schätzen?" Die Lücken zwischen alten und neuen Schätzungen zeigen Ihnen genau, wo Ihre Kalibrierung falsch liegt.

Andere Messmethoden

Einige Teams bewegen sich komplett weg von Story Points, und die KI-Einführung beschleunigt diese Verschiebung. Cycle Time misst, wie lange ein Ticket von Anfang bis Ende dauert. Es umfasst den Review-Engpass und die Deployment-Pipeline, nicht nur, wie schnell jemand den Code geschrieben hat. Teams, die Cycle Time verfolgen, stellen fest, dass KI die Nadel bei der gesamten Liefergeschwindigkeit kaum bewegt, selbst wenn sich die Coding-Geschwindigkeit verdoppelt. Throughput zählt, wie viele Items das Team pro Sprint abschließt, unabhängig von der Größe. Wenn Ihr Team letzten Sprint 12 Stories und diesen Sprint 14 Stories ausgeliefert hat, sind das nützliche Informationen, ohne zu debattieren, was ein "Punkt" bedeutet. DORA-Metriken (Deployment-Frequenz, Lead Time, Change Failure Rate, Time to Restore) konzentrieren sich auf Ergebnisse statt auf Output. Wenn KI das Coding schneller macht, aber die Change Failure Rates steigen, weil weniger sorgfältig reviewt wird, zeigt DORA den Trade-off, den Velocity-Zahlen verbergen. Dashboard zeigt verschiedene Metriken nebeneinander, mit traditionellem Velocity-Chart im Vergleich zu Cycle-Time- und Throughput-Charts, die unterschiedliche Muster über die Team-Performance offenbaren Ron Jeffries, dem oft die Erfindung von Story Points zugeschrieben wird, hat gesagt: "Vielleicht habe ich Story Points erfunden, und wenn ja, tut es mir jetzt leid." Seine Sorge war, dass Punkte als Produktivitätsmaß missbraucht werden, anstatt als Planungswerkzeug. KI macht diesen Missbrauch schlimmer.

Was jetzt tatsächlich funktioniert

Basierend auf dem, was Teams Anfang 2026 berichten: Behalten Sie Planning Poker bei, aber ändern Sie die Konversation. Das Schätzungsmeeting ist immer noch wertvoll. Die Diskussion darüber, was in einer Story enthalten ist, ist wichtiger als die Zahl, die Sie zuweisen. Aber aktualisieren Sie die Fragen: "Wird KI dabei helfen?" sollte Teil der Konversation sein. Wenn eine Story hauptsächlich Boilerplate ist, sagen Sie es. Wenn es eine komplexe Integration ist, bei der KI irreführende Lösungen generieren wird, markieren Sie das ebenfalls. Behandeln Sie KI-generierten Code als ersten Entwurf, nicht als fertige Arbeit. Bauen Sie Review-Zeit in Ihre Schätzungen ein. Eine Story, bei der KI 80% des Codes geschrieben hat, könnte mehr Review-Zeit benötigen als eine, bei der ein Entwickler jede Zeile geschrieben hat, weil der Reviewer die Absicht verifizieren muss, nicht nur die Qualität. Achten Sie auf die Wahrnehmungslücke. Erinnern Sie sich an das METR-Ergebnis: Entwickler glaubten, 20% schneller zu sein, während sie tatsächlich 19% langsamer waren. KI zu verwenden fühlt sich produktiver an, weil das Generieren von Code kognitiv leichter ist als von Grund auf zu schreiben. Dieses Gefühl stimmt nicht immer mit der Uhr überein. Lassen Sie es nicht Ihre Sprint-Commitments aufblähen. Messen Sie, was Sie ausliefern, nicht was Sie coden. Wenn sich die Cycle Time Ihres Teams trotz schnellerem Coding nicht verbessert hat, ist der Engpass woanders. Beheben Sie das, bevor Sie sich um Story Points sorgen. Für Teams, die mit verschiedenen Schätzungsskalen experimentieren möchten, während sie neu kalibrieren, unterstützt Kollabe Fibonacci, T-Shirt-Größen und benutzerdefinierte Skalen, die Sie anpassen können, während Ihr Team herausfindet, was in einem KI-unterstützten Workflow funktioniert.

Dies ist ein Prozessproblem

Die Teams, die damit gut umgehen, haben kein KI-Schätzungstool gekauft. Sie erkannten, dass KI verändert hat, wie ihre Arbeit erledigt wird, und passten ihren Prozess an. Das beginnt mit ehrlichen Gesprächen darüber, wo KI hilft und wo nicht. Ihre Velocity von vor sechs Monaten ist keine nützliche Baseline mehr. Und die Lücke zwischen Coding-Output und tatsächlicher Lieferung war noch nie größer, also konzentrieren Sie sich auf die Lieferseite.

Nicht unbedingt. Story Points funktionieren immer noch als relatives Sizing-Tool für Team-Diskussionen und Sprint-Planung. Was Sie tun sollten, ist, Ihre Referenz-Stories neu zu kalibrieren und sicherzustellen, dass Ihr Team den ungleichmäßigen Einfluss der KI bei der Schätzung berücksichtigt.

Schätzen Sie den gesamten Lieferaufwand, nicht nur die Coding-Zeit. Eine Story, die 10 Minuten zum Coden braucht, aber 2 Stunden zum Reviewen und Testen, ist immer noch ein bedeutendes Stück Arbeit. Teilen Sie Ihr Denken zwischen Implementierung und Verifikation auf.

Bei routinemäßigen, gut definierten Aufgaben verringert sich die Lücke erheblich. Bei komplexer Arbeit, die architektonisches Urteilsvermögen erfordert, übertreffen Seniors immer noch, weil sie wissen, wann KI-Vorschläge falsch sind. Das echte Risiko besteht darin, dass Juniors KI-generierten Code ausliefern, ohne die Erfahrung, subtile Probleme zu erkennen.

Cycle Time und Throughput geben ein klareres Bild der Lieferungsperformance ohne die Kalibrierungskopfschmerzen. DORA-Metriken (Deployment-Frequenz, Lead Time, Change Failure Rate) erfassen Qualität neben Geschwindigkeit. Die meisten Teams profitieren davon, alle drei neben Velocity zu verfolgen, anstatt sie komplett zu ersetzen.