Artikel

Die Sprint-Review funktioniert nicht mehr

KI beschleunigt die Bereitstellung, wodurch Sprint-Reviews für Feedback, Lernprozesse und die Produktausrichtung an Bedeutung gewinnen.

Robbin Schuurman

Aktualisiert Oktober 15, 2026

13 Minuten

Artikel 5 von 9 in dieser Reihe.

Stellen Sie sich eine Sprint-Review vor, bei der sich alle Anwesenden einig sind, dass sie ein Erfolg ist. Der Product Owner führt die Stakeholder durch drei Funktionen. Die Demo verläuft reibungslos. Die Benutzererfahrung wurde in der Woche zuvor von einem KI-Design-Agenten optimiert, und das macht sich bemerkbar. Die Stakeholder nicken, stellen zwei freundliche Fragen und spenden dem Team Beifall. Bei der anschließenden Retrospektive wird das Engagement der Stakeholder lobend hervorgehoben.

Zwei Wochen später liegt die Akzeptanz aller drei Funktionen unter fünfzehn Prozent. An der Eskalationssitzung nehmen dieselben Beteiligten teil. Bei der Sprint-Review wurde die Zufriedenheit mit der Präsentation gemessen, nicht mit dem Produkt. Das ist das Muster, das ich in diesem Artikel benennen und abschaffen möchte.

In den ersten vier Artikeln dieser Reihe habe ich eine Definition von Wert vorgestellt, dargelegt, dass Verantwortlichkeit eher bündelt als auflöst, die Verfeinerung als „Option Framing“ neu definiert und die Anforderungen an das Inkrement erhöht, um dessen Übernahme sicherzustellen. Alle vier dieser Stränge laufen in einem einzigen Scrum-Event zusammen. Dieses Event ist derzeit das schwächste Glied im Arbeitsrhythmus des KI-gestützten Teams. Warum versagt die Sprint-Review so regelmäßig bei den Teams, die sie am dringendsten benötigen?

Dies ist ein visionärer Beitrag, kein prognostischer. Ich kann Ihnen nicht genau sagen, wie sich die Sprint-Review in den nächsten fünf Jahren entwickeln wird. Ich kann Ihnen jedoch darlegen, wie sich die Sprint-Review nach Ansicht einer Gruppe erfahrener Professional Scrum Trainer weiterentwickeln muss und warum eine andere Tagesordnung – beginnend mit Ihrer nächsten Sitzung – die Erkenntnisse verändern wird, die Sie daraus gewinnen. Die vollständige Liste der Mitwirkenden des Face-to-Face-Events in Amsterdam finden Sie am Ende des Artikels. Die hier dargelegten Argumente stammen von mir. Die Überlegungen stammen von uns allen.

Der Scrum-Leitfaden hat es richtig erkannt

Im Scrum Guide wird die Sprint-Review als Arbeitssitzung beschrieben. Das Scrum-Team und die Stakeholder prüfen die Ergebnisse des Sprints und legen künftige Anpassungen fest. Der Begriff „Demo“ kommt im Guide an keiner Stelle vor.

Machen Sie keinen Fehler: Der Scrum Guide ist in Bezug auf dieses Ereignis nicht fehlerhaft. Die Begrifflichkeit, der Zweck und die Erwartungen an die Zusammenarbeit der Beteiligten sind alle korrekt definiert. Was sich in der Praxis jedoch verändert hat, ist das Ereignis selbst: In zu vielen Produktteams hat sich eine Arbeitssitzung still und leise zu einer Präsentation gewandelt. KI ist nicht die eigentliche Ursache für diese Entwicklung, doch sie wird das Problem noch erheblich verschlimmern.

Warum sich das Demo-Muster hartnäckig hält und warum KI es noch verschlimmert

Drei Faktoren sorgen dafür, dass das Demo-Muster fortbesteht. Demos lassen sich leicht durchführen. Die Beteiligten sind durch jahrzehntelange Unternehmensrituale darauf konditioniert, sie zu erwarten. Und die Rückmeldungen, die eine Demo vermittelt – die Teilnehmerzahl, zustimmendes Nicken, Lächeln und Applaus – sind leichter zu deuten als die Signale, die sich aus einer tatsächlichen Ergebnisprüfung ergeben.

KI macht die erste Kraft mittlerweile kinderleicht stark. Ein Agent kann einen Demo-Ablauf optimieren, das Walk-Through-Skript erstellen und die Funktion so darstellen, dass sie in weniger als einer Stunde optimal zur Geltung kommt. Das ist eine nützliche Fähigkeit. Sie ist jedoch auch gefährlich, denn Perfektion galt schon immer als Indikator für Qualität, und Perfektion ist mittlerweile kostengünstig zu erreichen. Ein Team kann alle zwei Wochen eine makellose Demo zur Sprint-Review vorlegen, ohne jemals ein validiertes Ergebnis zu liefern.

Sollte die Sprint-Review weiterhin so gestaltet sein, dass sie sich an dem orientiert, was KI am einfachsten leisten kann, wird sie mit jedem Sprint an Aussagekraft verlieren.

So sieht eine gelungene Sprint-Review bereits aus

Bevor ich auf die Erweiterung im Zeitalter der KI eingehe, möchte ich auf einen wichtigen Punkt hinweisen. Viele Produktteams, mit denen ich zusammenarbeite, führen seit Jahren Sprint-Reviews durch, die bereits vom üblichen Demo-Muster abweichen; der in diesem Artikel beschriebene Wandel hin zur KI beginnt nicht bei Null, sondern baut auf einer bereits bewährten Vorgehensweise bei der Durchführung dieser Veranstaltung auf.

Anfang 2025 habe ich zwei Beiträge veröffentlicht, in denen ich den Ansatz dargelegt habe, den ich unterrichte. Der erste Beitrag, „Wie man Sprint-Reviews durchführt, die das Produkt tatsächlich voranbringen“, schlägt eine einfache Metapher vor, die den Zweck dieser Veranstaltung neu definiert. Der zweite Artikel, „Eine praktische Agenda und Vorgehensweise für die Durchführung hervorragender Produkt-Reviews“, setzt dies in eine konkrete zweistündige Agenda um. Zusammen bilden sie die Grundlage, auf der der Rest dieses Artikels aufbaut.

Die Metapher ist ein Auto. Fünf Teile, von denen jedes eine eigene Rolle bei der Sprint-Review spielt.

Der Rückspiegel. Bewusst kurz gehalten. Ein kurzer, ergebnisorientierter Überblick darüber, was im gerade abgeschlossenen Sprint umgesetzt wurde und welche Veränderungen sich ergeben haben; gerade genug Hintergrundinformationen, um die nächsten Schritte zu begründen.
Die Windschutzscheibe. Worauf sich der Großteil der Diskussion konzentrieren sollte. Wohin entwickelt sich das Produkt, welche nächsten Schritte sind geplant, und welche Veränderungen in der Welt beeinflussen die Richtung?
Die Seitenfenster. Trends, Kundenrückmeldungen, Marktveränderungen, Schritte der Wettbewerber, Beobachtungen aus den Bereichen Vertrieb, Kundensupport und Rechtsabteilung. Die Beteiligten bringen diese Informationen ein; das Team nimmt sie zur Kenntnis und passt sich entsprechend an.
Das Lenkrad. Die Sprint-Review muss zu Entscheidungen führen oder diese zumindest vorbereiten. Wenn im Anschluss an die Veranstaltung keinerlei Steuerung erfolgt, handelt es sich lediglich um eine Statusaktualisierung mit zusätzlichen Schritten.
Die Beifahrersitze. Sie sind aktiv beteiligt. Sie sind kein Publikum, sondern Mitstreiter. Fragen Sie nach ihrer Sichtweise. Teilen Sie Ihre Unsicherheiten mit. Bitten Sie um echte Rückmeldungen.

Ein weiterer praktischer Tipp aus dem zweiten Beitrag ist es wert, an dieser Stelle hervorgehoben zu werden, da er die Art und Weise, wie die Beteiligten den Raum betreten, grundlegend verändert. Eröffnen Sie die Sprint-Review mit einer Geschichte – dreißig Sekunden lang –, die die Arbeit mit einer konkreten menschlichen Auswirkung verknüpft. Ein Kunde, dem geholfen wurde, ein Problem, das jemandem geschadet hat, eine Aufgabe, die in diesem Sprint schwieriger geworden ist. Interessengruppen engagieren sich für das, was auf dem Spiel steht; sie engagieren sich nicht für den Status quo.

Dieses Muster hat sich für Produktteams seit Jahren bewährt. „Hören Sie auf mit Vorführungen, beginnen Sie mit der Zusammenarbeit“ – das ist das Prinzip, das dahinter steht. Die meisten Sprint-Reviews, die Produkte voranbringen, ähneln viel eher diesem Ansatz und weit weniger einer Präsentation.

Im weiteren Verlauf dieses Artikels wird dasselbe Muster auf das Zeitalter der KI ausgeweitet. Die Metapher mit dem Auto bleibt bestehen. Die Agenda bleibt unverändert. Was sich jedoch verschärft, sobald die Akteure ins Spiel kommen, ist die Art der Beweise, die auf den Tisch gelegt werden müssen, sowie die Geschwindigkeit, mit der vom Team erwartet wird, darauf zu reagieren.

Die Überprüfung der Evidenz

Bezeichnen Sie den Ersatz im Zeitalter der KI als „Evidence Review“. Es handelt sich dabei nicht um eine neue Agenda, sondern um die Agenda der „Auto-Metapher“, die durch die Art von Belegen und den Entscheidungsrhythmus geschärft wurde, die ein KI-gestütztes Team einbringen muss. Die vier Fragen, die bei jedem Sprint Review ausnahmslos in dieser Reihenfolge gestellt werden, lauten wie folgt:

Worauf haben wir gewettet? Dies ist ein direkter Auszug aus dem Optionsrahmen des dritten Artikels dieser Reihe. Der Product Owner liest das Ergebnis und die Wette vor, zu der sich das Team bei der Verfeinerung verpflichtet hat. Eine nachträgliche Änderung ist nicht zulässig.
Was haben wir ausgeliefert? Kurz, sachlich, ohne Darbietung. Welches Inkrement wurde veröffentlicht, für welche Kohorte und wann? Keine Demo-Präsentation, es sei denn, ein Stakeholder wünscht dies ausdrücklich.
Was haben die Nutzer damit gemacht? Dies ist der Kern des Ereignisses. Daten zur Akzeptanz, Kohortenanalysen, Veränderungen bei den Support-Tickets – all dies sind Belege für den Akzeptanzzuwachs aus dem vierten Artikel dieser Reihe. Lautet die Antwort „Das wissen wir noch nicht“, wird dies im Rahmen des Ereignisses bewusst als Risiko im Produkt-Backlog erfasst.
Wie lautet der nächste Einsatz? Der Product Owner unterbreitet einen Vorschlag, das Team und die Stakeholder hinterfragen diesen, und die Veranstaltung endet mit mindestens einem potenziellen Eintrag in den Optionsrahmen der nächsten Verfeinerungsrunde.

Die vier Fragen lassen sich klar auf das Auto übertragen. Die Fragen 1 und 2 entsprechen dem Rückspiegel: kurz, ergebnisorientiert und gerade ausreichend, um den Rest des Gesprächs zu verankern. Frage 3 blickt gemeinsam aus den Seitenfenstern und durch die Windschutzscheibe: Was haben echte Nutzer tatsächlich getan, und was sagt uns das über die Welt, durch die das Produkt fährt? Frage 4 betrifft gemeinsam die Windschutzscheibe und das Lenkrad: Wohin geht es als Nächstes, und welche Entscheidung trifft das Team heute, um dorthin zu gelangen?

Vier Fragen, etwa fünfundvierzig Minuten und eine Arbeitssitzung, in der Entscheidungen getroffen werden statt Applaus zu ernten.

Was die Interessengruppen anders sehen und tun

Beteiligte, die zum ersten Mal an einer Evidenzprüfung teilnehmen, sind oft verwirrt. Wo sind die Screenshots? Wo ist die Schritt-für-Schritt-Anleitung? Wo ist der Höhepunkt, der Beifall verdient?

Die ersten zwei oder drei Evidenzüberprüfungen verlaufen ruhiger als die Demo-Überprüfungen, die sie abgelöst haben. Gut so. Diese Ruhe entsteht dadurch, dass sich die Beteiligten daran gewöhnen, tatsächlich Arbeit leisten zu müssen. Die Tagesordnung weist ihnen eine Aufgabe zu: die Evidenz auf Herz und Nieren zu prüfen, die nächste Hypothese zu hinterfragen und ihr Wissen über den Markt, die Kunden und das Wettbewerbsumfeld einzubringen. Eine gut durchgeführte „Evidence Review“ verwandelt die Stakeholder von einem Publikum in ein zweites Team. Das war schon immer die Absicht des Scrum-Leitfadens. Den meisten Stakeholdern wurde einfach noch nie die Aufgabe übertragen, diese Rolle zu übernehmen.

Wo Makler helfen – und wo nicht

Agenten sind im Rahmen einer Evidenzprüfung von großem Nutzen. Sie können Übersichtsdashboards erstellen, Kohortenvergleiche zusammenfassen und einen ersten Analyseentwurf dazu erstellen, warum sich eine Wette bewegt hat oder nicht. Sie können die Unterlagen vorbereiten.

Agenten halten keine Präsentationen, sie erzählen keine Geschichten und sie treten nicht vor den Beteiligten auf. Der Product Owner ist für die Darstellung der Nachweise verantwortlich, denn, wie im zweiten Artikel dieser Reihe dargelegt wurde, konzentriert sich die Verantwortlichkeit; sie wird nicht übertragen. Ein Mitarbeiter, der die Daten zusammenfasst, ist ein nützlicher Assistent. Ein Mitarbeiter, der die Sprint-Review durchführt, stellt ein Leck in der Verantwortlichkeit dar und birgt ein potenzielles Glaubwürdigkeitsproblem.

Wie dies in der Praxis aussieht

Kehren wir zum SaaS-Onboarding-Team zurück, das bereits in früheren Teilen dieser Serie vorgestellt wurde. Nach dem alten Demo-Modell hätte man den Stakeholdern im Rahmen der Sprint-Review den neu gestalteten Onboarding-Ablauf anhand einer überzeugenden UX-Präsentation vorgestellt. Zustimmendes Nicken. Beifall.

Im Rahmen einer „Evidence Review“-Agenda eröffnet die Product Ownerin die Sitzung stattdessen mit dem „Option Frame“: Die Hypothese lautete, dass durch die Beseitigung von Reibungsverlusten die Aktivierungsrate von 42 % auf 60 % steigen würde. Sie erläutert, welche Funktionen für welche Zielgruppe an welchem Tag bereitgestellt wurden. Anschließend werden die Akzeptanzdaten vorgestellt: Die 7-Tage-Aktivierungsrate liegt bei 47 %, nicht bei 60 %. Die Anzahl der Support-Tickets blieb unverändert. Die Reaktivierungsrate stieg leicht an. Sie schlägt die nächste Hypothese vor: Das Team geht nun davon aus, dass nicht Reibungspunkte, sondern Unsicherheit die Aktivierung blockierten, und im nächsten Sprint wird ein Transparenz-Panel für Wechselkurse bei einer Kohorte von KMU-Nutzern getestet. Ein Stakeholder aus dem Vertrieb stellt die Hypothese in Frage, legt drei aktuelle Protokolle verlorener Geschäfte vor und schlägt eine alternative Herangehensweise vor. Die Product Ownerin berücksichtigt dies im Optionsrahmen der nächsten Verfeinerung.

Die Veranstaltung endet pünktlich, ohne Applaus und mit zwei konkreten Beschlüssen als Ergebnis. Genau das sollte eine Stunde, die den Beteiligten zur Verfügung steht, bewirken, wenn ein KI-gestütztes Team auf Hochtouren arbeitet.

Fünf Dinge, die Sie bei Ihrer nächsten Sprint-Review tun können

Ersetzen Sie die Demo-Tagesordnung durch die Tagesordnung mit den vier Fragen. Drucken Sie die vier Fragen aus. Hängen Sie sie an die Wand. Gehen Sie sie bei jeder Sprint-Review der Reihe nach durch – und zwar drei Sprints hintereinander.
Legen Sie Nutzungsdaten vor, keine Screenshots. Wenn Sie die Frage „Was haben die Nutzer damit gemacht?“ nicht beantworten können, liegen noch keine Belege vor. Geben Sie dies an. Machen Sie diese Lücke zum nächsten Risiko im Produkt-Backlog.
Beachten Sie die Stimmung im Raum, nicht nur die Daten. Beteiligte, insbesondere erfahrene, kommunizieren ebenso viel durch das, was sie nicht sagen, wie durch das, was sie fragen. Ein versierter Product Owner nimmt das Zögern, das höfliche Lächeln und das vielsagende Schweigen wahr und spricht es laut aus. Agenten tun sich damit schwer. Menschen werden dafür bezahlt.
Beenden Sie jede Sprint-Review mit mindestens einem Kandidaten für den nächsten Optionsrahmen. Ohne Kandidaten gibt es keine Veranstaltung. Die „Review“ trifft Entscheidungen – oder sie bringt gar nichts hervor.
Verfolgen Sie eine Kennzahl: die Entscheidungsverzögerung im Sprint-Review. Es geht nicht um Anwesenheit, es geht nicht um Zufriedenheit. Wie schnell führt die Veranstaltung zu einer Entscheidung, auf die das Team im nächsten Sprint reagieren kann? Lautet die Antwort „Wir werden das offline weiterverfolgen“, ist der Ablauf der Veranstaltung zu langsam. Bei der Sprint-Review muss die Entscheidungsverzögerung bei produktbezogenen Ermessensentscheidungen verkürzt werden, nicht verlängert.

Die Wende

Die Sprint-Review hatte schon immer das Potenzial, die wertvollste Stunde des Sprints zu sein. Seit dreißig Jahren wird dieses Potenzial teilweise durch Demos verschwendet. Die KI wird die Community nun endlich dazu zwingen, diese Veranstaltung so zu nutzen, wie es der Scrum Guide schon immer vorgesehen hat. Nicht, weil der Guide geändert werden müsste. Sondern weil die Kosten, die durch das Verharren im Demo-Modus entstehen – gemessen an nicht implementierten Funktionen und unzufriedenen Stakeholdern – mittlerweile unmöglich zu ignorieren sind.

Nun sind Sie an der Reihe

Zählen Sie bei Ihrer nächsten Sprint-Review die Entscheidungen. Zählen Sie die Belegaussagen. Zählen Sie die Screenshots. Wenn die letzte Zahl größer ist als die ersten beiden zusammen, führen Sie genau das Gespräch, das Ihr Team braucht.

Der nächste Artikel befasst sich mit einem etwas ruhigeren, aber meiner Meinung nach wichtigeren Thema. Wenn die „Evidence Review“ in jedem Sprint neue Erkenntnisse liefert – wo werden diese Erkenntnisse dann gespeichert? Da KI-Agenten zunehmend Aufgaben wie das Verfassen von Entwürfen, das Programmieren und das Zusammenfassen übernehmen, verschwinden die natürlichen Orte, an denen Teams früher implizites Wissen gesammelt haben. Das ist ein Kostenfaktor, der es wert ist, benannt zu werden. Wir sehen uns dort.

Mitwirkende

Dieser Artikel entstand auf der Grundlage der PST-Präsenzveranstaltung Nr. 137 von Scrum.org in Amsterdam. Er wäre ohne die Gespräche mit folgenden Personen nicht möglich gewesen: Dave West, Merel van de Wiel-Riedeman, Tommi Kemppi, Sjoerd Nijland, Jesse Houwing, Robbin Schuurman, Martijn Magermans, Guus Verweij, Steven Deneir, Gregor Stuhldreier, Paul Kuijten, Mehdi Hoseini, Simon Kneafsy, Vivien Colas, Jeroen de Jong, Kate Hobler, Olivier Ledru, Roderick Schoon, Stephan Vlieland, Tiffanie Newton und Karel Smutný. Die hier dargelegten Argumente stammen von mir. Die Überlegungen stammen von uns.

< Lesen Sie den vorherigen Artikel