Kostenlose Vorlage · zum Kopieren

Sprint Review: Vorlage für ein Review, das mehr ist als eine Demo.

Im Sprint Review prüfen Scrum Team und Stakeholder gemeinsam, was im Sprint entstanden ist, und entscheiden, was als Nächstes sinnvoll ist. Die Vorlage hält beides fest: das Ergebnis und die Änderungen, die daraus fürs Product Backlog folgen.

Sprint Review
SPRINT REVIEW

RAHMENDATEN
Team / Produkt: …
Sprint Nr. / Zeitraum: …
Datum / Ort oder Tool: …
Scrum Team: …
Stakeholder: …

SPRINT-ZIEL
Ziel: …
Erreicht? [ ] ja  [ ] teilweise  [ ] nein – weil: …

FERTIG (erfüllt die Definition of Done)
- … – gezeigt von: …
- … – gezeigt von: …

NICHT FERTIG (zurück ins Product Backlog)
- … – was fehlt: …

FEEDBACK DER STAKEHOLDER
- … (von: …)
- … (von: …)

VERÄNDERUNGEN IM UMFELD
Markt, Kund:innen, Budget, Termine, Gesetze: …

FORTSCHRITT ZUM PRODUCT GOAL
Product Goal: …
Wo stehen wir? …

ANPASSUNGEN AM PRODUCT BACKLOG
Neu: …
Höher priorisiert: …
Gestrichen / zurückgestellt: …

OFFENE FRAGEN UND NÄCHSTE SCHRITTE
[ ] … – wer – bis wann
Input fürs nächste Sprint Planning: …
Wann du sie brauchst
  • Am Ende jedes Sprints, vor der Retrospektive
  • Wenn Kund:innen oder Fachbereiche das Ergebnis selbst sehen sollen
  • Bevor über eine Freischaltung oder ein Release entschieden wird
  • Wenn sich Prioritäten im Umfeld geändert haben und das Backlog angepasst werden muss
Lieber gar nicht mehr tippen?

noteit schreibt deine Calls mit und füllt Zusammenfassung, Entscheidungen und To-dos automatisch aus – in Teams, Zoom & Co.

7 Tage gratis testen
Ausgefülltes Beispiel

Ziel erreicht, ein Item zurück, eine neue Priorität.

Erfundenes Beispiel, das an die Sprint-Planning-Vorlage anschließt: Das Team eines Reiseportals hat zwei Wochen an der Umbuchung gearbeitet. Die Leiterin der Hotline sieht das Ergebnis zum ersten Mal.

Sprint Review · Sprint 24 · Team Buchung · Reiseportal Wanderzeit
Rahmendaten

30. Oktober, 13:00–14:10 · Teams

Scrum Team: Markus Leitgeb (Product Owner), Lisa Weber (Scrum Master), fünf Developers

Stakeholder: Petra Hofbauer (Leitung Hotline), Jakob Strasser (Partnermanagement)

Sprint-Ziel

Gäste können eine Buchung selbst umbuchen, ohne die Hotline anzurufen. Erreicht.

Fertig und gezeigt

WZ-412 neuen Termin wählen, WZ-415 Preisdifferenz, WZ-418 Bestätigungsmail, WZ-421 Protokoll fürs Backoffice, WZ-399 Datumsfilter in Safari.

Petra Hofbauer hat eine Umbuchung in der Testumgebung selbst durchgeklickt.

Nicht fertig

WZ-420 Stornobedingungen anzeigen – Texte der Rechtsabteilung kamen erst am letzten Tag. Zurück ins Product Backlog.

Feedback

Hotline: Umbuchungen weniger als 48 Stunden vor Anreise führen bei kleinen Hütten zu Problemen – dort lieber sperren. (Petra Hofbauer)

Partnermanagement: Partnerbetriebe wollen per Mail erfahren, wenn ein Gast umbucht. (Jakob Strasser)

Umfeld und Product Goal

Wintersaison startet am 1. Dezember, danach steigen Anrufe stark.

Product Goal „Gäste verwalten ihre Buchung komplett selbst“: Umbuchen fertig, Stornieren und Personen ändern fehlen noch.

Anpassungen am Product Backlog

Neu und ganz oben: WZ-436 Umbuchung bis 48 Stunden vor Anreise begrenzen.

Neu: WZ-437 Partnerbetrieb per Mail über Umbuchung informieren.

Zurückgestellt: WZ-430 Gutschein statt Rückzahlung.

Nächste Schritte

Markus Leitgeb entscheidet über die Freischaltung, sobald WZ-436 fertig ist – voraussichtlich im nächsten Sprint.

Petra Hofbauer schickt drei typische Umbuchungsfälle aus der Hotline – bis 3. November.

Tipps

Ein Review, nach dem das Backlog anders aussieht.

Arbeitstermin statt PräsentationDer Scrum Guide warnt ausdrücklich davor, das Review auf eine Präsentation zu beschränken. Lass Stakeholder selbst klicken und frag nach, statt Folien zu zeigen.
Nur Fertiges zeigenWas die Definition of Done nicht erfüllt, ist nicht Teil des Increments. Zeig es nicht als fertig – sonst rechnet jemand fest damit.
Die richtigen Leute einladenWer das Produkt nutzt, verkauft oder betreut, gibt das wertvollste Feedback. Ein Review nur im Team verschenkt seinen Zweck.
Feedback mit NamenNotiere, von wem ein Wunsch kommt. Der Product Owner kann dann nachfragen, statt zu raten, was gemeint war.
Backlog im Termin anpassenNeue Items und geänderte Prioritäten gehören ins Protokoll, solange alle im Raum sind. Das ist das eigentliche Ergebnis des Reviews.
Kein Freigabe-TorLaut Scrum Guide ist das Review keine Hürde für ein Release – fertige Arbeit darf auch vorher ausgeliefert werden. Im Review wird geprüft und angepasst.
Typische Fehler
  • Folienvortrag ohne Fragen und Diskussion
  • Halbfertiges wird als „fast fertig“ vorgeführt
  • Keine Stakeholder dabei, nur das Scrum Team
  • Feedback wird gesammelt, aber nie ins Product Backlog übertragen
  • Review und Retrospektive werden in einem Termin vermischt

Diese Vorlage dient der allgemeinen Orientierung und ersetzt keine individuelle Beratung. Prüfe sie vor der Verwendung auf deinen Einzelfall.

Häufige Fragen
Wie lange dauert ein Sprint Review?

Der Scrum Guide 2020 nennt höchstens vier Stunden für einen einmonatigen Sprint, bei kürzeren Sprints ist es meist kürzer. Für zwei Wochen reichen oft 60 bis 90 Minuten.

Was ist der Unterschied zwischen Sprint Review und Retrospektive?

Im Review geht es ums Produkt: Was ist entstanden, was kommt als Nächstes? In der Retrospektive geht es um die Zusammenarbeit des Teams. Das Review findet zuerst statt, die Retro schließt den Sprint ab.

Wer nimmt am Sprint Review teil?

Das Scrum Team und wichtige Stakeholder, etwa Kund:innen, Fachbereiche oder die Geschäftsführung. Der Product Owner lädt sie ein.

Darf man im Sprint Review Arbeiten zeigen, die nicht fertig sind?

Man kann darüber sprechen, aber nicht als Teil des Increments vorführen. Unfertige Items gehen zurück ins Product Backlog und werden neu eingeplant.

Protokoll schreiben?
Macht ab jetzt noteit.

7 Tage alles aus Pro gratis – ohne Kreditkarte.

Jetzt kostenlos testen