Sprint Retrospective und KI: Warum Verbesserungen nicht an das Modell delegiert werden dürfen

Dies ist der fünfte Artikel aus der Serie darüber, wie KI die klassischen Meetings eines cross-funktionalen Entwicklungsteams verändert. In den vorherigen Teilen habe ich Backlog Refinement, Sprint Planning, Daily Scrum und Sprint Reviewbehandelt. Die Gesamtschlussfolgerung wird allmählich strenger: KI sammelt gut den Input für das Gespräch, sollte aber nicht das Gespräch selbst ersetzen. In der Sprint Retrospective ist diese Grenze besonders wichtig, weil das Team hier nicht nur Aufgaben und Produkt bespricht, sondern eigene Gewohnheiten, Interaktionen, Qualität und die Fähigkeit zur Veränderung.

Die Sprint Retrospective scheint ein sehr bequemer Kandidat für KI zu sein. Am Ende des Sprints gibt es bereits Jira, Git, Pull Requests, CI/CD, Vorfälle, Chats, Kalender, Notizen vom Daily Scrum, Entscheidungen aus dem Sprint Review, manchmal auch kurze Teamumfragen. Das Modell kann schnell zusammenstellen: was die Arbeit am häufigsten gebremst hat, wo Review-Bottlenecks hingen, welche Aufgaben von Tag zu Tag wanderten, wo die Definition of Done unklar blieb, welche Entscheidungen sich wiederholten, welche Themen in früheren Retros auftauchten und nicht verschwunden sind.

Auf den ersten Blick ist das eine fast ideale Automatisierung. Man muss sich nicht den gesamten Sprint erneut ins Gedächtnis rufen. Man muss nicht darüber streiten, ob das Warten auf Review ein echtes Problem war oder nur jemandes Gefühl. Man muss nicht manuell Dutzende Tickets und Diskussions-Threads durchsehen. KI kann Fakten vorbereiten, Muster gruppieren, eine Root-Cause-Analyse vorschlagen und sogar Action Items für den nächsten Sprint generieren.

Aber genau hier beginnt das größte Risiko.

Die Sprint Retrospective existiert nicht, um eine ordentliche Liste von Verbesserungen zu erhalten. Ihr Sinn besteht darin, dass das Team ehrlich sieht, wie es arbeitet, sich darauf einigt, was geändert werden sollte, und Verantwortung für diese Änderung übernimmt. Wenn KI die Retros in eine Liste von Empfehlungen verwandelt, kann das Team ein schönes Dokument erhalten und das Wichtigste verlieren: psychologische Sicherheit, gemeinsames Verständnis des Problems und echtes Follow-through.

„KI kann Muster hervorheben, aber Verbesserung beginnt erst dann, wenn das Team das Problem anerkennt und sein Verhalten ändert.“

Wozu die Sprint Retrospective dient

Im Scrum Guide 2020 wird die Sprint Retrospective sehr praktisch beschrieben: Das Team plant Wege, um Qualität und Effektivität zu steigern. Dafür inspiziert das Scrum Team, wie der Sprint aus Sicht von Menschen, Interaktionen, Prozessen, Werkzeugen und Definition of Done verlief. Das Team bespricht, was gut lief, welche Probleme auftraten und wie diese Probleme gelöst wurden oder nicht. Danach bestimmt es die nützlichsten Änderungen, und die bedeutendsten Verbesserungen sollten so bald wie möglich adressiert werden und können in das Sprint Backlog des nächsten Sprints gelangen.

Das heißt, die Retrospektive ist keine emotionale Entlastung am Ende des Sprints. Und sie ist keine formale Zeremonie, bei der drei Spalten ausgefüllt werden müssen: was war gut, was war schlecht, was verbessern wir. Dieses Event dreht sich um die Anpassung der Arbeitsweise. In diesem Sinne ist es direkt mit der allgemeinen Logik von Scrum verbunden: Transparenz ist für die Inspektion nötig, Inspektion ist für die Anpassung nötig, und Inspektion ohne Anpassung wird leer. Der Scrum Guide betont ausdrücklich: Die Scrum-Events sind so konzipiert, dass sie Veränderung provozieren und nicht einfach Protokolle produzieren.

Als zusätzliche Orientierung ist der Scrum Guide Expanded v2026.1nützlich, aber genau als Companion-Quelle auf Basis des Scrum Guide 2020, nicht als neue kanonische Version des Scrum Guide. Für diesen Artikel ist er aus zwei Gründen wichtig. Erstens sagt er, dass Reflexion in einer psychologisch sicheren Umgebung effektiver ist. Zweitens beschreibt er im Abschnitt über KI das Modell als supervised decision-making partner: KI kann Transparenz, Inspektion und Anpassung verstärken, ersetzt aber nicht die menschliche Verantwortung und hebt die empirische Kontrolle des Prozesses nicht auf.

Deshalb würde ich den Zweck der Sprint Retrospective über fünf Funktionen beschreiben:

• echte Muster der Teamarbeit sehen, nicht nur die lautesten Meinungen;
• Interaktionen, Prozesse, Werkzeuge und Definition of Done ohne Angst vor Bestrafung besprechen;
• Fakten von Interpretationen und Vermutungen trennen;
• eine kleine Anzahl von Verbesserungen auswählen, die das Team wirklich bereit ist auszuprobieren;
• diese Verbesserungen so in den nächsten Sprint übertragen, dass sie einen Owner, ein Prüfkriterium und einen Platz in der Arbeit haben.

Das ist der Rahmen für das Gespräch über KI. Wenn ein Werkzeug dem Team hilft, diese Funktionen besser zu erfüllen, ist es nützlich. Wenn es einfach eine schönere Liste von Action Items erzeugt, kann es bequem sein, macht das Team aber nicht unbedingt effektiver.

Was gewöhnlich schiefgeht

Das Problem mit Retrospektiven liegt selten darin, dass das Team keine Probleme benennen kann. Meist sind die Probleme andere. Das Team diskutiert wieder dasselbe. Action Items wandern von Sprint zu Sprint. Die Leute reden vorsichtig, weil sie nicht schuldig wirken wollen. Die schmerzhaftesten Themen werden umgangen. Der Scrum Master zieht das Format durch, aber nicht die Veränderung. Am Ende stimmen alle etwas wie „lasst uns besser kommunizieren“ zu, und das löst sich schon in der nächsten Woche auf.

Die Studie von Lehtinen, Itkonen und Lassenius in Empirical Software Engineering beleuchtet diese Seite von Retrospektiven gut. Die Autoren untersuchten 37 Team-Retrospektiven über fast drei Jahre und zeigten mehrere wichtige Dinge: Diskussionen betreffen oft Themen, die dem Team nahe und von ihm steuerbar sind, können aber unter Participant Bias leiden; ohne Hard Evidence spiegeln sie nicht immer die Realität wider; manche Themen wiederholen sich lange, weil sie entweder natürlich zurückkehren oder das Team sie auf seiner Ebene wegen Komplexität oder fehlender Kontrollierbarkeit nicht lösen kann.

Das ist ein sehr nützliches Rahmenwerk für KI. Das Modell kann tatsächlich helfen, Hard Evidence dorthin zu bringen, wo früher nur ein Gefühl war. Zum Beispiel sagt das Team: „Reviews bremsen den Sprint.“ KI kann Fakten aufbringen: wie viele PRs länger als einen Tag warteten, welche genau hingen, welche Kommentare sich wiederholten, wo es Nacharbeit nach dem Merge gab. Das ist nützlicher, als aus dem Gedächtnis zu streiten.

Aber dasselbe Rahmenwerk hat eine Kehrseite. Wenn das Team nicht über die unbequeme Ursache sprechen will, macht KI es nicht ehrlicher. Wenn das Problem außerhalb des Einflussbereichs des Teams liegt, kann das Modell ein Action Item schön formulieren, das trotzdem niemand umsetzen wird. Wenn die Leute dem Kontext nicht vertrauen, werden sie nicht mehr über den Prozess streiten, sondern darüber, ob KI ihre Arbeit korrekt beschrieben hat.

Wo KI wirklich hilft

KI hat in der Sprint Retrospective eine starke Nutzenzone, wenn man nicht versucht, ihr die Verbesserung selbst zu übertragen. Ich würde sie vor der Retrospektive und nach der Retrospektive einsetzen, nicht statt der Retrospektive.

Aber hier ist es wichtig, nicht zu viel zu versprechen. DORA State of AI-assisted Software Development 2025 beschreibt KI als Verstärker der bestehenden Stärken und Schwächen des organisationalen Systems. Für die Retrospektive ist das eine fast ideale Formulierung: Wenn das Team bereits ehrlich über den Prozess diskutieren und Verbesserungen bis zur Aktion bringen kann, macht KI den Input reicher. Wenn die Retrospektive längst ein sicheres Ritual ohne Follow-through geworden ist, macht KI dieses Ritual einfach schneller und ordentlicher.

Vor dem Meeting kann KI einen Input für die Inspektion vorbereiten:

• wiederkehrende Impediments aus Daily Scrum, Tickets, Pull Requests und Incident Notes sammeln;
• Stellen finden, an denen Work Items lange auf Review, Testdaten, eine Entscheidung des Product Owners oder eine externe Abhängigkeit warteten;
• den Plan aus dem Sprint Planning mit den tatsächlichen Entscheidungen während des Sprints und dem Ergebnis vergleichen, das im Sprint Review besprochen wurde;
• Abweichungen zwischen Definition of Done und der Art, wie das Team Aufgaben tatsächlich abgeschlossen hat, hervorheben;
• alte Action Items sammeln und zeigen, welche davon erledigt, vergessen oder wiederholt wurden;
• Kandidatenfragen für das Gespräch formulieren: Was war Fakt, was Interpretation, und was muss überprüft werden.

Nach dem Meeting kann KI beim Follow-through helfen: ausgewählte Action Items sorgfältig festhalten, Owner, Prüfkriterium, Verknüpfung mit dem Sprint Backlog und Erinnerung für die nächste Retrospektive ergänzen. Das ist besonders wertvoll, weil die Schwachstelle vieler Retros nicht in der Diskussion liegt, sondern darin, dass Verbesserungen den nächsten Sprint nicht überleben.

Aber in all diesen Szenarien bleibt KI eine vorbereitende und unterstützende Schicht. Sie darf nicht entscheiden, welches Problem das wichtigste ist. Sie darf keine Schuldigen benennen. Sie darf Root Cause nicht als Fakt bestimmen. Und sie darf auf keinen Fall automatisch einen „Verbesserungsplan des Teams“ ohne lebendige Prüfung schreiben.

Warum KI die Retrospektive nicht für das Team durchführen sollte

Die gefährlichste Version einer KI-gestützten Retrospektive wirkt reif. Das Modell sammelt alle Daten, analysiert die Stimmung des Teams, findet „die drei Hauptursachen der Probleme“, schlägt Action Items vor und schickt eine Zusammenfassung in Slack oder Confluence. Alle lesen, nicken, setzen Reaktionen, und die Retrospektive wird kürzer. Manchmal beginnt das Team sogar zu denken: Wenn KI schon alles analysiert hat, warum eine Stunde für ein Gespräch verschwenden?

Das Problem ist, dass die Retrospektive nicht nur wegen des Ergebnisses wertvoll ist. Sie ist wertvoll wegen des Prozesses gemeinsamen Verstehens. Für das Team ist es wichtig, nicht nur die Aussage „Review dauert zu lange“ zu bekommen. Es muss sich darüber verständigen, warum das passiert, was das Team zu ändern bereit ist, welchen Kompromiss es eingeht und wer die Aktion übernimmt. Manchmal taucht in diesem Gespräch auf, was in den Daten nicht sichtbar ist: die Angst, mit einem starken Entwickler zu streiten, die Verärgerung über unklaren Product Context, die Müdigkeit durch ständige dringende Aufgaben, stillschweigende Ablehnung der aktuellen Definition of Done.

Die klassische Arbeit von Amy Edmondson über psychological safety und Lernverhalten ist hier wichtig nicht als modischer Verweis, sondern als praktischer Orientierungspunkt. Wenn Menschen nicht das Gefühl haben, über Probleme ohne zwischenmenschliches Risiko sprechen zu können, wird die Retrospektive zu sicheren Formulierungen. KI kann in einer solchen Situation das Protokoll reibungsloser machen, aber das Team nicht ehrlicher machen.

Darüber hinaus kann KI die Ehrlichkeit verschlechtern, wenn das Team sie als Monitoring wahrnimmt. Wenn das Modell Slack, Jira, PR-Kommentare und den Kalender liest und dann schreibt „Alexej hat eine niedrige Reaktionsgeschwindigkeit auf Reviews“ oder „QA verzögert oft die Datenbereitschaft“, ist das keine Unterstützung der Retrospektive mehr. Das ist Performance Management unter dem Deckmantel der Prozessverbesserung. In einer solchen Umgebung beginnen Menschen, sichtbare Aktivität zu optimieren, mit dem Modell zu streiten und den Ruf zu verteidigen, statt den tatsächlichen Prozess zu diskutieren.

Genau deshalb sind Quellen wie NIST Generative AI Profile, OWASP Top 10 for LLM Applications 2025, EDPB Opinion 28/2024 und ICO-Materialien zu Monitoring at work hier relevant. Nicht als rechtlicher Abschnitt des Artikels, sondern als Erinnerung: Retrospektive Daten werden leicht sensibel. Sie betreffen Menschen, Verhalten, Konflikte, Fehler, Verzögerungen, Korrespondenz und manchmal Schwachstellen der Führung.

Die praktische Grenze ist einfach: KI in der Retro sollte work and system analysieren, not people. Also blockierte Arbeit, wiederkehrende Erwartungen, unklare Regeln, Lücken in der Definition of Done, schlechte Handoffs, überlastete Prozesspunkte. Nicht „wer schlecht gearbeitet hat“, sondern „was im System uns wieder zum selben Ergebnis kommen lässt“.

„Ein guter KI-Input für die Retro betrachtet blockierte Arbeit und wiederkehrende Muster. Ein schlechter KI-Input verwandelt Menschen in Berichtszeilen.“

Setzen wir den Fall fort: B2B-LMS und E-Mail-Erinnerungen

Nehmen wir denselben Fall aus den vorherigen Artikeln: eine B2B-LMS-Plattform, Pflichtkurse, E-Mail-Erinnerungen an Mitarbeitende, die einen Pflichtkurs bis zur Frist nicht abgeschlossen haben. Im Sprint Planning wählte das Team ein enges Sprint Goal: Das System sendet eine korrekte Erinnerung an aktive Mitarbeitende mit unvollständigem Pflichtkurs vor der Frist und speichert eine überprüfbare Versandhistorie. Im Daily Scrum verfolgte das Team Risiken zu Deduplizierung, Zeitzonen und Testdaten. Im Sprint Review diskutierte das Team, was das für das Produkt und das Product Backlog ändert.

Nun kommt die Sprint Retrospective. Ohne KI kann das Gespräch schnell in gewohnte Empfindungen abgleiten. Das Backend sagt: „Uns haben Rückfragen zur Eligibility ausgebremst.“ QA sagt: „Die Testdaten kamen zu spät.“ Das Frontend sagt: „Die API änderte sich mitten im Sprint.“ Der Product Owner sagt: „Wir haben nicht mit so vielen Fragen zu expiredgerechnet.“ Der Scrum Master notiert: „Kommunikation verbessern“, „Daten früher vorbereiten“, „Anforderungen weniger ändern“. Die Retro scheint durchgeführt.

KI kann den Input konkreter machen. Sie hebt die Sprint-Historie hervor und zeigt:

• vier PRs warteten mehr als einen Tag auf Review, und alle hingen mit Retry Logic und Idempotency zusammen;
• dreimal änderte sich die Auslegung von Eligibility für deaktivierte Nutzer;
• QA-Daten erschienen am dritten Tag später, als das Team im Planning erwartet hatte;
• die Definition of Done verlangte keine überprüfbare Versandhistorie für Negativszenarien;
• der alte Action Item „PR-Größe reduzieren“ wurde nicht umgesetzt und wiederholte sich als Problem;
• ein Teil der Slack-Diskussionen betraf nicht die Implementierung, sondern das Fehlen einer einheitlichen Entscheidung zu expired.

Das ist ein guter Input. Aber es ist noch keine Retrospektive.

Die Retrospektive beginnt, wenn das Team diskutiert, was davon tatsächlich geändert werden soll. Zum Beispiel kann es entscheiden: nicht „früher kommunizieren“, sondern „im Planning strittige Eligibility-Zustände und ihre Product-Owner-Entscheidung explizit festhalten“. Nicht „QA bereitet Daten schneller vor“, sondern „im Sprint Backlog wird ein separates Work Item für Testdaten vor Beginn der Implementierung des kritischen Szenarios hinzugefügt“. Nicht „weniger PRs machen“, sondern „für Änderungen an der Notification Architecture muss ein PR in einen Review-Szenario passen und vor Arbeitsbeginn einen Review-Owner haben“. Nicht „DoD verbessern“, sondern „die Definition of Done umfasst jetzt eine überprüfbare Versandhistorie für Negativszenarien von Erinnerungen“.

Das sind nun Action Items. Sie sind konkret, überprüfbar und mit dem nächsten Sprint verbunden. KI half, Muster zu sehen. Das Team wählte eine Änderung.

Anti-Patterns

Im Folgenden einige Anti-Patterns, die ich bei der Einführung von KI in die Sprint Retrospective gesondert beobachten würde.

1. KI-Zusammenfassung ersetzt das lebendige Gespräch

Wenn das Team einfach die generierte Zusammenfassung liest und ihr zustimmt, verliert die Retro das Wesentliche. Die gute Frage ist nicht „hat KI den Sprint genau beschrieben?“, sondern „was davon sind wir bereit, in unserer Arbeit zu ändern?“.

2. Sentiment Analysis wird zur Wahrheit über das Team

Stimmungsanalyse kann ein nützliches schwaches Signal sein, aber sie kennt den Kontext nicht. Sarkasmus, Müdigkeit, lokaler Konflikt, Scherz, Schweigen und vorsichtige Formulierung lassen sich schlecht in eine Metrik verwandeln. Die Stimmung des Teams darf nicht auf ein Diagramm reduziert werden.

3. KI sucht Schuldige statt systemischer Muster

Sobald das Modell beginnt, Menschen nach Geschwindigkeit, Aktivität oder der Anzahl „erstellter Blocker“ zu ranken, wird die Retrospektive zu einem Monitoring. Das zerstört psychologische Sicherheit und verschlechtert die Qualität der Informationen, die Menschen bereit sind beizutragen.

4. Root Cause wird ohne Prüfung akzeptiert

Das Modell kann selbstsicher schreiben: „Die Hauptursache für Verzögerungen sind unklare Anforderungen.“ Aber das kann nur der sichtbare Teil sein. Die tatsächliche Ursache kann in architektonischer Schuld, Prioritätskonflikten, fehlenden Testdaten oder der Angst liegen, ein Problem zu eskalieren. Root Cause von der KI ist eine Hypothese, kein Fakt.

5. Action Items werden zu allgemein

„Kommunikation verbessern“, „schneller reviewen“, „besser vorbereiten“ ändern fast nie das Verhalten. Ein gutes Action Item sollte die Fragen beantworten: Wer macht es, was genau ändert sich, wo ist das im nächsten Sprint sichtbar und wie überprüft das Team den Effekt.

6. Verbesserungen landen nicht im Sprint Backlog

Der Scrum Guide erlaubt, dass die wichtigsten Verbesserungen in den Sprint Backlog des nächsten Sprints gelangen. Wenn das Team eine Verbesserung gewählt, ihr aber keine Aufmerksamkeit, keinen Owner und keinen Platz in der Arbeit gegeben hat, ist das keine Improvement. Das ist ein Wunsch.

Wie sich die Rollen verändern

KI hebt die Verantwortungsbereiche innerhalb des Scrum Teams nicht auf, verändert aber die Vorbereitung auf das Gespräch. Weniger Wert liegt in der manuellen Rekonstruktion der Sprint-Historie. Mehr Wert liegt in der ehrlichen Interpretation, der Wahl eines kleinen Experiments und dem Durchziehen einer Verbesserung bis zum Ergebnis.

Rolle	Risiko bei schlechtem KI-Szenario	Reife Nutzung von KI
Entwickler	Streiten mit der KI-Bewertung ihrer Aktivität und verteidigen die Reputation statt den Prozess zu diskutieren.	Nutzen Fakten und Muster als Input, wählen aber selbst, was sie an Engineering-Praktiken, Review, DoD und Handoffs ändern.
Product Owner	Liest die KI-Retro als Bericht über die Leistung des Teams und drängt auf Geschwindigkeit.	Hilft, Produktunschärfe zu beseitigen, Entscheidungen zu klären, die das Team gebremst haben, und Verbesserungen im nächsten Sprint Backlog zu unterstützen.
Scrum Master	Übergibt die Moderation an das Modell und erhält ein sauberes Protokoll statt eines ehrlichen Gesprächs.	Nutzt den KI-Input zur Vorbereitung, schützt aber die psychologische Sicherheit, den Fokus auf das System und das Follow-through der gewählten Action Items.
Quality Engineer / QA-Engineer	Bekommt die Rolle der „Quelle von Verzögerungen“, wenn das Modell Probleme oberflächlich mit dem Testen verknüpft.	Hilft, Qualitätssignale in Änderungen der Definition of Done, der Test-Data-Ownership und der Observability zu übersetzen.
UX/UI-Designer	Fällt aus der Retro heraus, weil die KI hauptsächlich Code, PRs und Entwicklungsaufgaben analysiert.	Hebt Interaktionen, Entscheidungen und Nutzerkontext hervor, die die Arbeitsqualität des Teams und des Produkts beeinflusst haben.
Engineering Lead / Tech Lead	Nutzt die KI-Retro als Dashboard zur Kontrolle der Ingenieure.	Hilft, systemische Engineering-Bottlenecks von individueller Aktivität zu unterscheiden und eine technische Verbesserung zu wählen, die tatsächlich in den nächsten Sprint passt.

Praktischer Filter für eine KI-gestützte Retrospektive

Ich würde nicht mit der Idee beginnen „lass die KI eine Retro durchführen“. Ich würde mit einer engeren Frage beginnen: Welcher Input hilft dem Team, die Art der Arbeit ehrlicher zu inspizieren und ein bis zwei Verbesserungen zu wählen, die es tatsächlich umsetzen wird?

KI-Input für die Sprint Retrospective ist nützlich, wenn er hilft, die Fragen zu beantworten:

• welche Probleme sich wiederholten und welche einmalig waren;
• welche Fakten das Thema stützen und welche Meinung oder emotionale Bewertung sind;
• was im Einflussbereich des Teams liegt und was die Hilfe von Supporters, Management oder eines anderen Teams erfordert;
• welche alten Action Items nicht erledigt wurden und warum;
• welcher eine Prozess, das Tool, die Working Agreement oder die Definition of Done im nächsten Sprint geändert werden sollte;
• wie das Team überprüft, dass die Änderung gewirkt hat.

Und umgekehrt: Wenn der KI-Input hauptsächlich die Frage beantwortet „wer war der Engpass“, ist das ein gefährliches Signal. Die Retrospektive sollte dem Team helfen, das Arbeitssystem zu verbessern, und nicht ein verdecktes Ranking der Teilnehmer erzeugen.

Daten und Grenzen

Die Sprint Retrospective ist besonders sensibel gegenüber Daten, weil die KI leicht beginnt zu sammeln, was Menschen als persönlich wahrnehmen: Chatnachrichten, Antwortgeschwindigkeit, Tonalität von Kommentaren, Reaktionszeit auf PRs, Teilnahme an Meetings, wiederkehrende Fehler, Konflikte in Diskussionen. Je breiter der Zugriff, desto überzeugender die Analyse. Aber desto höher das Risiko einer Offenlegung sensibler Kontexte, übermäßiger Abhängigkeit von der Modellausgabe und der Verwandlung der Retro in Employee Monitoring.

Praktisch würde ich mehrere Regeln vor der Einführung von KI in die Retro festlegen:

• einen minimalen Satz an Quellen nutzen, der für die Frage der Retro nötig ist;
• keine persönlichen Nachrichten ohne ausdrückliche Vereinbarung und Notwendigkeit analysieren;
• keine persönlichen Rankings, Scores und Schlussfolgerungen zum Performance Management erstellen;
• dem Team zeigen, welche Daten verwendet und welche ausgeschlossen wurden;
• Fakten von generierten Interpretationen trennen;
• wichtige Schlussfolgerungen an der Primärquelle prüfen;
• KI-Zusammenfassungen löschen oder ihre Speicherung begrenzen, wenn sie sensiblen Teamkontext enthalten.

Das ist keine Bürokratie. Das ist die Voraussetzung für ein ehrliches Gespräch. Wenn die Menschen nicht verstehen, was genau das Modell liest und wie seine Ausgabe später verwendet wird, werden sie vorsichtiger sprechen. Und eine vorsichtige Retrospektive führt fast immer zu sicheren, aber schwachen Verbesserungen.

Was sich also wirklich ändert

KI kann eine Sprint-Retrospektive tatsächlich nützlicher machen. Sie kann den Aufwand der Vorbereitung senken, Fakten in das Gespräch bringen, wiederkehrende Muster aufzeigen, an nicht erledigte Action Items erinnern, Abweichungen von der Definition of Done hervorheben und helfen, ein vages „wir müssen uns verbessern“ in ein konkretes Next-Sprint-Experiment zu verwandeln.

Aber das funktioniert nur, wenn das Team die Grenze versteht: KI bereitet Material für die Inspektion vor, führt aber die Anpassung nicht für das Team durch. Sie hilft, Daten zu sehen, schafft aber keine psychologische Sicherheit. Sie kann eine Root Cause vorschlagen, weiß aber nicht, worüber die Menschen Angst haben zu sprechen. Sie kann ein Action Item schreiben, übernimmt aber keinen Owner und ändert das Verhalten im nächsten Sprint nicht.

Deshalb würde ich die Kernthese so formulieren: KI sollte die Kosten der Wiederherstellung von Fakten senken, damit dem Team mehr Aufmerksamkeit für das ehrliche Gespräch und die Wahl einer kleinen Verbesserung bleibt. Wenn das Gegenteil passiert und die Sprint-Retrospektive zu einer automatisch generierten Liste von Empfehlungen wird, verliert das Team genau das, wofür das Event existiert: gemeinsames Lernen, Verantwortung für Veränderung und die Fähigkeit, die Qualität der Arbeit zu steigern.

Ein reifes Team fragt nicht: „Können wir die Retrospektive an KI delegieren?“. Es fragt anders: „Welchen Teil der Vorbereitung kann KI übernehmen, damit unsere Retrospektive ehrlicher, konkreter wird und besser zum Handeln führt?“. Das ist eine weniger effektvolle Frage. Dafür ist sie näher an echter kontinuierlicher Verbesserung.

Quellen und Orientierungspunkte

• Scrum Guide 2020 — Sprint-Retrospektive, Qualität und Effektivität, Menschen / Interaktionen / Prozesse / Werkzeuge / Definition of Done, die nützlichsten Verbesserungen und der Bezug zum Sprint Backlog.
• Scrum Guide Expanded v2026.1 — Companion-Quelle auf Basis des Scrum Guide 2020: psychologische Sicherheit, sinnvolle Nachverfolgung kontinuierlicher Verbesserung und KI als supervised decision-making partner.
• Scrum.org: Introduction to the Sprint Retrospective — praktische Erläuterung der Sprint-Retrospektive als Event für Inspection and Adaptation der Arbeitspraktiken des Teams.
• Lehtinen, Itkonen & Lassenius: Recurring opinions or productive improvements — empirische Studie über 37 Retrospektiven aus fast drei Jahren: participant bias, hard evidence, wiederkehrende Themen und Korrekturmaßnahmen.
• Amy Edmondson: Psychological Safety and Learning Behavior in Work Teams — klassische Quelle zur psychologischen Sicherheit als Bedingung für Team Learning.
• NIST Generative AI Profile — Konfabulation, Datenschutz, Human-AI Configuration, Overreliance, Informationsintegrität und weitere Risiken generativer KI.
• OWASP Top 10 for LLM Applications 2025 — Offenlegung sensibler Informationen, excessive agency, Fehlinformationen und operative Risiken von LLM-Anwendungen.
• DORA State of AI-assisted Software Development 2025 — KI als Verstärker bestehender Stärken und Schwächen des organisationalen Systems.
• EDPB Opinion 28/2024 und ICO monitoring at work guidance impact assessment — Orientierungspunkte zu personenbezogenen Daten, Transparenz, Verhältnismäßigkeit und den Grenzen von Workplace Monitoring.