Wie führst du ein effektives Sprint Review durch?

Review ist nicht Status

Häufiger Fehler: Sprint Review wird zum Powerpoint-Status-Meeting. Richtiger Fokus: Live-Demo der gebauten Funktionen. Stakeholder sehen, was wirklich funktioniert, geben sofort Feedback. Folien sind verboten, außer für Kontext. Wenn keine Demo möglich (z.B. interner Refactor), ist der Punkt vermutlich nicht im richtigen Sprint.

Wer ist dabei

Pflicht: Product Owner, Entwicklungsteam, Scrum Master. Optional aber wertvoll: relevante Stakeholder (Vertrieb, Marketing, Top-Kunden). Kunden direkt einladen wirkt Wunder für Praxis-Bezug. Nicht: Personen, die keinen Bezug zum Produkt haben, sonst wird das Meeting zur Show statt zum Arbeitsmeeting.

Strukturierter Ablauf

1) Sprint-Ziel kurz wiederholen (2 Min). 2) Was haben wir geschafft, was nicht (5 Min). 3) Demo pro Story (Hauptteil, 30-60 Min). 4) Feedback und Diskussion (15 Min). 5) Ausblick nächster Sprint und Backlog-Anpassung (15 Min). Diese Struktur hält das Meeting fokussiert.

Feedback verarbeiten

Feedback aus dem Review wird sofort vom Product Owner ins Backlog aufgenommen, priorisiert, ggf. in neue Stories umgewandelt. Wer Feedback einsammelt und nicht verarbeitet, demotiviert Stakeholder. Sichtbare Konsequenz aus Reviews macht aus dem Meeting echte Steuerung, nicht Theater.