Der Sprint Review nimmt eine konkrete und wichtige Position im Scrum-Framework ein. Es ist das Event, in dem das empirische Herz von Scrum konkret wird: echte Arbeit wird von echten Stakeholdern überprüft, echtes Feedback wird gesammelt, und der Product Backlog wird basierend auf dem Gelernten aktualisiert. Gut gemacht, ist er eines der wertvollsten Events im Sprint. Schlecht gemacht, als Formalität, Präsentation, oder Leistungsbeurteilung des Entwicklungsteams, erzeugt er Konformität ohne Erkenntnis.
Wofür er da ist
Der Zweck des Sprint Review ist, das Increment zu überprüfen und den Product Backlog entsprechend anzupassen. Das klingt einfach, hat aber bedeutsame Implikationen dafür, wie das Event ablaufen sollte.
"Überprüfen" bedeutet, genuin zu untersuchen, was gebaut wurde: ob es wie beabsichtigt funktioniert, ob es den erwarteten Wert liefert, und ob es verändert, was Team und Stakeholder darüber verstehen, was als Nächstes kommen sollte. Das ist eine Arbeitssitzung, keine Vorführung. Stakeholder sollten sich mit dem tatsächlichen Produkt auseinandersetzen, echte Fragen stellen, und Feedback geben, auf das reagiert werden kann.
"Anpassen" bedeutet, dass der Product Backlog am Ende eines Sprint Review sichtbar anders sein sollte als zu Beginn. Neue Elemente könnten basierend darauf hinzugefügt werden, was die Demonstration offenbart hat. Bestehende Elemente könnten basierend auf Feedback neu priorisiert werden. Elemente, die angesichts des Gebauten keinen Sinn mehr ergeben, könnten entfernt werden. Ein Sprint Review, bei dem der Backlog unverändert bleibt, ist ein Sprint Review, bei dem kein echtes Lernen stattgefunden hat.
Wie er durchgeführt wird
Vorbereitung. Das Scrum-Team überprüft den Sprint Backlog vor dem Event und stellt sicher, dass alle abgeschlossene Arbeit tatsächlich der Definition of Done entspricht. Alles, was die DoD nicht erfüllt, sollte nicht als vollständig präsentiert werden. Stakeholder sollten mit genug Vorlauf eingeladen werden, um sinnvoll teilnehmen zu können, und sie sollten den Zweck des Events verstehen, nicht als Abnahme-Zeremonie, sondern als kollaborative Arbeitssitzung.
Das Increment präsentieren. Das Entwicklungsteam demonstriert, was während des Sprints gebaut wurde. Der Schwerpunkt sollte auf dem Zeigen funktionierender Funktionalität liegen, nicht auf Folien oder Berichten über Funktionalität. Echte Nutzende und Stakeholder, die sich mit echter Software auseinandersetzen, erzeugen nützlicheres Feedback als jede Präsentation. Kann das Increment nicht demonstriert werden, ist das selbst eine bedeutsame Information über die Natur der Arbeit.
Feedback sammeln. Nach der Demonstration verschiebt sich das Gespräch zu Feedback und Fragen. Was haben Stakeholder beobachtet? Entspricht es dem Erwarteten? Was offenbart es über das, was als Nächstes benötigt wird? Das ist eine aktive, kollaborative Diskussion, das Scrum-Team sollte in dieser Phase mehr zuhören als präsentieren.
Über nächste Schritte entscheiden. Der letzte Teil des Sprint Review ist zukunftsgerichtet: Was bedeutet das in dieser Sitzung Gelernte für den Product Backlog? Was sollte nach oben, was nach unten, was sollte hinzugefügt werden? Die Product-Owner-Person moderiert dieses Gespräch typischerweise, und das Ergebnis sollte eine Reihe konkreter Änderungen am Backlog sein, nicht allgemeine Eindrücke, die später verarbeitet werden.
Wer teilnimmt
Das Scrum-Team, Product-Owner-Person, Scrum Master und Developer, nimmt am Sprint Review teil. Die Product-Owner-Person kümmert sich typischerweise um Einladungen an Stakeholder, zu denen Kund:innen, Nutzende, Führungskräfte oder andere Teams gehören können. Der Scrum Guide ist flexibel darüber, wer konkret teilnehmen sollte, was die Realität widerspiegelt, dass relevante Stakeholder je nach Kontext und Sprint variieren.
Eine Anmerkung: Der Sprint Review ist kein geschlossenes Event. Ein breites Spektrum an Stakeholdern einzubeziehen, einschließlich Menschen, die nicht an der Erstellung der Anforderungen beteiligt waren, erzeugt oft das nützlichste Feedback. Die Person, die das Produkt täglich nutzt, aber nie zu seiner Entwicklung konsultiert wurde, hat häufig die direkteste Einsicht darin, ob das Gebaute tatsächlich nützlich ist.
Häufige Scheiternsmuster
Der Sprint Review scheitert am häufigsten, wenn er zur Formalität wird: ein regelmäßiger Termin im Kalender, an dem das Team Arbeit einem weitgehend passiven Publikum präsentiert, das zustimmt und weitergeht. Sind Stakeholder nicht engagiert, ist Feedback nicht konkret, und ändert sich der Backlog nicht, ist das Event zu Overhead geworden statt zu Wert.
Das zu beheben, erfordert meist eher eine Veränderung der Raumdynamik als der Agenda: weniger Folien, mehr Demonstration, mehr echte Fragen, explizite Zeit für Backlog-Diskussion. Das Event sollte sich wie eine Zusammenarbeit zwischen dem Team und den Menschen anfühlen, denen das Produkt dient, nicht wie ein Quartalsbericht von einer Partei an die andere.