Sprint Review ohne Feedback? So wird aus der Demo ein Arbeitsgespräch

Wenn im Sprint Review kein brauchbares Feedback entsteht, hilft häufig ein anderer Gesprächsaufbau: Zeigt ein nutzbares Ergebnis im Kontext einer konkreten Frage, ladet die dafür relevanten Stakeholder ein und plant gemeinsame Arbeit ein. Eine lange Präsentation mit „Noch Fragen?“ am Ende macht es den Beteiligten schwer, gezielt beizutragen.

Ein typischer Ablauf: Das Team zeigt erledigte Arbeit, alle nicken, die Zeit ist fast vorbei. Zwei Tage später kommen grundlegende Änderungswünsche über andere Kanäle. Das Review hat Informationen übertragen, aber wenig gemeinsames Verständnis geschaffen. Der folgende Vorschlag hilft, die Rückmeldung früher und konkreter ins Gespräch zu holen.

Den Zweck des Sprint Reviews gemeinsam klären

Im Sprint Review inspizieren Scrum Team und Stakeholder das Ergebnis des Sprints und besprechen, welche Anpassungen sinnvoll sind. Es ist ein Arbeitsgespräch. Der Scrum Guide beschreibt es ausdrücklich in diesem Sinn; es ist kein Freigabetor, das jede Auslieferung bis zum Termin aufhalten muss.

Klärt diesen Zweck vor dem nächsten Termin in eurem Team. Unsere Scrum Cards unterstützen dabei: Ordnet die vorhandenen Karten zu Rollen, Events und Artefakten und besprecht, wie das Review in den Zusammenhang gehört. Das Set enthält 40 Karten und orientiert sich am Scrum Guide von November 2020.

Die Lernkarten ersetzen kein Produktfeedback. Sie helfen aber, ein Missverständnis auszuräumen, bevor ihr den Ablauf verändert. Wenn das Team das Review als interne Leistungsschau versteht, werden die Fragen an Stakeholder anders ausfallen als bei einem gemeinsamen Arbeitsgespräch über das Produkt.

Vor der Einladung eine echte Frage formulieren

Wähle mit dem Team ein oder zwei Fragen aus, deren Antworten die nächsten Entscheidungen beeinflussen können. „Gefällt euch das?“ ist dafür oft zu allgemein. Konkreter wäre: „Könnt ihr mit dieser Übersicht erkennen, welcher Vorgang eure Aufmerksamkeit braucht?“ oder „Welche Information fehlt für euren nächsten Arbeitsschritt?“

Die Frage bestimmt, wen ihr braucht. Wenn es um den Ablauf im Kundendienst geht, sind Menschen mit Kenntnis dieses Ablaufs hilfreich. Eine große Runde von Personen, die das Produkt nur aus Berichten kennen, liefert möglicherweise andere Rückmeldungen. Benenne in der Einladung, welche Perspektive gefragt ist.

Teile notwendige Hintergrundinformationen vorab in kurzer Form. Niemand sollte erst während einer Demo erraten müssen, welches Problem das Team bearbeitet hat. Gleichzeitig braucht es keine umfangreiche Pflichtlektüre. Ein kurzer Kontext mit Ziel, bisheriger Annahme und gewünschter Rückmeldung kann genügen.

Ein Arbeitsablauf für ein 60-Minuten-Review

Die folgende Zeitplanung ist ein eigenes Beispiel für einen überschaubaren Produktbereich. Sie ist keine allgemeine Scrum-Vorgabe. Passt Umfang und Dauer an euren Sprint und die nötige gemeinsame Arbeit an.

Wenn ihr mehrere unabhängige Themen habt, prüft, ob alle Stakeholder für alle Teile gebraucht werden. Eine passende kleinere Runde kann mehr beitragen als ein großer Termin, in dem jede Person lange auf ihren relevanten Abschnitt wartet.

Am Produkt arbeiten statt Folien kommentieren

Zeigt einen nachvollziehbaren Anwendungsfall mit einem klaren Startpunkt. Bei einer neuen Übersicht könnte eine Person beispielsweise einen bestimmten Vorgang finden und den nächsten Schritt erklären. Achtet darauf, wie sie vorgeht und an welcher Stelle sie nachfragt. Das liefert andere Hinweise als eine Erklärung sämtlicher Schaltflächen.

Die Scrum.org-Ressource Conducting the Sprint Review beschreibt das Review ebenfalls als Arbeit mit Stakeholdern und betont die Bedeutung fertiggestellter Arbeit. Unfertige Ideen könnt ihr in geeigneten anderen Gesprächen prüfen; stellt sie nicht als bereits nutzbares Increment dar.

Wenn Nutzende nicht selbst teilnehmen können, benennt die Grenze eurer Rückmeldung. Eine interne Einschätzung aus zweiter Hand ist nicht dasselbe wie eine Beobachtung tatsächlicher Nutzung. Sie kann trotzdem hilfreich sein, sollte aber nicht als Beweis für Kundenakzeptanz ausgegeben werden.

Rückmeldungen in vier Kategorien sortieren

Sammelt zuerst Beobachtungen: „Die Person hat die Statusinformation übersehen.“ Trennt davon Interpretationen: „Die Beschriftung ist möglicherweise unklar.“ Ergänzt Fragen, die noch offen sind, und Ideen für eine Änderung. Diese Trennung verhindert, dass die erste Lösung sofort als einzige mögliche Konsequenz erscheint.

Eine einfache Notizvorlage enthält Fall, Beobachtung, mögliche Bedeutung und nächsten Prüfschritt. Bei einer Rückmeldung wie „Wir brauchen einen zusätzlichen Knopf“ fragst du nach dem zugrunde liegenden Arbeitsproblem. Vielleicht fehlt tatsächlich eine Funktion. Vielleicht ist die vorhandene Funktion nur nicht erkennbar.

Versprecht nicht, jede Idee umzusetzen. Der Product Owner muss Rückmeldungen mit anderen Erkenntnissen und Prioritäten zusammenführen. Erklärt aber, wie Beiträge weiterbehandelt werden. Ein offenes „Wir prüfen die Bedeutung für das Product Backlog“ ist ehrlicher als eine spontane Zusage ohne Abwägung.

Ein fiktives Beispiel: Eine neue Auftragsübersicht

Ein Team zeigt eine neue Übersicht, die verspätete Aufträge sichtbar machen soll. In der bisherigen Demo hatte es erklärt, wie Filter funktionieren. Im neuen Review bittet es eine Person aus dem Service, die drei Aufträge zu nennen, die sie zuerst bearbeiten würde.

Dabei wird sichtbar, dass „verspätet“ allein nicht reicht. Manche Fälle warten auf Kundenzuarbeit, andere auf eine interne Entscheidung. Die Rückmeldung lautet deshalb nicht einfach „mehr Filter“, sondern: Für eine sinnvolle Priorisierung fehlt der Grund der Wartezeit. Das Team kann nun prüfen, welche Information verfügbar ist und wie sie verständlich angezeigt werden kann.

Der Product Owner hält die neue Erkenntnis fest und bespricht die Folgen für die Reihenfolge weiterer Arbeit. Die Stakeholder müssen nicht gleich eine vollständige technische Lösung entwerfen. Ihr Beitrag liegt darin, den tatsächlichen Arbeitsbedarf verständlicher zu machen.

Wenn weiterhin niemand etwas sagt

Gib zunächst kurze stille Denkzeit. Bitte um eine konkrete Beobachtung oder Frage, statt sofort eine allgemeine Bewertung zu verlangen. Du kannst auch zwei gegensätzliche Anwendungssituationen zeigen und fragen, in welcher die Lösung heute eher trägt. Das macht Unterschiede leichter besprechbar.

Prüfe außerdem, ob die Teilnehmenden den Eindruck haben, die Entscheidung sei ohnehin bereits abgeschlossen. Wenn Rückmeldungen regelmäßig ohne Erklärung verschwinden, wird eine neue Moderationstechnik allein wenig ändern. Zeigt im nächsten Review kurz, was aus einer früheren Rückmeldung geworden ist und warum.

Manchmal fehlt tatsächlich etwas Diskussionswürdiges für diese Gruppe. Dann erfindet keine Kritik, um den Termin lebendig wirken zu lassen. Nutzt die Zeit, um veränderte Rahmenbedingungen oder relevante nächste Fragen zu besprechen. Ein Review muss keine lückenlose Show bieten.

Rückmeldungen beim nächsten Review wieder aufgreifen

Beginnt einen späteren Termin mit einem knappen Rückblick auf eine relevante frühere Erkenntnis. Zeigt, ob sie zu einer Änderung, einer weiteren Untersuchung oder einer bewussten anderen Priorisierung geführt hat. Eine nachvollziehbare Begründung ist auch dann wichtig, wenn ein Vorschlag nicht umgesetzt wurde.

So erkennen Stakeholder, dass ihre Beteiligung Folgen hat. Ihr braucht dafür keine lange Liste sämtlicher Kommentare. Wählt die Punkte aus, die eure Produktentscheidung tatsächlich beeinflusst haben. Der Zusammenhang zwischen Rückmeldung und nächstem Schritt macht den Termin über mehrere Sprints hinweg sinnvoll.

Häufige Fragen zum Sprint Review

Ist das Review dasselbe wie die Retrospektive?

Nein. Das Review richtet sich auf Produkt und weitere Anpassung gemeinsam mit Stakeholdern. Die Retrospektive betrachtet die Zusammenarbeit und Arbeitsweise des Scrum Teams. Unsere Retrospektiven-Übersicht hilft bei der Gestaltung dieses anderen Gesprächs.

Wer moderiert das Review?

Das Scrum Team gestaltet den Termin passend. Eine moderierende Person kann hilfreich sein, doch eine bestimmte Moderationsrolle ist nicht der Kern des Zwecks. Wichtig sind relevante Beteiligung, ein verständliches Ergebnis und die Weiterverarbeitung der Erkenntnisse. Die Erklärung der Scrum-Rollen ergänzt die Verantwortlichkeiten. Wählt für euer nächstes Review eine einzige Frage, deren Antwort tatsächlich etwas verändern kann.