KI-gestützte Sprint-Planung und Aufwandsschätzung

Das echte Ausmaß des Problems

Sprint-Schätzungen sind in den meisten Software-Teams ein systemisches Versagen, das sich alle zwei Wochen wiederholt. Laut PMI Community-Led AI Survey 2024 (über 1.500 Projektmanager weltweit) nennen 61 Prozent der Befragten ungenaue Aufwandsschätzungen als eines der drei größten Hindernisse für Projektliefertreue — mehr als Ressourcenengpässe oder Scope-Creep.

Die Ursache ist gut dokumentiert: Story-Point-Schätzungen in Planning-Poker-Sessions sind nicht systematisch — sie sind soziale Prozesse. Wer laut spricht, beeinflusst das Ergebnis. Wer neu im Team ist, schätzt hoch. Wer optimistisch ist, schätzt niedrig. Wer die historische Velocity kennt, justiert still nach unten. Das Ergebnis ist eine Zahl, die wenig mit tatsächlichem Aufwand zu tun hat — und die das Team trotzdem committet.

Konkrete Zahlen aus der Praxis:

• Carry-over-Rate von 25–45 Prozent ist in Softwareteams ohne systematische Schätzunterstützung die Regel, nicht die Ausnahme (Erfahrungswerte aus der Atlassian State of Agile 2023)
• Entwicklungsteams verbringen laut Stack Overflow Developer Survey 2024 (65.000 Befragte) durchschnittlich 2–4 Stunden pro Woche in Sprint-Planning-Meetings — Schätzung und Backlog-Diskussion machen dabei den größten Block aus
• 57,5 Prozent der professionellen Entwickler nutzen Jira als primäres Projektmanagement-Tool (Stack Overflow 2024) — die historische Datenbasis für KI-Schätzmodelle ist also fast überall vorhanden, wird aber selten genutzt
• Studien zur agilen Schätzgenauigkeit zeigen, dass Teams ohne historische Kalibrierung ihre Velocity um 30–50 Prozent überschätzen — konsistent über viele Sprints

Was dabei verloren geht, ist nicht nur Planungszeit. Es ist das Vertrauen der Stakeholder. Wenn drei Sprints hintereinander 30 Prozent Carry-over anfallen, hören Produktmanager und Geschäftsleitung auf, Sprint-Commitments für bare Münze zu nehmen. Der Schaden ist kulturell — und schwerer zu reparieren als die ursprüngliche Schätzungenauigkeit.

Mit vs. ohne KI — ein ehrlicher Vergleich

¹ Eigene Erfahrungswerte und Herstellerangaben; keine repräsentative Studie. Effekte hängen stark von Datenbasis-Qualität und Team-Disziplin beim Schließen von Tickets mit Ist-Aufwänden ab.

Einschätzung auf einen Blick

Zeitersparnis — hoch (4/5) Das Planning-Meeting ist der offensichtlichste Gewinn: Wenn die KI Story-Point-Vorschläge liefert und die Kapazitätsrechnung bereits durchgeführt hat, schrumpft das Meeting von 3 Stunden auf 90 Minuten. Was bleibt, ist die wertvolle inhaltliche Diskussion — Abhängigkeiten, Prioritäten, Risiken — statt das Schätzritual. In Relation zu anderen Use Cases dieser Kategorie ist das einer der stärksten Zeithebel, weil Planning-Meetings rhythmisch alle zwei Wochen anfallen.

Kosteneinsparung — niedrig (2/5) Es gibt kaum direkte Kosteneinsparung. Die Entwicklungskapazität, die früher im Planning-Meeting steckte, wird jetzt anders genutzt — aber nicht weniger bezahlt. Der Wert liegt in besserer Planungsqualität, höherem Stakeholder-Vertrauen und weniger Nacharbeitsaufwand durch Carry-overs. Das ist real, aber schwer in Euro auszudrücken. Anders als bei der Automatischen Code-Review, wo gesparte Review-Zeit direkte Entwicklungskapazität freimacht, bleibt der ROI hier überwiegend qualitativ.

Schnelle Umsetzung — niedrig (2/5) Das ist der häufig unterschätzte Knackpunkt: KI-gestützte Sprint-Schätzung setzt mindestens 6–12 Monate sauber erfasste historische Daten voraus — mit konsistenten Story Points, abgeschlossenen Tickets mit Ist-Aufwänden und stabiler Teamzusammensetzung. Wer diese Voraussetzung erfüllt, kann in 8–12 Wochen pilotieren. Wer nicht erfüllt, hat erst ein Datenbasis-Problem. Das macht diese Einführung zu einer der langwierigeren in der it-software-Kategorie.

ROI-Sicherheit — mittel (3/5) Carry-over-Rate und Planning-Dauer sind messbar — das ist mehr Messbarkeit als bei vielen anderen KI-Projekten. Die Kausalitätsfrage ist aber nicht trivial: Wenn die Carry-over-Rate sinkt, ist es die KI oder wurde nebenbei die Ticket-Qualität verbessert? In der Praxis passiert meist beides gleichzeitig. Teams, die konsequent messen, sehen nach 3–6 Monaten real sinkende Abweichungen. Teams, die nicht messen, können den Effekt nicht belegen.

Skalierbarkeit — hoch (4/5) Das Modell wird mit jeder Sprint-Runde besser — mehr Daten bedeuten bessere Kalibrierung, mehr Teams bedeuten mehr Muster. Wer heute mit einem Team anfängt, hat nach 12 Monaten ein erheblich präziseres Modell als am Anfang. Für Unternehmen mit mehreren Entwicklungsteams bietet sich ein geteiltes Modell an, das teamübergreifende Muster erkennt — das ist ein echtes Skalierungsargument, das manuelle Schätzung nie erreichen kann.

Richtwerte — stark abhängig von historischer Datenbasis, Team-Konsistenz und Ticket-Qualität.

Was das Schätzsystem konkret macht

Das technische Fundament ist NLP kombiniert mit Regressionsmodellen. Das klingt komplizierter als es ist. In der Praxis läuft es so ab:

Schritt 1 — Historische Analyse: Das System liest alle abgeschlossenen Tickets der letzten 6–12 Monate ein: Titel, Beschreibung, Labels, Story-Point-Schätzung beim Planning, tatsächlicher Aufwand beim Abschluss, Sprint-Zugehörigkeit, Assignee-Team. Daraus baut es ein Team-spezifisches Muster: Welche Ticket-Typen werden systematisch unterschätzt? Welche Labels korrelieren mit hohem Aufwand? Welche Beschreibungslänge und -qualität korrelieren mit Schätzgenauigkeit?

Schritt 2 — Ähnlichkeitsmatching: Wenn ein neues Ticket im Backlog erscheint, findet das System die historisch ähnlichsten abgeschlossenen Tickets — nicht nach Stichwörtern, sondern nach semantischer Ähnlichkeit der Beschreibung. Es schlägt eine Story-Point-Range vor: “Ähnliche Tickets hatten 3–5 Punkte, Median war 4.”

Schritt 3 — Kapazitätsprognose: Das System berechnet, wie viele Story Points das Team in den kommenden Sprint realistisch liefern kann, auf Basis der letzten 5–8 Sprints, der geplanten Verfügbarkeit (Urlaube, Feiertage) und historischer Abweichungsmuster (z.B. Sprints mit Incidents haben typisch 20 Prozent weniger Output).

Was es nicht ersetzt: Die inhaltliche Diskussion im Planning bleibt. Ob Ticket A vor Ticket B kommt, ob Feature X gerade strategisch sinnvoll ist, ob die Beschreibung vollständig genug ist — das ist Teamarbeit, kein Algorithmus. Das System gibt eine Schätz-Baseline, keine Entscheidung.

Die Story-Points-vs.-Stunden-Debatte: Was KI dazu verändert

KI-gestützte Schätzung zündet am besten auf Story Points — weil Story Points relative Komplexität abbilden und sich gut zu historischen Mustern in Relation setzen lassen. Stunden dagegen sind präziser, aber über Sprints weniger stabil.

Gleichzeitig stellt die wachsende Verbreitung von KI-Coding-Tools wie GitHub Copilot das Story-Point-Modell vor ein neues Problem: Wenn ein Entwickler mit Copilot 40 Prozent der Implementierung automatisch generiert, stimmt der “relative Aufwand” nicht mehr. Das Feature, das früher 8 Punkte wert war, ist jetzt vielleicht 4. Das verändert die Velocity — aber nicht gleichmäßig für alle Ticket-Typen.

Was das praktisch bedeutet: Wenn dein Team KI-Coding-Tools intensiv nutzt, solltest du das Sprint-Schätzmodell mindestens alle 6 Monate neu kalibrieren. Historische Datenpunkte aus der Vor-KI-Ära spiegeln ein anderes Effort-Profil wider. Wer diese Kalibrierung vergisst, bekommt Schätzvorschläge, die systematisch zu hoch sind.

Integration in Jira, Linear und Azure DevOps — die Realität

Die gute Nachricht: Alle drei großen Plattformen bieten inzwischen KI-Schätzfunktionen — als eingebautes Feature oder über Plugins. Die schlechte Nachricht: Die Integration bedeutet in jedem Fall Konfigurationsarbeit, und die Datenqualität-Anforderungen sind real.

Jira mit Atlassian Intelligence (Premium/Enterprise)

Atlassian Intelligence (jetzt als Teil von Rovo positioniert) bietet Issue-Summarisierung, ähnliche Issue-Vorschläge und automatisches Ausformulieren von Beschreibungen. Eine dedizierte Story-Point-Schätz-KI ist noch nicht im Core-Produkt (Stand April 2026) — aber über Marketplace-Apps wie “Smart Estimation” oder Drittanbieter wie ZenHub erreichbar. Für die direkte KI-Schätzung in Jira gilt: Atlassian Premium ist Pflicht (ca. 15,25 USD/Nutzer/Monat), EU-Datenresidenz nur ab Premium verfügbar. Wer auf dem Standard-Plan ist, hat kein EU-Hosting.

ZenHub — GitHub-native Sprint-KI

ZenHub ist aktuell der ausgereifteste Ansatz für rein KI-gestützte Sprint-Planung: Automated Sprint Building befüllt Sprints auf Basis von Velocity und Backlog-Priorität, Predicted Sprints zeigt 8 Sprints voraus, AI Sprint Reviews generieren Zusammenfassungen ohne manuellen Aufwand. Der Preis: ca. 12,50 USD/Nutzer/Monat. Wichtige Einschränkung: ZenHub lebt in GitHub — wer Jira nutzt, muss entweder migrieren oder parallel arbeiten. Kein EU-Datenhosting.

Linear — einfacher Einstieg, begrenzte KI-Schätztiefe

Linear hat keine eigenen KI-Story-Point-Vorschläge, aber eine hervorragende PlanningPoker.live-Integration und automatisches Rollover nicht abgeschlossener Issues. Velocity-Tracking läuft passiv. Sinnvoll als Einstieg für Teams, die den Jira-Overhead loswerden wollen, ohne sofort in KI-Schätzung zu investieren. Preis: ab 8 USD/Nutzer/Monat.

Azure DevOps mit GitHub Copilot

Für Microsoft-geprägte Unternehmen: Azure DevOps Boards integriert seit 2025 GitHub Copilot für Backlog-Zerlegung und Task-Generierung. Vollständige KI-Schätzfunktionen für Boards erfordern GitHub Copilot Enterprise (ab 19 USD/Nutzer/Monat). Vorteil: EU-Datenhosting verfügbar. Für Teams, die bereits Azure und GitHub nutzen, ist das der natürlichste Weg.

Zusammenfassung — wann welcher Ansatz:

• Jira-Team, Premium-Plan, EU-Hosting nötig → Atlassian Intelligence/Rovo + Marketplace-Plugin
• GitHub-natives Team, KI-Schätzung im Fokus → ZenHub
• Team will Jira-Komplexität reduzieren, kein EU-Hosting-Zwang → Linear
• Microsoft-Ökosystem (Azure, Teams) → Azure DevOps + GitHub Copilot

Planning Poker ersetzen oder ergänzen?

Das ist die praktisch wichtigste Designentscheidung: Ersetzt KI das Planning Poker — oder macht sie es besser?

Die Antwort der meisten Teams, die es ernsthaft probiert haben: Ergänzen, nicht ersetzen. Hier ist der Grund:

Planning Poker hat einen unsichtbaren zweiten Nutzen, der mit “Schätzung” nichts zu tun hat: Es erzwingt, dass jedes Teammitglied ein Ticket versteht, bevor eine Zahl fällt. Wer sich nicht traut, “2” zu sagen, ohne zu erklären warum, hat das Ticket nicht verstanden. Der Dissens — wenn Jonas 3 nennt und Marie 8 — ist kein Effizienzproblem. Er ist ein Erkenntnismoment: Es gibt unterschiedliche Vorstellungen davon, was dieses Ticket bedeutet.

Wer Planning Poker vollständig durch KI-Schätzvorschläge ersetzt, verliert diesen Mechanismus. Teams, die das beschreiben, sagen nach einigen Monaten: “Wir committen jetzt schneller, aber merken im Sprint, dass wir gar nicht dasselbe meinen.” Die Carry-over-Rate sinkt nicht — sie verschiebt sich nur in Rework während des Sprints.

Das produktive Modell: KI liefert die Startposition. Das Team diskutiert nur noch Abweichungen. Wenn alle vier Personen für Ticket X “5” nennen und die KI hat auch 5 vorgeschlagen — done, 30 Sekunden. Wenn Jonas 2 sagt und Marie 8 sagt — das ist die Diskussion, die stattfinden muss. Die KI hilft, sinnlose Schätzdebatten zu eliminieren, ohne die sinnvollen zu unterdrücken.

Datenschutz und Datenhaltung

Sprint-Daten enthalten in der Regel keine klassisch personenbezogenen Daten im DSGVO-Sinne — keine Namen von Endkunden, keine medizinischen Daten. Aber sie enthalten Arbeitsleistungsdaten: Wer hat wann wie viele Story Points geschätzt, wer hat sie tatsächlich geliefert, wer hat Tickets nicht abgeschlossen?

Das ist nach DSGVO Art. 4 Nr. 1 personenbezogen, sobald es einer natürlichen Person zugeordnet werden kann — und das ist bei namentlich zugewiesenen Jira-Tickets immer der Fall.

Konkrete Konsequenzen:

• Atlassian Intelligence (Jira): EU-Datenresidenz nur ab Premium-Plan. Standard-Plan verarbeitet Daten auf US/Australien-Servern. AVV ist verfügbar, aber die physische Verarbeitung bleibt US-seitig. Für Teams mit mehr als 50 Personen: Datenschutzbeauftragten einbinden.
• ZenHub: Kein EU-Hosting, Verarbeitung in den USA. Für US-Datenverarbeitung von Mitarbeiterdaten DSGVO-Compliance durch AVV sicherstellen — aber das physische Hosting bleibt US-seitig.
• Azure DevOps: EU-Datenhosting wählbar (West Europe / Germany North). Für DSGVO-sensible Umgebungen die Region bewusst wählen. GitHub Copilot Enterprise hat eigene Datenschutzkonfigurationen.
• On-premise-Schätzmodelle: Für Unternehmen mit hohen Datenschutzanforderungen ist ein selbst gehostetes ML-Modell (Python + sklearn, lokal trainiert auf exportierten Jira-Daten) eine valide Option. Keine Cloud-Verarbeitung, vollständige Datenkontrolle. Erfordert aber Entwicklerarbeit für Aufbau und Wartung.

Wichtig vor dem Produktivbetrieb: AVV mit dem jeweiligen Anbieter unterzeichnen. Bei Atlassian und Azure selbstbedient im Admin-Portal verfügbar.

Was es kostet — realistisch gerechnet

Einmalige Einrichtungskosten

Der größte initiale Aufwand ist nicht die Software — es ist die Datenbasis-Qualität. Teams, die Story Points nicht konsistent gepflegt haben (offene Tickets ohne Abschluss-Aufwand, wechselnde Definitionen, fehlende Labels), investieren 2–4 Wochen Bereinigung, bevor ein Modell sinnvolle Ergebnisse liefert.

• Datenbasis-Analyse und -Bereinigung: 2–4 Wochen interner Aufwand
• KI-Plugin-Setup (ZenHub, Atlassian Intelligence, Azure DevOps Copilot): 1–3 Tage Konfiguration
• Pilotphase (1 Sprint), Review, Anpassung: weitere 2–4 Wochen

Laufende Kosten (monatlich, pro Nutzer)

Für ein 10-köpfiges Team mit ZenHub Enterprise: ca. 125 USD/Monat (rund 115 Euro). Mit Jira Premium: ca. 152 USD/Monat. Diese Kosten sind für ein Entwicklungsteam, das 2–4 Stunden/Woche mit Sprint-Planning verbringt, innerhalb weniger Monate durch eingesparte Meeting-Zeit amortisiert.

Wie du den Nutzen tatsächlich misst

Drei Kennzahlen, die du vor und nach der Einführung verfolgst:

1. Carry-over-Rate: Prozent der Sprint-Tickets, die nicht im Sprint abgeschlossen werden
2. Planning-Meeting-Dauer: Tatsächlich gezeitete Dauer vom Start bis zum Sprint-Commit
3. Schätz-zu-Ist-Abweichung: Durchschnittliche Differenz zwischen geschätzten und tatsächlichen Story Points pro Ticket

Lass mindestens 3 Sprints mit KI-Unterstützung ablaufen, bevor du die Werte vergleichst. Das erste Sprint setzt du als Baseline — da passt sich das Team noch an.

Typische Einstiegsfehler

1. Mit einem zu kleinen Datensatz starten. Ein Team, das seit 3 Monaten Scrum macht, hat vielleicht 80–120 abgeschlossene Tickets. Das ist zu wenig, um belastbare Muster zu erkennen — besonders für seltene Ticket-Typen. Ein KI-Modell, das auf 80 Datenpunkten trainiert wurde, liefert Schätzvorschläge, die nicht besser sind als die der erfahrensten Person im Team. Warte auf mindestens 200–300 abgeschlossene Tickets mit Ist-Aufwänden.

2. Planning Poker vollständig abschaffen. Teams, die Planning Poker durch KI-Schätzungen ersetzen statt sie zu ergänzen, verlieren den Alignment-Mechanismus. Sechs Monate später berichten sie: “Wir schätzen schneller, aber wir haben weniger gemeinsames Verständnis der Tickets.” Das zeigt sich in mehr Rework im Sprint — nicht in der Carry-over-Rate, sondern in der Qualität. Halte Planning Poker für Tickets mit hoher Abweichung zwischen KI-Vorschlag und Team-Intuition.

3. Das Modell nie nachkalibrieren. Das ist der Wartungsfehler, der alle anderen obsolet macht. Nach 6 Monaten mit KI-Coding-Tools im Team, nach einem größeren Refactoring, nach Teamwechseln — das historische Muster, auf dem das Modell aufgebaut wurde, gilt nicht mehr. Wer keine Kalibrierungs-Routine einplant (mindestens halbjährlich), hat nach einem Jahr ein Modell, das systematisch falsch liegt — und das niemand hinterfragt, weil es so selbstverständlich geworden ist.

4. Ticket-Qualität als Voraussetzung ignorieren. KI-Schätzmodelle sind so gut wie die Ticket-Beschreibungen, die sie einlesen. Ein Ticket mit dem Titel “Bug fix” und keiner Beschreibung erzeugt keinen validen Vorschlag. Teams, die keine Definition of Ready haben (was muss ein Ticket enthalten, bevor es ins Sprint Planning kommt?), werden frustriert sein: Das Modell kann Ähnlichkeit nur finden, wenn die Tickets beschreibend genug sind. Einführung von KI-Schätzung und Verbesserung der Ticket-Qualität müssen Hand in Hand gehen.

Historische Datenbasis als Voraussetzung

Dies verdient eine eigene Betrachtung, weil es der häufigste Grund ist, warum KI-Schätzprojekte scheitern oder enttäuschen.

Mindestanforderungen für ein arbeitsfähiges Modell:

• Mindestens 200 abgeschlossene Tickets mit Story-Point-Schätzung beim Planning und tatsächlichem Abschluss-Status
• Tickets über mindestens 6 Monate verteilt (um Saisonalität und Teamveränderungen abzubilden)
• Konsistente Story-Point-Skala: Wenn das Team zwischen Fibonacci (1, 2, 3, 5, 8, 13) und T-Shirt-Sizes (S/M/L/XL) gewechselt hat, müssen die Daten normiert werden
• Mindestens 70 Prozent der Tickets abgeschlossen (nicht nur “In Progress” oder “Closed without Done”) — Tickets, die ohne Aufwandserfassung geschlossen wurden, rauschen nur

Was tun, wenn diese Basis fehlt?

Dann ist KI-Schätzung noch nicht dran. Stattdessen:

1. Führe konsistente Story Points ein, falls noch nicht vorhanden
2. Stelle sicher, dass alle Tickets beim Abschluss korrekt erfasst werden (Done, nicht “Abgebrochen” ohne Begründung)
3. Führe eine Velocity-Tracking-Routine ein (das kann jedes Jira/Linear/Azure DevOps ohne KI)
4. Komm nach 6 Monaten wieder auf das Thema zurück

Der Zeitaufwand für diesen Vorbereitungsschritt zahlt sich doppelt aus: Auch ohne KI verbessert sich die Sprint-Planungsqualität durch bessere Ticket-Disziplin signifikant.

Was mit der Einführung wirklich passiert — und was nicht

Die erste Reaktion des Teams

In fast jeder Einführung gibt es in der ersten Woche eine Fraktion: “Das Modell liegt falsch.” Es schlägt 5 Punkte vor, das Team findet, es sind 3. Das passiert. Das Modell ist nicht unfehlbar — es ist ein Ausgangspunkt, kein Orakel. Wenn das Team systematisch und begründet von den Vorschlägen abweicht, ist das wertvoll: Diese Abweichungen sind der Lernimpuls für das Modell.

Das Widerstandsmuster: Die erfahrenen Schätzer

In jedem Team gibt es eine oder zwei Personen, die durch jahrelange Erfahrung ein intuitives Gefühl für Aufwandsschätzungen entwickelt haben. Für diese Menschen fühlt sich ein KI-System, das ihre Intuition in Frage stellt, respektlos an. “Ich weiß, wie lange das dauert.” Der produktive Umgang: Diese Personen sind exakt die richtigen Kandidaten für die Modell-Kalibrierung. Wenn Janina immer besser schätzt als das Modell — was sind ihre Heuristiken? Die können explizit gemacht und ins Modell integriert werden.

Was nicht passiert: Vollautomatisches Sprint-Planning

Niemand geht in ein Meeting und sagt: “Der Sprint ist fertig, die KI hat ihn gebaut.” Das ist nicht das Ziel und würde in der Praxis scheitern, weil Prioritäten, Abhängigkeiten und strategische Ziele nicht im historischen Datenmodell stecken. Die KI übernimmt den Rechenaufwand. Die Entscheidung bleibt beim Team.

Was konkret hilft:

• Erste zwei Sprints: KI-Vorschläge zeigen, aber explizit fragen “Warum weichen wir ab?” — das schult die Skepsis und den kritischen Umgang
• Monate 2–3: Wenn die Abweichungsrate sinkt, sieht das Team den Effekt — das ist der natürliche Überzeugungsmoment
• Dauerhaft: Einen “Schätz-Retrospektive”-Slot in der regulären Retrospektive einbauen: Wo lag das Modell falsch und warum?

Realistischer Zeitplan mit Risikohinweisen

Häufige Einwände — und was dahintersteckt

“Wir schätzen doch schon, warum brauchen wir da KI?” Stimmt — aber die entscheidende Frage ist: Sind die Schätzungen kalibriert? Kalibriert bedeutet: Die historische Abweichung zwischen Schätzung und tatsächlichem Aufwand liegt konsistent unter 20 Prozent. Wenn das der Fall ist, stimmt der Einwand. Wenn die Carry-over-Rate über 20 Prozent liegt oder Planning-Meetings regelmäßig 3+ Stunden dauern, ist das ein Zeichen, dass die Kalibrierung fehlt. KI ersetzt dann nicht das Schätzen, sondern gibt der Team-Intuition eine empirische Grundlage.

“Das macht das Team abhängig von einem System — wir verlieren die Intuition.” Das ist ein realer Einwand — und einer, der ernst genommen werden muss. Wenn das Team KI-Vorschläge nie hinterfragt, verkümmert die Schätz-Intuition tatsächlich. Das Gegenmittel: Explizit machen, was das System macht. Wenn die KI 5 Punkte vorschlägt und das Team 3 vergibt — warum? Das Verargumentieren der Abweichung hält die Intuition scharf. Teams, die KI als Hilfsmittel nutzen statt als Orakel, entwickeln Schätz-Intuition schneller, weil sie laufend Feedback über ihre Abweichungen bekommen.

“Unsere Tickets sind zu individuell — historische Muster helfen nicht.” Gilt für hochindividuelle Forschungsprojekte oder Greenfield-Architekturen. Gilt nicht für die meisten Software-Teams, die ähnliche Feature-Typen immer wieder entwickeln: CRUD-Features, Integrationen, Bugfixes, Refactorings, Tests. Selbst wenn jedes Ticket einmalig ist, gibt es in der Beschreibung und im Typ genug Ähnlichkeit, um Muster zu erkennen. Wer wirklich keine Musterkategorien hat, hat kein Schätzproblem — der hat ein anderes Problem.

Woran du merkst, dass das zu dir passt

Zeichen, dass du bereit bist:

• Dein Team macht seit mindestens 6 Monaten konsequent Sprints mit Story Points — und hat abgeschlossene Tickets mit nachvollziehbarem Status
• Sprint-Planning dauert regelmäßig mehr als 2 Stunden, und ein erheblicher Teil davon ist die Schätzdiskussion, nicht die Priorisierungsdiskussion
• Die Carry-over-Rate liegt konsistent über 20 Prozent und niemand weiß genau, warum
• Stakeholder zweifeln an Sprint-Commitments, weil zu viele Commitments nicht eingehalten wurden
• Ihr habt Jira, ZenHub, Linear oder Azure DevOps als primäres Planungstool — die Datenbasis ist also vorhanden

Harte Ausschlusskriterien — wann es sich nicht lohnt:

1. Teams mit weniger als 6 Monaten konsistenter Sprint-Geschichte und unter 200 abgeschlossenen Tickets. Kein Datenfundament, keine verlässlichen Muster. Erst die Datendisziplin einführen — Story Points, konsistentes Closing, Velocity-Tracking — und nach 6 Monaten wiederkommen. KI auf schlechten Daten liefert schlechte Ergebnisse mit falscher Konfidenz.

2. Teams ohne Ticket-Qualitätsstandard (Definition of Ready). Wenn Tickets regelmäßig ohne Beschreibung ins Sprint Planning kommen, kann kein Ähnlichkeitsmodell greifen. Erst eine Definition of Ready einführen und für 3 Sprints durchhalten. Dann Schätz-KI drauflegen.

3. Teams, die Story Points bereits aufgegeben haben oder nie ernsthaft genutzt haben. Das betrifft insbesondere Teams, die bereits zu striktem Timeboxing oder “No Estimates”-Ansätzen gewechselt sind. KI-Schätzmodelle setzen relative Komplexitätsbewertungen voraus. Wer auf Basis von Durchlaufzeit plant statt von Story Points, profitiert von einem anderen Ansatz (Kanban-Flow-Analyse statt Sprint-Estimation-KI).

Das kannst du heute noch tun

Bevor du ein Tool einführst: Mach ein 30-Minuten-Audit eurer Jira- oder Linear-Datenbasis. Öffne die Velocity-Ansicht (in Jira unter Berichte → Velocity) und schau dir die letzten 5–8 Sprints an.

Drei Fragen:

1. Wie stark schwankt die tatsächlich abgelieferte Velocity von Sprint zu Sprint?
2. Gibt es Sprint-Tickets, die als “Done” markiert sind, aber keine Story Points hatten?
3. Liegt die Carry-over-Rate konsequent über 20 Prozent?

Wenn du auf zwei dieser drei Fragen mit “Ja” antwortest, lohnt sich der nächste Schritt. Wenn nicht — ihr schätzt schon gut genug, und das Geld ist woanders besser investiert.

Für den nächsten Sprint-Planning-Termin: Schicke deinem Team diesen Prompt, der auf der letzten Retro-Diskussion aufbaut:

Quellen & Methodik

• PMI Community-Led AI and Project Management Survey 2024: Project Management Institute, „Artificial Intelligence and Project Management — A Global Chapter-Led Survey” (2024). Über 1.500 Befragte weltweit; 61 % nennen Schätzungsungenauigkeit als Top-3-Hindernis. Download: pmi.org (PDF öffentlich verfügbar).
• Stack Overflow Developer Survey 2024: stackoverflow.co/2024. 65.000 Befragte; Jira bei 57,5 % der professionellen Entwickler; 76 % nutzen oder planen KI-Tools im Entwicklungsprozess (Stand: Juni 2024).
• Atlassian State of Agile 2023: Atlassian-eigene Studie zu agilen Entwicklungspraktiken; Carry-over-Raten 25–45 % ohne systematische Schätzunterstützung. Veröffentlicht auf atlassian.com.
• Scrum.org Forum-Diskussion, 2024: „How to approach story point estimation with advent of AI Dev acceleration tools?” — Mehrere Scrum-Practitioners beschreiben den Verlust von Team-Alignment nach vollständiger Abschaffung von Planning Poker. scrum.org/forum.
• ZenHub-Produktseiten (April 2026): Preisangaben (Starter 8 USD/Nutzer, Enterprise 12,50 USD/Nutzer/Monat), Feature-Beschreibungen Automated Sprint Planning und Predicted Sprints. zenhub.com/pricing.
• Atlassian-Preisseite (April 2026): Jira Standard 7,75 USD/Nutzer/Monat, Jira Premium 15,25 USD/Nutzer/Monat, EU-Datenresidenz nur ab Premium. atlassian.com/de/software/jira.
• McKinsey, „Unleashing developer productivity with generative AI” (2023): Aufgabenkomplexität beeinflusst KI-Produktivitätsgewinn erheblich — bei hochkomplexen Tasks unter 10 %; relevant für Story-Point-Kalibrierung bei KI-Coding-Teams. mckinsey.com.
• Erfahrungswerte: Implementierungskosten, Zeitrahmen und Kalibrierungsempfehlungen basieren auf Erfahrungswerten aus agilen Teams mit 8–50 Mitarbeitenden (Stand April 2026).

Du willst wissen, ob eure Jira-Datenbasis für KI-Schätzung ausreicht und wie ihr am besten startet? Meld dich — das klären wir in einem kurzen Gespräch.