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

Das echte Ausmaß des Problems

Sprint-Schätzungen sind in vielen Software-Teams ein Problem, das sich alle zwei Wochen wiederholt.

Die Ursache ist bekannt: 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.

Was sich belegen lässt, und was nicht:

• 57,5 Prozent der professionellen Entwickler nutzen Jira (Stack Overflow Developer Survey 2024), die historische Datenbasis für KI-Schätzmodelle ist also in vielen Teams vorhanden, wird aber selten genutzt
• Wie hoch Carry-over-Raten typischerweise sind und wie viele Stunden Teams im Sprint-Planning verbringen, dazu haben wir keine belastbare Studie gefunden. Beides steht in eurem eigenen Tool: Carry-over im Sprint-Bericht, Planning-Dauer im Kalender
• Ob euer Team seine Velocity systematisch überschätzt, zeigt der Vergleich von geplanten und gelieferten Story Points der letzten fünf bis acht 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

¹ Keine Messwerte, sondern die Richtung, in die sich die Kennzahl bewegen soll. 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, mittel (3/5) Das Planning-Meeting ist der offensichtlichste Gewinn, aber er ist kleiner, als er klingt. Gespart wird höchstens die Schätzdiskussion, im Beispiel oben 48 Minuten für zwölf Tickets, und davon nur der Teil, bei dem sich Team und Vorschlag einig sind. Die Abweichungen sollen ja weiter diskutiert werden. Bei neun oder zehn Personen sind das trotzdem mehrere Personenstunden je Sprint, und sie fällt rhythmisch alle zwei Wochen an. Was bleibt, ist die wertvolle inhaltliche Diskussion, Abhängigkeiten, Prioritäten, Risiken, statt des Schätzrituals.

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 einen Teil des Codes generieren lässt, verschiebt sich der relative Aufwand, aber nicht im selben Verhältnis. Generierter Code ist nicht ausgelieferte Funktion, Review, Tests und Fehlersuche bleiben. McKinsey fand 2023 bei Aufgaben, die Entwickler als hochkomplex einstuften, weniger als 10 Prozent Zeitersparnis, bei Routineaufgaben deutlich mehr. 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 danebenliegen, bei Routine-Tickets eher zu hoch, bei komplexen kaum verändert.

Konkrete Werkzeuge, was wann passt

Die ehrliche Nachricht vorweg: Eine Story-Point-Schätzung je Ticket aus euren historischen Daten liefert keine der großen Plattformen ab Werk. Es gibt KI für Zusammenfassungen, Backlog-Zerlegung und Sprint-Befüllung, für die eigentliche Schätzung braucht ihr eine Marketplace-App, ein eigenes Modell oder den Prompt unten. Die Integration bedeutet in jedem Fall Konfigurationsarbeit, und die Anforderungen an die Datenqualität sind real.

Jira mit Rovo (ab Standard)

Rovo, früher Atlassian Intelligence, bietet Issue-Zusammenfassungen, ähnliche Issues und das Ausformulieren von Beschreibungen. Eine Story-Point-Schätzung aus euren Daten steckt nicht im Produkt, dafür braucht es eine App aus dem Atlassian Marketplace. Rovo und die EU-Datenresidenz sind inzwischen schon im Standard-Tarif enthalten, rund 7,91 US-Dollar je Nutzer und Monat. Premium kostet rund 14,54 US-Dollar und bringt vor allem teamübergreifende Planung.

ZenHub , GitHub-native Sprint-KI

ZenHub ist auf KI-gestützte Sprint-Planung zugeschnitten: 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. Eine Schätzung je Ticket ist das nicht, die Punkte vergibt weiter das Team. Der Teams-Tarif kostet 4,99 US-Dollar je Nutzer und Monat bei Jahreszahlung, 7,50 US-Dollar bei monatlicher, Enterprise gibt es auf Anfrage. 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 ein automatisches Rollover nicht abgeschlossener Issues. Velocity-Tracking läuft passiv. Sinnvoll als Einstieg für Teams, die schlanker planen wollen, ohne sofort in KI-Schätzung zu investieren. Basic kostet 10 US-Dollar je Nutzer und Monat, die KI-Triage gibt es erst im Business-Tarif für 16 US-Dollar.

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. Eine Story-Point-Schätzung liefert Copilot dort nicht. Der volle KI-Umfang (Backlog-Zerlegung, Repo-Chat, MCP-Server) setzt GitHub Copilot Enterprise voraus, 39 US-Dollar je Nutzer und Monat zusätzlich zur Azure-DevOps-Lizenz. 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, EU-Hosting nötig → Standard-Plan mit Rovo plus Marketplace-App für die Schätzung
• GitHub-natives Team, Sprint-Planung mit KI 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 bessere Antwort: 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. Das Risiko: Das Team committet schneller und merkt erst im Sprint, dass nicht alle dasselbe meinen. Dann sinkt die Carry-over-Rate nicht, sie verschiebt sich 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:

• Rovo ( Jira ): EU-Datenresidenz ist laut unserer Toolseite schon im Standard-Plan enthalten. AVV ist verfügbar. Den Datenschutzbeauftragten bindest du unabhängig von der Teamgröße ein.
• Betriebsrat: Gibt es einen, ist die Einführung mitbestimmungspflichtig, sobald das System die Leistung einzelner Personen auswerten kann. § 87 Abs. 1 Nr. 6 BetrVG nennt die “Einführung und Anwendung von technischen Einrichtungen, die dazu bestimmt sind, das Verhalten oder die Leistung der Arbeitnehmer zu überwachen”. Namentlich zugewiesene Tickets mit Schätz- und Ist-Werten sind genau solche Daten.
• 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 bietet eine EU-Datenresidenz nur im Enterprise-Tarif.
• 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 kostet ZenHub Teams 10 mal 4,99 US-Dollar im Monat bei Jahreszahlung. Jira Premium kostet 10 mal 14,54 US-Dollar, Standard 10 mal 7,91 US-Dollar, jeweils plus Marketplace-App für die Schätzung.

Rechnung mit den Zahlen aus dem Beispiel oben: Leas Team schätzt zwölf Tickets zu je 4 Minuten, 48 Minuten je Planning. Angenommen, bei der Hälfte der Tickets sind sich Team und Vorschlag sofort einig, dann entfallen rund 24 Minuten je Sprint, bei neun Personen 3,6 Personenstunden, bei gut zwei Sprints im Monat knapp 8 Personenstunden. Bei einem internen Stundensatz von 80 bis 120 € sind das 620 bis 940 € Kapazität im Monat, gegenüber Lizenzkosten von rund 50 bis 150 US-Dollar für zehn Personen. Dagegen stehen 2 bis 4 Wochen Datenbereinigung, bei einer Person 80 bis 160 Stunden oder 6.400 bis 19.200 € Kapazität, die diese Rechnung frühestens nach sieben Monaten einholt, im ungünstigen Fall nach über drei Jahren. Und die Rechnung setzt voraus, dass die eingesparte Zeit tatsächlich in produktive Arbeit fließt und nicht in andere Meetings. Im schlechten Fall, das Team trifft sich einfach kürzer, aber der Output bleibt gleich, ist der ROI rein qualitativ (bessere Planungsqualität, weniger Carry-over-Stress).

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.

Vier 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. Die Folge zeigt sich oft erst Monate später: schneller geschätzt, aber weniger gemeinsames Verständnis der Tickets, sichtbar als 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 länger als 2 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. Liegt die Carry-over-Rate konsequent über 20 Prozent?
3. Gibt es Sprint-Tickets, die als “Done” markiert sind, aber keine Story Points hatten?

Starke Schwankung und hohe Carry-over-Rate sprechen für den nächsten Schritt. Frage 3 prüft die Daten: Gibt es viele solche Tickets, kommt zuerst die Bereinigung, sonst lernt das Modell aus Lücken. Sind Schwankung und Carry-over niedrig, schätzt ihr 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

• Stack Overflow Developer Survey 2024: survey.stackoverflow.co/2024, rund 65.000 Befragte; Jira bei 57,5 % der professionellen Entwickler.
• Preise und Funktionen: unsere Toolseiten zu Jira (Stand Juni 2026, Rovo und EU-Datenresidenz ab Standard), ZenHub (Stand Juli 2026), Linear und Azure DevOps (Copilot Enterprise für den vollen KI-Umfang); Funktionsbeschreibungen Automated Sprint Planning und Predicted Sprints von zenhub.com.
• McKinsey, „Unleashing developer productivity with generative AI” (2023): Aufgabenkomplexität beeinflusst den KI-Produktivitätsgewinn erheblich, bei als hochkomplex eingestuften Aufgaben unter 10 % Zeitersparnis. mckinsey.com.
• BetrVG § 87 Abs. 1 Nr. 6: Mitbestimmung bei technischen Einrichtungen zur Überwachung von Verhalten oder Leistung, gesetze-im-internet.de.
• Eigene Annahmen: Zeitrahmen, Datenmengen, der Anteil übereinstimmender Schätzungen im Rechenbeispiel und die Kalibrierungsempfehlungen sind Einschätzungen der Redaktion, keine Messung.

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.