Skip to content

Vorlage – Scrum Sprint Review Meeting (60 Min.)

Zweck des Sprint Reviews:
Das Inkrement prüfen, konkretes Stakeholder-Feedback einholen und Produkt sowie Backlog bei Bedarf anpassen.
Wichtig: Keine Retrospektive, keine Status-Show.

1. Vorbereitung (PO / SM)

Checkliste:

  • [ ] Meetingagenda mindestens 24h vorher versenden
  • [ ] Teilnehmende & Rollen in der Agenda aufführen (PO, Dev Team, relevante Stakeholder)
  • [ ] Sprint-Ziel & „Done vs. Geplant“ klar formuliert
  • [ ] Ort für Feedback/Notizen festlegen (z. B. Planner, Trello, Jira, OneNote)

2. Ablauf & Agenda (Timer max. 60 Min.)

Regeln:

  • Live-Demo am Produkt, keine Folienpräsentation
  • Fragen willkommen
  • Detaillierte Technik-Diskussionen → Parking Lot

2.1 Kick-off & Ziel – 0–3 Min (Scrum Master)

  • Timer starten
  • Zweck, Ablauf, Rollen kurz erklären

2.2 Sprint-Ziel & Umfang – 3–7 Min (Product Owner)

  • Sprint-Ziel in 1 Satz
  • Was ist „Done“, was nicht? (kurz & ehrlich)

2.3 Live-Demo des Inkrements – 7–35 Min (Dev Team)

  • In 2–4 Szenarien demonstrieren
  • Akzeptanzkriterien sichtbar erfüllen
  • Fokus: Nutzerwert, nicht Technik
  • Scrum Master sammelt Fragen/Feedback im Board (z. B. Miro, Jira, Whiteboard)

2.4 Stakeholder-Feedback & Wirkung – ca. 20–30 Min (PO moderiert, SM unterstützt)

Leitfragen:

  • Entspricht das Gezeigte euren Erwartungen?
  • Wo seht ihr Nutzen, Lücken oder Risiken?
  • Was sollen wir als Nächstes priorisieren oder ändern?

Ergebnis:

  • Annahmen bestätigt oder widerlegt
  • Neue oder angepasste Backlog-Einträge grob skizziert und grob priorisiert

2.5 Entscheidungen & Next Steps – ca. 20–40 Min (SM)

  • Welche Items werden als akzeptiert betrachtet, welche sind noch offen?
  • Backlog-Änderungen festhalten (Owner: Product Owner)
  • Action Items definieren: Wer macht was bis wann?

2.6 Ausblick & Abschluss – 58–60 Min (Product Owner)

  • Kurzer Ausblick auf mögliches nächstes Sprint-Ziel
  • Dank & Verabschiedung

3. Erfolgskriterien (DoD fürs Review)

Ein Sprint Review gilt als „gut“, wenn:

  • Stakeholder-Feedback konkret erfasst wurde
  • Backlog-Einträge erstellt oder angepasst und grob priorisiert sind
  • Action Items mit Owner & Termin definiert sind
  • Die Timebox eingehalten wurde

4. Nachbereitung (≤ 24h) durch SM / PO

Checkliste:

  • [ ] Kurzprotokoll teilen (Entscheidungen, Feedback-Highlights, Action Items, Links zur Aufnahme/Artefakten)
  • [ ] Backlog aktualisiert (PO): neue/angepasste PBIs inkl. Priorität & Notizen
  • [ ] Action Items nachverfolgen (SM): Fälligkeiten im Team-Board tracken

Kurzprotokoll-Template (Copy/Paste):

  • Sprint-Ziel: …
  • Gezeigt: …

Entscheidungen:

  • … (Impact: …)

Backlog-Änderungen:

  • NEU/ÄNDERUNG: … (Priorität: hoch/mittel/niedrig)

Action Items:

  • [Owner] → Aufgabe (Fällig: Datum)

Feedback-Highlights:

  • + …
  • ? …
  • → …

5. Einladungs-E-Mail (kurz & klar)

Betreff:
Sprint Review – [Produkt] Sprint [##] (60 Min)

Textvorschlag:

Hallo zusammen,

wir zeigen das Produkt-Inkrement des letzten Sprints live und sammeln euer Feedback für die weitere Priorisierung.

  • Datum: [Datum]
  • Zeit: [Uhrzeit, Zeitzone]
  • Ort/Link: [Konferenz-Link]

Agenda (60 Min):
Ziel (3) · Ziel & Umfang (4) · Live-Demo (28) · Feedback & Wirkung (18) · Entscheidungen (5) · Ausblick (2)

Beste Grüße
[PO/SM]

6. Do / Don’t (Spickzettel)

Do:

  • Live am Produkt zeigen
  • Nutzerfluss zeigen
  • Klare Entscheidungen herbeiführen
  • Akzeptanzkriterien sichtbar machen
  • Zahlen nur zur Einordnung verwenden

Don’t:

  • Status-Folienschlacht
  • Technik-Deep-Dive
  • Neue Schätzrunden
  • Retro-Themen ins Review ziehen

7. Mini-Checklisten (zum Abhaken im Termin)

Während des Reviews (Scrum Master):

  • [ ] Timer im Blick
  • [ ] Fragen & Feedback ins Board schreiben
  • [ ] Parking-Lot pflegen
  • [ ] Entscheidungen laut wiederholen & bestätigen

Vor Abschluss:

  • [ ] Akzeptiert vs. Offen klar benannt?
  • [ ] Backlog-Anpassungen benannt?
  • [ ] Action Items (Owner + Termin) gesetzt?