Das Sprint Review ist eines der zentralen Ereignisse im Scrum Framework. Es findet am Ende jedes Sprints statt und dient dazu, dem Team und den Stakeholdern zu zeigen, was tatsächlich geliefert wurde – und gemeinsam Feedback zu sammeln, um das Produkt kontinuierlich zu verbessern.
In diesem Artikel zeige ich dir, wie ein Sprint Review konkret abläuft, wie du es mit JIRA unterstützt und welche Best Practices sich in der Praxis bewährt haben.
Was ist ein Sprint Review?
Das Sprint Review ist eine offizielle Scrum-Veranstaltung, die immer am Ende des Sprints stattfindet. Laut Scrum Guide gilt dafür eine Timebox von etwa einer Stunde pro Sprint-Woche – für einen zweiwöchigen Sprint also rund zwei Stunden.
Erfahrung aus der Praxis:
Meist ist eine Stunde vollkommen ausreichend, wenn das Team vorbereitet ist und die Reviews zielgerichtet moderiert werden.
Im Sprint Review trifft sich das Scrum-Team mit den Stakeholdern. Es wird gezeigt, was im Sprint gebaut oder erledigt wurde, und gemeinsam wird besprochen, was als Nächstes wichtig ist.
Kurz gesagt:
- Sprint Review: Produkt verbessern, Stakeholder-Feedback einholen
- Sprint Retrospektive: Team & Prozesse verbessern
Oder, wie man scherzhaft sagt:
Review für die Außenwelt, Retro fürs Überleben.
Der Ablauf eines Sprint Reviews mit JIRA
1. Start des Meetings
Der Scrum Master oder Product Owner eröffnet das Sprint Review und gibt den Rahmen vor. Ziel ist es, transparent zu zeigen, was im Sprint entstanden ist – und offen für Fragen und Feedback zu sein.
Wichtig: Keine PowerPoint-Schlachten. Die Stories sollten für sich sprechen.
2. JIRA Scrum Board teilen
Am besten teilt ein Teammitglied (oder der PO) direkt das JIRA Scrum Board. So sehen alle live, wie der aktuelle Sprint aussieht. Das schafft Transparenz und vermeidet lange Erklärungen.
3. Präsentation der „Done“-Stories
Jetzt stellt das Team die abgeschlossenen Stories vor.
- Zeigt Akzeptanzkriterien, Umsetzung und, wenn möglich, eine kurze Demo (Screenshots, Videos oder live).
- Hier zeigt sich oft: „Done“ ist nicht immer gleich „wirklich fertig“. Aber genau dafür ist das Review da.
4. Feedback der Stakeholder einholen
Stakeholder geben hier Rückmeldungen, stellen Fragen oder äußern neue Wünsche.
Das Team hört aktiv zu – und erklärt geduldig, warum „nur ein kleiner Button“ trotzdem drei Tage Arbeit sein kann.
5. Product Backlog prüfen
Der Product Owner schaut mit dem Team ins Backlog:
- Haben sich Prioritäten durch das Feedback verändert?
- Gibt es neue Anforderungen, die aufgenommen werden müssen?
6. Sprint-Ziel überprüfen
Was wurde erreicht? Was nicht? Und warum?
Manchmal reicht auch schon ein (halb-)fertiger Screenshot, der zumindest gut aussieht.
7. Ausblick auf den nächsten Sprint
Der PO gibt einen kurzen Ausblick auf den nächsten Sprint. Hier kann auch eine Roadmap oder JIRA-Timeline eingeblendet werden, um den Stakeholdern eine Perspektive zu geben.
Best Practices (und ehrliche Wahrheiten)
- JIRA-Board immer live zeigen: Es macht alles transparent – auch das, was man lieber nicht zeigen würde.
- Die richtigen Stakeholder einladen: Sonst wird’s ein Elternabend.
- Auf das Sprint-Ziel fokussieren: Nicht in Details wie Farbvarianten abdriften.
- Feedback direkt ins Backlog aufnehmen: Sonst verschwindet es schneller als ein Bug in der QA-Spalte.
- Timebox einhalten: Nach zwei Stunden hört nur noch der PO zu, weil er muss.
Zusammenfassung
- Das Sprint Review ist der Termin, um Ergebnisse zu zeigen, Feedback zu sammeln und das Produkt weiterzuentwickeln.
- Das JIRA Scrum Board ist dabei das zentrale Tool für Transparenz und Diskussion.
- Gut vorbereitet und moderiert, bleibt das Review im Zeitrahmen und liefert echten Mehrwert – für das Team und die Stakeholder.
Fazit
Ein Sprint Review ist keine lästige Pflicht, sondern eine Chance, gemeinsam mit Stakeholdern das Produkt zu verbessern.
Mit einem klar strukturierten Ablauf und einem aktiven JIRA-Board macht ihr Reviews nicht nur effektiver, sondern auch kurzweiliger – und alle gehen mit einem klaren Bild der nächsten Schritte hinaus.