Der Wert eines Sprint Review hängt stark davon ab, ob während des Events die richtigen Fragen gestellt werden. Teams, die nur zeigen, was gebaut wurde, ohne eine strukturierte Reihe von Fragen, die das anschließende Gespräch leiten, erhalten tendenziell höfliches Nicken statt des substanziellen Feedbacks, das das Event eigentlich hervorbringen soll.

"Löst das das Problem, das wir dachten zu lösen?" Das ist die Frage, die den gesamten Review verankern sollte, und die am leichtesten übersprungen wird, wenn es hektisch darum geht, das Gebaute zu zeigen. Ein Feature kann genau nach Spezifikation gebaut sein und trotzdem an diesem Test scheitern, wenn sich die zugrunde liegende Annahme über das Problem als falsch herausstellt.

"Was müsste zutreffen, damit das als Misserfolg gilt?" Diese Frage vor dem Feiern von Erfolg zu stellen, bringt die konkreten Erfolgskriterien ans Licht, an denen das Team tatsächlich gearbeitet hat, statt eines vagen Gefühls, dass "es funktioniert". Kann niemand diese Frage klar beantworten, lohnt es sich, das zu wissen, bevor weitere Arbeit auf einem unklaren Fundament aufbaut.

"Was haben wir gelernt, das wir nicht erwartet hatten?" Die wertvollsten Sprint Reviews bringen oft Information hervor, die niemand als nötig antizipiert hatte: eine technische Einschränkung, die den Plan ändert, eine Nutzerreaktion, die einer Annahme widerspricht. Explizit danach zu fragen, statt darauf zu warten, dass es natürlich zur Sprache kommt, macht es wahrscheinlicher, dass es ans Licht kommt.

"Was sollte das am Product Backlog ändern?" Ein Sprint Review, der zu keiner Backlog-Änderung führt, ist entweder einer, bei dem nichts gelernt wurde (unwahrscheinlich), oder bei dem das Gelernte nicht in Handlung übersetzt wurde (wahrscheinlicher und untersuchenswert). Diese Frage erzwingt die Verbindung zwischen dem Review-Gespräch und dem Artefakt, das es eigentlich aktualisieren soll.

"Wer war nicht im Raum, der das hätte sehen sollen?" Stakeholder-Lücken summieren sich still. Ein Review, an dem nur Menschen teilnehmen, die der Richtung ohnehin schon zustimmen, erzeugt Bestätigung, keine Prüfung. Zu identifizieren, wer fehlt, und konkret warum diese Perspektive wichtig ist, lohnt sich als regelmäßige Überprüfung.

"Ist das tatsächlich fertig, oder sieht es nur fertig aus?" Zu unterscheiden zwischen etwas, das die Definition of Done erfüllt, und etwas, das dem fertigen Feature in einer Demo nur ähnelt, ist ein echtes, wiederkehrendes Risiko, besonders bei UI-lastiger Arbeit, wo die visuelle Ebene der zugrunde liegenden Funktionalität voraus sein kann.

"Was ist der kleinste nächste Schritt, der mehr Wert schafft?" Den Review damit zu beenden, den nächsten inkrementellen Schritt zu identifizieren, statt direkt zu "was steht als Nächstes auf der Roadmap" zu springen, hält das Gespräch am tatsächlichen Zustand des Produkts verankert statt am aspirativen Plan.

Alle sieben bei jedem einzelnen Review zu stellen, wäre ein erschöpfendes Meeting. Der Wert liegt darin, sie verfügbar zu haben, und zu bemerken, wenn ein Review still mehrere davon übersprungen hat, ohne dass jemand nach dem Warum fragt.