Sprint Review Ergebnis zeigen, Feedback einsammeln

Am Ende jedes Sprints kommt der Moment der Wahrheit: Das Team zeigt, was es in den letzten Wochen gebaut hat. Nicht als PowerPoint-Präsentation, sondern als funktionierende Software (oder ein anderes greifbares Ergebnis). Stakeholder geben Feedback, und daraus ergeben sich oft die Prioritäten für den nächsten Sprint.

Sprint Review auf einen Blick

Was?
Demo des Sprint-Ergebnisses + Feedback
Wer?
Scrum-Team + Stakeholder
Dauer
Max. 4 Stunden bei 4-Wochen-Sprint
Ergebnis
Überarbeitetes Product Backlog

Wie läuft ein Sprint Review ab?

Der typische Ablauf in vier Schritten:

  1. Sprint-Ziel vorstellen: Was hatte sich das Team vorgenommen?
  2. Ergebnis zeigen: Was ist fertig geworden? Live-Demo der neuen Funktionalität oder des Arbeitsergebnisses.
  3. Was nicht fertig wurde: Ehrlich kommunizieren — und erklären, warum.
  4. Feedback und Diskussion: Stakeholder kommentieren, fragen nach, bringen neue Ideen ein. Der Product Owner nimmt relevante Punkte ins Backlog auf.

Sprint Review ist keine Demo

Das ist ein häufiges Missverständnis: Das Review ist kein Präsentationstermin, bei dem das Team dem Management „vorführt", was es geschafft hat. Es ist ein Arbeitstermin — ein Gespräch auf Augenhöhe.

Die Stakeholder sind nicht Zuschauer, sondern Teilnehmer. Ihr Feedback fließt direkt in die nächste Planung ein. Das Review ist der Moment, in dem Scrum seine Stärke ausspielt: Feedback-Schleifen statt langer Planungszyklen.

So wird das Review wirklich nützlich

  • Echte Software zeigen: Keine Screenshots, keine Mockups — die tatsächlich funktionierende Anwendung vorführen.
  • Stakeholder aktiv einbeziehen: Lass sie die Software selbst ausprobieren, nicht nur zuschauen.
  • Nicht schönreden: Wenn etwas nicht fertig wurde, sag es. Transparenz schafft Vertrauen — Beschönigung untergräbt es.
  • Backlog direkt aktualisieren: Gutes Feedback verpufft, wenn es nicht festgehalten wird. Der PO sollte im Review mitschreiben.