Beiträge

So sieht ein KI-natives Sprint Review im Jahr 2026 aus

Die meisten Teams, mit denen ich spreche, führen ihre Sprint Reviews immer noch so durch, als wäre es 2018. Jemand teilt einen Bildschirm, geht abgeschlossene Tickets durch, fragt "Noch Fragen?" und das Meeting ist vorbei. Stakeholder nicken, nichts ändert sich, und die Hälfte von ihnen erscheint ab Sprint vier nicht mehr. Dieses Format ergab Sinn, als Releases langsam waren und Leute in einem Raum sein mussten, um die Arbeit zu sehen. Beides stimmt nicht mehr. Teams, die KI-Coding-Tools nutzen, liefern doppelt so viel pro Sprint, und Stakeholder sind über Zeitzonen und Slack-Kanäle verteilt. Die 60-minütige Live-Demo passt zu keiner dieser Realitäten. So sieht ein Sprint Review für Teams aus, die es rund um KI neu aufgebaut haben.

Die Form hat sich umgekehrt

Die alte Form: 60 Minuten live, demolastig, geringe Beteiligung. Die neue Form: Der Großteil des Reviews passiert asynchron vor dem Meeting. Das Meeting selbst schrumpft auf 30 Minuten und wird zu einer Entscheidungsrunde, nicht zu einer Demo.

Phase	Altes Format	KI-natives Format
Vor dem Meeting	Nichts	Async-Demos, KI-generierte Änderungs­zusammenfassung, Stakeholder-Briefing
Meeting	60 min Walkthrough + Q&A	30 min Diskussion zum vorab gesehenen Material, Entscheidungen für nächsten Sprint
Nach dem Meeting	Notizen versanden in irgendeiner Notion-Seite	KI synthetisiert Feedback zu Backlog-Kandidaten
Stakeholder-Last	Jede Demo durchsitzen, relevant oder nicht	Nur die Demos schauen, die sie betreffen, in eigener Zeit kommentieren

Der Gewinn: Stakeholder müssen sich nicht mehr zwischen "alles mitmachen" und "alles verpassen" entscheiden. Sie schauen, was relevant ist, in ihrer eigenen Zeit, und kommen zum Live-Meeting bereits mit einer Meinung.

Was die KI tatsächlich macht

Es wird viel über "KI-gestützte Sprint Reviews" geredet. Meistens sind das Dashboards mit einem aufgeschraubten Chatbot. Wenn man das wegnimmt, bleiben vier Jobs, die KI gerade gut erledigt.

Die Änderungs­zusammenfassung erstellen

Der Product Owner hat früher eine Stunde am Vortag des Reviews damit verbracht, "was wir diesen Sprint geliefert haben" zusammenzustellen. Diese Zusammenfassung schreibt sich jetzt selbst. KI liest geschlossene Tickets, PR-Beschreibungen und Release Notes und entwirft eine für Stakeholder lesbare Zusammenfassung, nach Thema gruppiert (nicht nach Ticket). Der PO bearbeitet sie, statt sie zu schreiben. Zwanzig Minuten statt einer Stunde, und das Ergebnis ist besser, weil es nach dem gruppiert ist, was Stakeholder interessiert, nicht nach Ticket-Reihenfolge.

Demos aufnehmen und indexieren

Engineers nehmen 2-3-minütige Loom-Demos der Features auf, die sie gebaut haben. KI transkribiert sie, taggt sie nach Produktbereich und verlinkt sie zurück zur ursprünglichen Story. Stakeholder, die async schauen, können in Demos suchen ("zeig mir alles zum Checkout"), statt sich durch eine 60-minütige Zoom-Aufzeichnung zu scrollen.

Feedback in Echtzeit synthetisieren

Das ist die Sache, die meine Meinung zu Async-First-Reviews geändert hat. Während der Live-Diskussion hört die KI mit (mit Erlaubnis) und clustert Kommentare nach Thema, sobald sie eingehen. Am Ende des Meetings braucht ihr niemanden, der Notizen macht. Ihr habt eine geclusterte Liste der Stakeholder-Anliegen, bereits gruppiert, bereit, Backlog-Kandidaten zu werden. Für Teams, die ihre Retro direkt nach dem Review machen: Dieselbe KI-Schicht, die das automatische Gruppieren in der Retrospective antreibt, übernimmt auch das Review-Feedback. Gleiches Muster, andere Zeremonie.

Feedback mit der Historie verbinden

Mein liebster Anwendungsfall ist der einfachste: Gedächtnis. "Haben wir das nicht vor zwei Sprints besprochen?" brauchte früher jemanden mit gutem Gedächtnis und einer Toleranz fürs Scrollen. Jetzt zeigt die KI es an: "Stakeholder hat dieses Anliegen im Review vom 14. März erwähnt. Team hat zugesagt, darauf zurückzukommen. Status: noch offen." Stakeholder vertrauen dem Prozess mehr, wenn sie sehen, dass ihre Beiträge nachverfolgt werden, auch drei Sprints später. Eine Kleinigkeit, die viel bewirkt.

Was hartnäckig menschlich bleibt

Manche Sprint-Review-Aufgaben sehen automatisierbar aus, sind es aber nicht. Verschwende keine Energie damit. Entscheiden, was gezeigt wird. KI kann jede geschlossene Story auflisten. Sie kann dir nicht sagen, welche drei für den VP of Sales wichtig sind, der 20 Minuten Zeit hat. Das ist eine Einschätzung des Publikums, und ein PO, der seine Stakeholder kennt, wird das immer besser machen als ein Modell. Den Raum lesen. Wenn ein Stakeholder mit verschränkten Armen "sieht gut aus" sagt, liegt die Bedeutung in der Körpersprache. KI-Stimmungsanalyse auf Transkripten verpasst das komplett. Reviews brauchen mindestens einen Menschen, der auf den Widerspruch achtet, den niemand laut ausspricht. Feedback annehmen oder ablehnen. Das war schon vor KI eine Regel, und sie gilt immer noch. Der PO sammelt Feedback und bewertet es später im Backlog Refinement. Lass dich nicht von einem KI-Tool, das automatisch Tickets aus Feedback-Kommentaren erstellt, in spontane Zusagen drängen. Das "Sollen wir das bauen?"-Gespräch. KI sagt dir, was du gebaut hast. Die schwerste Frage in einem Sprint Review ist, ob das Team die richtigen Dinge baut. Das ist ein Strategiegespräch zwischen Menschen, informiert durch Daten, die die KI sichtbar macht, aber nicht von ihr entschieden.

Ein Durchlauf eines KI-nativen Reviews

So sieht der Rhythmus aus, den ein Team, mit dem ich arbeite, für einen zweiwöchigen Sprint nutzt. Es ist nicht die einzige Form, aber sie zeigt, wie die beweglichen Teile zusammen aussehen.

1. Zwei Tage vorher: Engineers nehmen Demos auf

   Jeder Engineer nimmt einen 2-3-minütigen Walkthrough dessen auf, was er gebaut hat. KI transkribiert und taggt sie. Gesamtaufwand des Teams: vielleicht 30 Minuten quer durchs Team.

2. Einen Tag vorher: PO verschickt das Briefing

   KI erstellt eine Entwurfs-Zusammenfassung, nach Thema gruppiert. Der PO bearbeitet sie, fügt Business-Kontext für jede Gruppe hinzu und schickt einen einzigen Loom plus einen Link zur Demo-Bibliothek. Stakeholder haben 24 Stunden.

3. Async-Feedback-Fenster

   Stakeholder schauen die Demos, die sie betreffen, und hinterlassen Kommentare mit Zeitstempel. KI clustert Kommentare nach Thema, sobald sie eingehen, sodass der PO ins Meeting kommt und die drei wichtigsten Diskussionspunkte schon kennt.

4. Live-Meeting, 30 Minuten

   Kein Screensharing. Beginn mit "Du hast gesagt, wir haben getan" aus dem letzten Review. Diskussion der Top-Cluster aus dem Async-Feedback. Entscheidung, was sich im nächsten Sprint ändert. Ende.

5. Nach dem Meeting: KI-Synthese ins Backlog

   KI wandelt Feedback-Cluster in Backlog-Kandidaten mit vollständigem Kontext um (welcher Stakeholder, welche Demo, was wurde gesagt). PO pflegt das Backlog in seiner eigenen Zeit. Nichts fällt durchs Raster.

Das Team, das das so macht, hat mir erzählt, dass ihre Review-Teilnahme von "drei von sieben Stakeholdern, meist zu spät" auf "sechs von sieben, vorbereitet, mit konkretem Feedback" gestiegen ist. Der Schlüssel war nicht die KI. Es war, die Zeit der Stakeholder genug zu respektieren, um sie nicht durch irrelevante Demos sitzen zu lassen.

Wo das schiefgeht

Ein paar Muster, die ich beobachtet habe, killen KI-native Reviews, bevor sie Fuß fassen. Async als "Meeting weglassen" verstehen. Die asynchrone Vorarbeit ersetzt die Demo, nicht die Diskussion. Teams, die das Live-Meeting komplett streichen, verlieren den Entscheidungsmoment und landen bei Stakeholder-Feedback, das nie aufgelöst wird. Die KI das Briefing schreiben lassen, ohne es zu bearbeiten. Automatisch erzeugte Zusammenfassungen sind zu 80 % fertig. Der Job des PO sind die letzten 20 %, also der Business-Kontext und die Einordnung, worauf Stakeholder achten sollen. Lässt man das weg, liest sich die Zusammenfassung wie eine Release Note. Demos aufnehmen, die niemand schaut. Wenn deine Stakeholder die Async-Demos nicht schauen, liegt das Problem wahrscheinlich daran, dass du zu viele aufnimmst oder sie zu lang sind. Drei 2-Minuten-Demos schlagen jederzeit einen 15-minütigen Walkthrough.

Sprint Review vs. Retrospective in einem KI-nativen Team

Diese beiden Zeremonien dienen weiterhin unterschiedlichen Zwecken, aber ihre KI-Schichten überschneiden sich mehr, als man denkt.

	Sprint Review	Retrospective
Publikum	Team + Stakeholder	Nur Team
Hauptjob der KI	Externes Feedback ins Backlog synthetisieren	Team-Feedback clustern, Action Items nachverfolgen
Was automatisiert ist	Änderungs­zusammenfassung, Feedback-Clustering	Auto-Gruppierung nach Ähnlichkeit, Stimmung, Zusammenfassungen
Was menschlich bleibt	Strategie und Priorisierung	Ehrliche Reflexion und psychologische Sicherheit

Wenn du bereits Retrospectives mit KI-Gruppierung und Zusammenfassungen machst, hast du 70 % des Wegs zu einem KI-nativen Sprint Review hinter dir. Dieselben Muster lassen sich übertragen. Der größere Schritt ist der Kulturwandel zu Async-First, nicht das Tooling.

Wo du anfangen kannst

Du brauchst keine neue Plattform. Pick dir den Teil deines aktuellen Reviews raus, der am meisten weh tut, und setze KI darauf an.

• Wenn das Schreiben der Änderungs­zusammenfassung den Donnerstag deines PO killt: Starte mit automatisch generierten Zusammenfassungen.
• Wenn Demos zu lang laufen und Stakeholder abschalten: Starte mit vorab aufgenommenen Async-Demos.
• Wenn Feedback zwischen Reviews verloren geht: Starte mit Feedback-Clustering und Follow-up-Tracking.
• Wenn Stakeholder nicht erscheinen: Starte mit dem "Du hast gesagt, wir haben getan"-Einstieg bei jedem Review.

Die besten Sprint Reviews, die ich dieses Jahr gesehen habe, sind nicht die mit der schicksten KI. Es sind die, in denen KI die Teile entfernt hat, die niemand mochte, das Recap und die Notizen, damit das Strategiegespräch mehr Luft bekommt.