Sprint Review und KI: Warum eine Demo das Gespräch über den Wert nicht ersetzt

Dies ist der vierte Artikel aus der Serie darüber, wie KI die klassischen Meetings eines cross-funktionalen Entwicklungsteams verändert. Im ersten Artikel habe ich Backlog Refinement behandelt und gezeigt, dass KI die Vorbereitung von Material beschleunigt, aber die Teamprüfung des Sinns nicht ersetzt. Im zweiten ging es um Sprint Planning: KI erstellt einen Entwurf des Plans, übernimmt aber keine Teamverpflichtung. Im dritten um Daily Scrum: KI bereitet Signale zum Fortschritt des Sprints vor, führt aber die Synchronisation nicht für das Team durch. Nun ist es logisch, zum Sprint Review überzugehen und den verführerischsten Fehler zu analysieren: ein lebendiges Gespräch über den Wert in ein schönes KI-Demo zu verwandeln.

Das Sprint Review wirkt wie der ideale Ort für KI. Am Ende des Sprints gibt es bereits alles, woraus sich leicht eine wirkungsvolle Präsentation zusammenstellen lässt: abgeschlossene Aufgaben in Jira, gemergte Pull Requests, Änderungen im Code, neue Screens, aktualisierte Metriken, Support-Tickets, Nutzerfeedback. KI kann in Minuten Release Notes erstellen, ein Demo-Szenario entwerfen, Folien gestalten, zählen, wie viel insgesamt erledigt wurde, und sogar eine saubere Zusammenfassung dessen generieren, was die Nutzer sagen.

Auf den ersten Blick ist das ein reiner Gewinn. Weniger manuelle Vorbereitung. Weniger „Lasst uns fünf Minuten vor dem Meeting entscheiden, was wir zeigen“. Weniger langweiliges Aufzählen des Erledigten. Die Präsentation wirkt professionell, die Release Notes sind zusammenhängend geschrieben, die Metriken schön visualisiert.

Aber hier gibt es eine Falle, und sie ist ernster als beim Daily Scrum.

Das Sprint Review existiert nicht zur Demonstration. Seine Aufgabe ist es, gemeinsam mit den Stakeholdern das Ergebnis des Sprints zu inspizieren, den Fortschritt zum Product Goal zu besprechen und das Product Backlog anzupassen. Wenn KI das Sprint Review in ein poliertes Demo verwandelt, erhält das Team eine schönere Präsentation, verliert aber das Wesentliche: ehrliches Feedback, die gemeinsame Entscheidung „was als Nächstes zu tun ist“ und die Verantwortung für das Produkt.

„KI kann die Routine der Vorbereitung beseitigen, aber das Sprint Review ist nicht wegen der Demo wertvoll, sondern wegen der Entscheidung, was am Produkt zu ändern ist.“

Wozu ein Sprint Review dient

Im Scrum Guide 2020 wird das Sprint Review recht streng beschrieben. Es ist das zweitletzte Ereignis des Sprints, timeboxed auf maximal vier Stunden für einen einmonatigen Sprint. Sein Ziel ist es, das Ergebnis des Sprints zu inspizieren und weitere Anpassungen zu bestimmen. Das Scrum Team präsentiert die Arbeitsergebnisse den wichtigsten Stakeholdern, und der Fortschritt zum Product Goal wird besprochen. Und separat, fast polemisch, präzisiert der Scrum Guide: „The Sprint Review is a working session and the Scrum Team should avoid limiting it to a presentation“ — es ist eine Arbeitssitzung, und das Team sollte es nicht auf eine Präsentation reduzieren.

Das ist der Schlüsselsatz für den gesamten Artikel. Das Sprint Review ist keine Abnahme der Arbeit durch den Product Owner, kein Bericht vor der Geschäftsleitung, kein Marketing-Demo für den Kunden und keine Zeremonie „wir sind toll“. Es ist der Moment, in dem Team und Stakeholder gemeinsam darauf schauen, was erledigt wurde und was sich ringsum verändert hat, und entscheiden, was als Nächstes zu tun ist. Das Ergebnis des Ereignisses sind nicht Applaus, sondern ein angepasstes Product Backlog.

Als zusätzliche Orientierung ist auch der Scrum Guide Expanded v2026.1nützlich, aber eben als Companion-Quelle, nicht als neue kanonische Version des Scrum Guide. Für diesen Artikel ist er als praktischer Rahmen wichtig: Das Sprint Review dreht sich um den realen Wertfluss zu den Stakeholdern und die gemeinsame Anpassung des Produktplans, nicht um eine Statuspräsentation. Im Abschnitt über KI beschreibt er 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 des Sprint Review über fünf Funktionen beschreiben:

• Inspektion des realen Ergebnisses des Sprints, nicht der Erzählung darüber;
• Sammlung ehrlichen Feedbacks von Stakeholdern und Nutzern;
• Prüfung des Fortschritts zum Product Goal;
• gemeinsame Entscheidung, was als Nächstes zu tun ist;
• Anpassung des Product Backlogs, nicht nur das Zeigen des Erledigten.

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 das Demo schöner macht, kann es bequem sein, verbessert aber nicht unbedingt das Produkt.

Was gewöhnlich schiefgeht

Das Problem des Sprint Review liegt selten darin, dass das Team nicht zeigen kann, was erledigt wurde. Das Problem ist, dass das Ereignis mit der Zeit zu einem einseitigen Demo verkommt: Das Team bereitet eine Präsentation vor, zeigt Screens, zählt abgeschlossene Aufgaben auf, die Stakeholder nicken höflich, jemand sagt „großartig, danke“, und alle gehen auseinander. Das Backlog ändert sich dabei nicht. Scrum.org analysiert genau dieses Anti-Pattern im Material Myth 12: The Sprint Review is a Demo: Eine Demo kann Teil des Ereignisses sein, aber das Ziel des Sprint Review ist es, Feedback zu maximieren und Risiko zu senken, nicht eine Präsentation abzuhalten.

Dann beginnt das Meeting gegen sein eigenes Ziel zu arbeiten. Das Team diskutiert, wie man es schöner präsentiert, statt was wichtig zu besprechen ist. Stakeholder schaffen es nicht, Feedback zu geben, weil das Team „naiv von seiner eigenen Präsentation mitgerissen wird“ — Scrum.org merkt dies eigens im Material How to Engage Stakeholders in your Sprint Reviews. Unangenehme Fragen werden nicht gestellt. Die Diskrepanz zwischen dem, was gebaut wurde, und dem, was der Markt braucht, taucht spät auf. Das Product Backlog bleibt so, wie es vor dem Meeting war, obwohl der ganze Sinn des Events darin besteht, es auf Basis neuer Daten zu ändern.

Im AI-assisted-Kontext kann sich dieses Problem verstärken. Wenn das Modell in jedem Sprint eine Präsentation, Release Notes und eine Liste der Errungenschaften generiert, gewöhnt sich das Team schnell an den Gedanken, dass „die Review schon vorbereitet ist“. Dann wird die Sprint Review noch glatter: AI-Folien geöffnet, Release Notes gelesen, Metriken gezeigt, ein höfliches „Danke“ erhalten und das Meeting geschlossen.

Es sieht professionell aus. Aber die Frage ist nicht, wie kohärent die Präsentation zusammengestellt ist. Die Frage ist, ob das Team sein Product Backlog geändert hat, wenn sich die Realität geändert hat.

Wo AI tatsächlich hilft

AI hat in der Sprint Review eine durchaus praktische Nutzenszone. Sie kann die Routine der Vorbereitung beseitigen und das an die Oberfläche bringen, was das Team am Ende des Sprints leicht verliert. Das ist besonders wertvoll, wenn es viele Quellen gibt: Issue Tracker, Pull Requests, CI/CD, Produktanalytik, Support-Tickets, Bewertungen aus den Stores, Umfrageergebnisse, Aufzeichnungen von Nutzerinterviews.

Aber hier ist es wichtig, nicht zu viel zu versprechen. Selbst der aktuelle DORA State of AI-assisted Software Development 2025 beschreibt AI eher als Verstärker bestehender organisatorischer Praktiken denn als eigenständige Garantie für besseres Delivery. Für die Sprint Review bedeutet das etwas Einfaches: Wenn das Team bereits ein ehrliches Gespräch über Wert führen und das Backlog anpassen kann, macht AI den Einstieg in dieses Gespräch reicher. Wenn die Sprint Review längst zu einem Demo-Ritual geworden ist, macht AI dieses Ritual einfach schneller und schöner.

Ein guter AI-Assistent sammelt vor der Sprint Review nicht „wie man es effektvoller zeigt“, sondern nützlichen Kontext für die Produktentscheidung:

• was sich im Produkt während des Sprints tatsächlich geändert hat und wie das mit dem Product Goal zusammenhängt;
• welche Elemente des Increments zur Inspektion bereit sind und welche man besser ehrlich als unfertig zeigt;
• was die Produktmetriken nach früheren Releases sagen;
• welches Feedback von Nutzern und Support kam, einschließlich widersprüchlichem und unangenehmem;
• welche Hypothesen früherer Sprints bestätigt wurden und welche nicht;
• welche offenen Produktfragen zur Diskussion mit den Stakeholdern gebracht werden sollten;
• welche Product-Backlog-Einträge möglicherweise an Aktualität verloren haben oder umgekehrt in der Priorität gestiegen sind.

In einem solchen Modus ersetzt AI die Sprint Review nicht. Sie senkt die Kosten der Vorbereitung darauf. Das Team kommt nicht mit Rohdaten und nicht mit hastig zusammengestellten Folien, sondern mit einem bereits strukturierten Bild: hier das Ergebnis, hier die Daten, hier das Feedback, hier die offenen Fragen. Das erlaubt, weniger Zeit auf das Sammeln von Fakten und mehr auf das Gespräch „was ändern wir jetzt im Produkt?“ zu verwenden.

Dies setzt die Logik der vorherigen Artikel der Serie fort. Im Refinement half AI, Material für die Diskussion zu sammeln. Im Planning — Varianten des Plans. Im Daily Scrum — Signale zum Verlauf des Sprints. In der Sprint Review kann sie Ergebnis und Feedback sammeln. Aber in allen vier Fällen verschwindet der menschliche Teil nicht: Team und Stakeholder müssen prüfen, was wichtig ist, was sich geändert hat und welche Entscheidung zu treffen ist.

Warum AI die Sprint Review nicht in ein Demo-Theater verwandeln sollte

Die gefährlichste Version einer AI-assisted Sprint Review wirkt sehr überzeugend: Das Modell generiert eine Präsentation mit schönen Folien, kohärente Release Notes, eine Liste der „wichtigsten Errungenschaften des Sprints“, Metrikdiagramme und eine glatte Zusammenfassung des Nutzerfeedbacks. Manchmal kommen eine automatische Prognose zum Product Goal und vorgeschlagene Änderungen im Backlog hinzu.

Aus Sicht formaler Transparenz ist das bequem. Aus Sicht von Scrum kann es eine Degradierung sein.

Erstens verstärkt ein solches Format die Einseitigkeit. Je schöner die AI-Demo, desto stärker die Versuchung, das Meeting als Präsentation „durchzuziehen“. Die Aufmerksamkeit verschiebt sich vom Feedback auf das Zeigen: Das Team verteidigt die Folien, statt die Stakeholder zum Streit über den Wert einzuladen.

Zweitens kann eine AI-Zusammenfassung des Feedbacks genau das auslöschen, wofür die Sprint Review durchgeführt wird. Der wahre Wert von Feedback liegt in Widersprüchen, schwachen Signalen, unangenehmem Widerspruch und einem seltenen, aber wichtigen Kommentar. Eine glatte gemittelte Zusammenfassung wirft Ausreißer leicht weg, und im Produkt ist oft gerade der Ausreißer das Signal. Das ist das klassische Risiko von Information Integrity und Misinformation, beschrieben im NIST-Profil für generative KI.

Drittens kann das Modell selbstbewusst Insights erfinden, die in den Daten nicht vorhanden sind. Konfabulation ist besonders gefährlich im Sprint Review, weil eine generierte „Schlussfolgerung“ über Nutzer leicht zu einer Produktentscheidung wird. Wenn die KI schreibt „Nutzer fordern X“, obwohl es in Wirklichkeit zwei Tickets und ein Interview waren, riskiert das Team, das Product Backlog auf Basis einer Halluzination zu ändern.

Viertens kann das Team beginnen, das Produkturteil an das Werkzeug zu delegieren. Wenn die KI Änderungen am Backlog vorgeschlagen hat, scheint es, als könne man sie einfach übernehmen. Wenn die KI gesagt hat, dass das Product Goal erreicht wird, scheint es, als gäbe es nichts zu besprechen. Das ist keine Automatisierung des Sprint Review, sondern eine Verlagerung von Verantwortung dorthin, wo es keine Verantwortung geben kann: Für das Produkt ist der Product Owner zusammen mit dem Team verantwortlich, nicht das Modell.

„Eine KI-Demo kann ein nützlicher Input sein. Sie sollte nicht den Austausch über den Wert ersetzen.“

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 nicht bis zur Frist abgeschlossen haben. Beim 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.

Ohne KI kann ein Sprint Review in einem solchen Sprint leicht zu einer Demo verkommen. Das Team zeigt den Bildschirm zur Einrichtung der Erinnerungen, demonstriert eine Test-E-Mail, sagt „der Scheduler läuft, die Deduplizierung ist vorhanden, das Historienprotokoll wird geschrieben“, die Stakeholder nicken, jemand lobt das Design der E-Mail. Formal ist alles gut. Das Backlog ändert sich nicht.

Aber das Team kann das Wesentliche verpassen: Die Erinnerungen gehen raus, aber die Öffnungsrate ist niedrig, weil der Betreff der E-Mail unglücklich gewählt ist; der Support hat bereits mehrere Anfragen erhalten „warum habe ich eine Erinnerung zu einem Kurs bekommen, den ich nicht absolvieren muss“ — das heißt, die Eligibility-Grenze funktioniert nicht wie erwartet; ein großer Kunde bittet um einen individuellen Zeitplan, und das verändert potenziell die Prioritäten des nächsten Sprints; und die Auslegung des Status expireddie das Team als außerhalb des Umfangs betrachtete, ist tatsächlich wichtig für die Stakeholder.

Die KI kann hier helfen. Vor dem Sprint Review sammelt sie Input: was an wen gesendet wurde, wie die Öffnungs- und Klickrate ist, welche Anfragen beim Support eingegangen sind und worum es dabei ging, welches Feedback Pilotkunden hinterlassen haben, welche Backlog-Einträge mit diesem Sprint Goal verbunden sind. Das ist gutes Material für das Gespräch.

Aber der Wert entsteht erst im Meeting, wenn Team und Stakeholder den nächsten Schritt machen: entscheiden, dass die niedrige Öffnungsrate ein Produktproblem ist und nicht Kosmetik; dass die Eligibility-Grenze präzisiert und als eigener Eintrag ins Backlog aufgenommen werden muss; dass individuelle Zeitpläne für große Kunden eine strategische Entscheidung sind und kein schneller Fix; und dass die Auslegung von expired nun aus „außerhalb des Umfangs“ in die nächste Priorität verschoben werden sollte. Die KI lieferte Ergebnis und Daten. Das Team adaptierte mit den Stakeholdern das Product Backlog.

Anti-Patterns

Im Folgenden einige Anti-Patterns, die ich bei der Einführung von KI im Sprint Review besonders beobachten würde.

1. Die KI macht die Präsentation schöner, aber das Meeting bleibt einseitig

Wenn der Aufwand in das Polieren von Slides und Release Notes fließt, wird das Sprint Review als Demo gestärkt, nicht als Working Session. Nützlicher wäre, dass die KI Fragen an die Stakeholder und offene Produktthemen vorbereitet und nicht nur eine effektvolle Vorführung des Erledigten.

2. KI-Zusammenfassungen von Feedback mitteln und verlieren schwache Signale

Eine glatte Zusammenfassung ist bequem zu lesen, aber gefährlich, weil sie Widersprüche und seltene, aber wichtige Kommentare herausfiltert. Feedback sollte unter Bewahrung von Widerspruch und Ausreißern gebracht werden, nicht nur als gemittelte „allgemeine Stimmung“.

3. Die KI erfindet Produkt-Insights, die in den Daten nicht vorhanden sind

„Nutzer wollen X“ klingt überzeugend, erfordert aber Prüfung: Auf wie vielen Signalen beruht die Schlussfolgerung, ist es eine Halluzination, hat sie einen seltenen Fall durch Massennachfrage ersetzt. Ein Insight des Modells ist eine Hypothese, keine Entscheidung.

4. Metriken werden als Errungenschaft gezeigt, nicht als Anlass für eine Entscheidung

„10 000 E-Mails versendet“ ist Aktivität, nicht Wert. Das Sprint Review sollte Metriken mit dem Product Goal verknüpfen und fragen, was sie im Plan ändern, statt sie als Beweis zu nutzen, dass der Sprint gut gelaufen ist.

5. Die KI schlägt Änderungen am Product Backlog vor, und sie werden ohne Diskussion übernommen

Der Vorschlag des Modells kann ein nützlicher Input sein, aber die Anpassung des Backlogs ist eine Produktentscheidung des Product Owners zusammen mit dem Team und den Stakeholdern, nicht die automatische Anwendung von KI-Empfehlungen.

6. Demo-Theater für die Führung statt Inspektion zur Adaption

Wenn das Sprint Review zu einer Show wird „wir zeigen der Geschäftsleitung, dass wir gut sind“, macht die KI die Show nur überzeugender. Das untergräbt das Vertrauen in das Event und beraubt das Team ehrlichen Feedbacks.

Wie sich die Rollen verändern

KI hebt die Rollen innerhalb des Scrum Teams nicht auf, aber sie verändert den Akzent in der Vorbereitung und Durchführung des Sprint Review. Weniger Wert liegt im manuellen Zusammenbauen der Präsentation. Mehr Wert liegt in der ehrlichen Inspektion des Ergebnisses, der Arbeit mit Feedback und der gemeinsamen Entscheidung über das Produkt.

Rolle	Risiko bei schlechtem KI-Szenario	Reife Nutzung von KI
Product Owner	Akzeptiert KI-Zusammenfassungen von Feedback und vorgeschlagene Backlog-Änderungen als fertige Lösung und hört auf, den Wert selbst zu durchdenken.	Nutzt KI-Input als Material, führt aber selbst das Gespräch über den Wert, prüft Insights und verantwortet die Anpassung des Product Backlogs.
Entwickler	Verwenden die Vorbereitung auf das Polieren einer KI-Demo, statt ehrlich zu zeigen, was fertig ist und was nicht.	Nutzen KI, um Ergebnis und Risiken schnell zusammenzustellen, und inspizieren das Increment ehrlich gemeinsam mit den Stakeholdern.
Scrum Master	Übergibt die Moderation den Folien und achtet nur auf das Timing der Präsentation.	Schützt das Sprint Review davor, zur Demo zu werden, hilft, Stakeholder einzubinden, und hält den Fokus auf der Anpassung.
Stakeholder	Bekommen eine glatte KI-Demo, nicken höflich und geben kein echtes Feedback.	Sehen das ehrliche Ergebnis und die Daten, stellen unbequeme Fragen und beeinflussen die Produktprioritäten.
Qualitätsingenieur / QA-Ingenieur	Bestätigt die KI-Liste des „Erledigten“ und erzeugt den Anschein von Bereitschaft des Increments.	Hilft, ehrlich zu zeigen, was der Definition of Done entspricht und was nicht, und wo Qualitätsrisiken bleiben.
UX/UI-Designer	Fällt aus dem Review heraus, weil die KI-Demo auf Funktionen und Metriken fokussiert.	Bringt Nutzerbeobachtungen und Feedback zur Erfahrung ein und hilft, das Ergebnis mit echtem Wert zu verbinden.

Praktischer Filter für ein KI-gestütztes Sprint Review

Ich würde nicht mit der Einführung eines „KI-Demo-Generators“ beginnen. Ich würde mit einer engeren Frage beginnen: Welcher Input hilft dem Team und den Stakeholdern, schneller eine ehrliche Produktentscheidung zu treffen? Danach kann KI als vorbereitende Schicht genutzt werden, nicht als Ersatz für das Event.

KI-Input für das Sprint Review ist nützlich, wenn er hilft, folgende Fragen zu beantworten:

• Was hat sich im Produkt wirklich verändert und wie hängt das mit dem Product Goal zusammen?
• Was ist bereit für eine ehrliche Inspektion und was muss als unfertig gezeigt werden?
• Was sagen die Daten und das Feedback, einschließlich widersprüchlicher Rückmeldungen?
• Welche Hypothesen wurden bestätigt und welche sind gescheitert?
• Welche offenen Produktfragen sollten mit den Stakeholdern besprochen werden?
• Welche Product-Backlog-Einträge müssen geändert, hinzugefügt oder entfernt werden?
• Welche Entscheidung treffen wir als Ergebnis und nicht nur, was wir zeigen?

Und umgekehrt: Wenn der KI-Input hauptsächlich die Frage beantwortet „wie zeigen wir das Erledigte wirkungsvoller“, ist das kein Sprint Review. Das ist eine Demo. Sie kann für die Kommunikation nützlich sein, aber man sollte sie nicht mit der Inspektion des Ergebnisses und der Anpassung des Product Backlogs verwechseln.

Datenverwaltung und Datenhygiene

Das Sprint Review ist besonders datensensibel, weil die KI-Vorbereitung leicht beginnt, Feedback aus Support-Tickets, CRM, Interviewaufzeichnungen, Umfragen, Store-Bewertungen und Kundenkorrespondenz zu sammeln. Je breiter der Zugriff, desto überzeugender die Zusammenfassung. Aber desto höher das Risiko von Lecks sensibler Informationen, von Bedeutungsverzerrung und übermäßiger Abhängigkeit von einer sicheren, aber unvollständigen Schlussfolgerung des Modells. Diese Risikoklassen sind gut beschrieben im NIST-Profil für generative KI, im NIST-Framework zum Management von KI-Risiken 1.0 und in den OWASP Top 10 for LLM Applications 2025.

Das Team sollte vorab vereinbaren, welche Feedback-Quellen für KI erlaubt sind, wie Nutzerdaten anonymisiert werden, wer die generierte Zusammenfassung sieht und ob Rohzitate von Kunden externen Stakeholdern gezeigt werden dürfen. Bei der Arbeit mit personenbezogenen Daten von Nutzern und Kunden sind Orientierungshilfen wie EDPB Opinion 28/2024 und ICO monitoring at work impact assessment nützlich — nicht als juristische Anleitung für den Artikel, sondern als Erinnerung an Rechtsgrundlage, Datenminimierung, Transparenz und Verhältnismäßigkeit.

Praktisch bedeutet das: keine überflüssigen personenbezogenen Daten in das Modell ziehen, Fakten von generierten Interpretationen trennen, KI-Insights als Hypothesen kennzeichnen, Nutzerzitate an der Primärquelle prüfen und im Sprint Review keine „Schlussfolgerungen“ zeigen, die nicht durch Daten belegt werden können. KI sollte dem Team helfen, Ergebnis und Feedback ehrlich zu sehen, und nicht ein überzeugendes, aber ungeprüftes Bild erzeugen.

Praktisches Fazit

KI kann das Sprint Review tatsächlich nützlicher machen. Sie kann die Routine der Vorbereitung reduzieren, das Ergebnis des Sprints im Voraus zusammenstellen, es mit Metriken verknüpfen, Feedback aggregieren, Abweichungen zwischen Plan und Realität hervorheben und Themen für die Diskussion mit den Stakeholdern vorschlagen.

Aber das funktioniert nur, wenn das Team die Grenze versteht: KI bereitet den Input vor, führt aber nicht das Sprint Review durch. Sie hilft, Ergebnis und Daten zu sehen, entscheidet aber nicht, was sie für das Produkt bedeuten. Sie kann Feedback sammeln, erzeugt aber nicht von sich aus ein ehrliches Gespräch über den Wert. Sie kann Änderungen am Backlog vorschlagen, übernimmt aber keine Verantwortung für das Produkt.

Deshalb würde ich die Kernthese so formulieren: KI sollte die Kosten der Vorbereitung senken, damit Team und Stakeholder mehr Aufmerksamkeit für das Gespräch über den Wert und die Anpassung des Plans behalten. Wenn das Gegenteil passiert und das Sprint Review zu einer polierten KI-Demo wird, verliert das Team genau das, wofür das Event existiert: ehrliche Inspektion des Ergebnisses, echtes Feedback, gemeinsame Entscheidung und Verantwortung für das Produkt.

Ein reifes Team fragt nicht: „Können wir die KI damit beauftragen, einen Sprint-Review-Bericht zu erstellen?“. Es fragt anders: „Welchen Teil der Vorbereitungsroutine kann die KI übernehmen, damit unser Sprint Review zu einem ehrlicheren Gespräch über den Wert und darüber wird, was im Produkt geändert werden muss?“. Das ist eine weniger spektakuläre Formulierung. Dafür ist sie näher an der realen Produktpraxis.

Quellen und Orientierungspunkte

• Scrum Guide 2020 — Sprint Review, Product Goal, Product Backlog, Inkrement, Working Session, Inspektion und Anpassung.
• Scrum Guide Expanded v2026.1 — Begleitquelle auf Basis des Scrum Guide 2020: praktische Rahmung des Sprint Review, Wertfluss zu den Stakeholdern und KI als supervised decision-making partner.
• Scrum.org: What is a Sprint Review? — Sprint Review als kollaborative Working Session, nicht als Präsentation.
• Scrum.org: Myth 12 — The Sprint Review is a Demo — warum sich ein Sprint Review nicht auf eine Demo reduzieren lassen sollte.
• Scrum.org: How to Engage Stakeholders in your Sprint Reviews — warum das Feedback der Stakeholder der Hauptwert des Events ist.
• NIST-Profil für generative KI — Konfabulation / selbstsicheres Erfinden, Information Integrity, übermäßige Abhängigkeit und menschliche Kontrolle.
• NIST-Framework zum Management von KI-Risiken 1.0 — Steuerung / Regulierung, Rechenschaftspflicht und Konfiguration der Mensch-KI-Interaktion.
• OWASP Top 10 for LLM Applications 2025 — Offenlegung sensibler Informationen, Misinformation und Excessive Agency in LLM-Anwendungen.
• DORA State of AI-assisted Software Development 2025 — KI als Verstärker organisatorischer Praktiken, nicht als eigenständige Garantie für Verbesserung.
• EDPB Opinion 28/2024 und ICO monitoring at work impact assessment — Orientierungspunkte zu personenbezogenen Daten, Minimierung, Transparenz und Verhältnismäßigkeit im Umgang mit Feedback.