In diesem Artikel lernst du, was das Meeting ist, wie es abläuft, welche Fehler du nicht machen darfst und wie du das meiste raus holst. Dieses Event stammt aus dem Scrum Framework und ist im Scrum Guide beschrieben.
Übersicht: Das Sprint Review Meeting
Das Sprint Review ist das vorletzte Event im agilen Framework Scrum. Zuvor haben bereits die Sprint Planung und das Daily Scrum stattgefunden. Nach dem Sprint Review folgt noch die Sprint Retrospektive. Das Sprint Review bietet die Möglichkeit das Produkt zu inspizieren und anzupassen. Dabei sollte das Sprint Review nicht als einfache Präsentation verstanden werden, sondern als ein Lernevent, in dem das Feedback der Stakeholder maximiert wird. Damit der Kundenwert noch besser verstanden wird, und klar ist, was die einzelnen Stakeholder wünschen.
Meeting oder Scrum Event? So läuft es ab!
Wir sprechen oft über das Sprint Review Meeting, genau genommen ist es ein Scrum Event. Der Unterschied ist oft mehr in der Theorie vergraben, als das er eine wirkliche Relevanz für die Praxis hat. Hier wird das Review immer als ein Termin / Meeting durchgeführt. Wir kennen in Scrum auch Events, die keine Meetings sind und haben damit einen übergreifenden Begriff in Scrum, der eben genau diese Events gruppiert.
Das Sprint Review folgt einem recht einfachen Ablauf. Es ist wichtig, dass gerade bei inhaltlichen Diskussionspunkten nicht abgeschweift wird. Der Scrum Master moderiert hier, wenn nötig. Die Einladung zum Sprint Review kann gerne direkt vom Product Owner kommen, ist aber keine Pflicht.
Zur Dauer kannst du festhalten, dass der Termin einen halben Tag bei einem einmonatigem Sprint dauert. Also ist das nicht länger als eine Stunde pro Woche Sprint, die ihr meistens durchführen werdet
Input, Inhalt, Output
- Die erledigte Arbeit, die während des Sprints entstanden ist.
- Produkterfahrungen, die gemacht worden sind
- Der Product Owner erklärt welche Einträge im Sprint abgenommen wurden und welche nicht.
- Die Entwickler beschreiben kurz, vor welchen Herausforderung sie gestanden haben und wie diese gelöst wurden.
- Die Entwickler stellt die fertigen PBIs vor und beantwortet Fragen dazu.
- Der Product Owner gibt Information zum Product Backlog, Fortschritt des Produktes und Daten zu Releases.
- Das gesamte Scrum-Team bespricht mit den Stakeholdern, was als nächstes sinnvoll in der Umsetzung ist, damit das Sprint Review wertvollen Input für den nächsten Sprint liefert.
- Betrachten von Marktgegebenheiten und wie damit umgegangen werden kann, um das Wertvollste weiterhin zu erstellen.
- Durchgesehenes Product Backlog
- Die nächsten wahrscheinlichen PBIs, die umgesetzt werden.
- Ausblick auf das nächste Sprint Review
Wie läuft das Sprint Review Meeting ab? Die Agenda!
Lernen demonstriert oder Demo?
Der Zweck eines Sprint Review Meetings in Scrum ist es, dass das Team vorstellt, was es in diesem Sprint geleistet hat. Es ist damit eines der Scrum Events, welches das agile Prinzip der Transparenz sehr stark unterstützt. Ziel des Sprint Reviews ist es, ein funktionierendes Produktinkrement den Stakeholdern, Endnutzern und anderen Interessenten erlebbar vorzustellen. Das Sprint Review ist allerdings mehr, es ist ein Lernevent und sollte nicht als "einfache Demo" verkommen. Nichtsdestotrotz ist es so, dass natürlich immer etwas demonstriert wird und es ist wichtig, dass die Entwickler hier auch tatsächlich etwas vorführen und mit den Stakeholdern in die Interaktion gehen, um auch wichtiges Feedback zu erhalten.
Typische Dysfunktionen des Sprint Reviews
Natürlich, hier sind einige typische Dysfunktionen für das Sprint Review in Scrum. Konzepte und Tipps erfahrener agile Coaches können dich in dem Abbau der Dysfunktionen deutlich unterstützen. Damit ist gemeint, dass etwas nicht so funktioniert, wie es gedacht ist. Und dazu habe ich dir einige prominente Beispiele aufgelistet.
Fehlende Durchführung
Das Sprint Review findet nicht oder nur unregelmäßig statt. So bekommt das Scrum Team von keinem User Feedback.
Keine / wenige / falsche Stakeholder anwesend
Für die Produktentwicklung ist es wichtig, das betroffene Personen im Review teilnehmen sollten. Nur so können Features besprochen werden und Feedback von den richtigen Menschen eingeholt werden. Scrum Master und Product Owner können sich bei fehlender Teilnahme darum kümmern.
Falsche / fehlende Vorbereitung
Das Entwicklungsteam (Entwickler) sollte sich bei diesem Termin, der informell ist, nicht übermäßig vorbereiten. Alles was gezeigt wird, sollte sich immer am Inkrement orientieren, das Sprint Ziel im Auge haben und sowieso gemacht worden sein und damit im Team auch bekannt sein.
Fehlendes Produktinkrement
Wird keine Arbeit fertig gestellt bzw. kann keine gezeigt werden, ist das für ein Review nicht gut. Hier kann der Scrum Master auf Ursachensuche gehen und gerade den ein oder anderen Blick auf das Sprint Planning werfen, ob dort alles richtig abläuft.
Verteidigungshaltung
Je nachdem welche Personen am Sprint Review teilnehmen, kann es schwer sein Feedback zu geben, es richtig aufzunehmen und auch damit umzugehen. Es kann (bei erfahrenen Agile Teams weniger) vorkommen, dass Menschen dann in eine Verteidigungshaltung rutschen, die den konstruktiven Charakter des Termins zerstören. Wurde das Review Meeting durchgeführt und entstand so eine Verteidugungshaltung kann in der Sprint Retrospective genauer das Problem beleuchtet werden.
Alle nicht geschafften Items immer in den nächsten Sprint
Im Scrum Review kann es vorkommen, dass ihr feststellt, es ist nicht alles abgeschlossen. Egal ob offene Fragen existieren, die Timebox nicht eingehalten werden konnte oder euch niemand das Feedback geben konnte, was ihr für eure DoD vielleicht definiert habt. Nicht fertig ist nicht fertig und deshalb kommt die Arbeit zurück ins Product Backlog.
Dinge zeigen, die nicht fertig sind
Die Definition of Done gibt an, welche Arbeit erledigt sein muss, damit Arbeit als fertig gilt. Am Ende eines Sprints wird spätestens überprüft, ob Product Backlog Items erfüllt sind oder nicht. Das kann - und teilweise sollte - man das auch bereits vor dem Ablauf des Sprints machen. Gerade größere Unternehmen oder Konzerne machen das gerne in einem Batch. Das ist für das Scrum Team natürlich nicht die beste Option.
Product Owner, Scrum Master und Agile Coach
Tipps erfahrener Agile Coaches können immer wertvoll sein und bringen oft eine neue Perspektive auf den Termin. Ebenso merkst du die Erfahrung von Product Owner oft daran, dass es klare Regeln und Abläufe gibt, die aber nicht dogmatisch und einengend sind. Als Scrum Master oder Agile Coach kannst du verschiedene Haltungen einnehmen, um jedes Event zu verbessern. Dabei kommt es immer auf den Reifegrad deines Teams an. Es kann durchaus ausreichen, ist die Reflexion zu gehen, wenn das Team schon ein gutes Verständnis über die Arbeitsweise erlangt hat. Es kann aber auch sein, dass du in die Teaching-Haltung gehen musst, wenn noch etwas fehlt.
Sprint-Review vs. Retrospektive und das Product Backlog mit Backlog Items
Während wir im ersten Event auf das Produkt schauen, liegt der Fokus im zweiten Event mehr auf dem Prozess und der Zusammenarbeit. In einem z.B. zweiwöchigen Sprint haben wir immer beide Events und werfen so nicht nur den Blick auf das Product Backlog und die Product Backlog Items (Sprintergebnisse), die einen starken Bezug für das nächste Sprint Planning haben, sondern gemeinsam mit dem Team auch einen Blick auf die Anpassung der Zusammenarbeit. Wir analysieren die Effektivität der Kommunikation, die Aufgabenverteilung und die Arbeitsmethoden, um Verbesserungspotenziale zu identifizieren. Durch regelmäßige Retrospektiven reflektieren wir gemeinsam über unsere Arbeitsweise und treffen gemeinsam Entscheidungen zur Anpassung und Verbesserung.
Die enge Verknüpfung zwischen Produkt und Prozess ermöglicht es uns, kontinuierliche Verbesserungen vorzunehmen und eine agile Arbeitsweise zu etablieren. Dieser integrative Ansatz trägt dazu bei, dass wir als Team effizienter arbeiten und unsere Ziele schneller erreichen.Indem wir sowohl das Produkt als auch den Prozess kontinuierlich optimieren, sind wir in der Lage, auf Veränderungen und Herausforderungen schnell zu reagieren und unseren Kunden einen Mehrwert zu bieten. Unsere Flexibilität und Anpassungsfähigkeit sind entscheidende Erfolgsfaktoren für unseren gemeinsamen Erfolg.
Weitere Scrum Events (z.B. Retrospective)
Bei der Einführung von Scrum stehen natürlich weitere Events auf dem Plan. Agile Organisationen arbeiten mit den richtigen und effektiven Events, nicht nur bei Scrum. Das Review findet immer am Ende des Sprints statt. Dass der Scrum Guide noch weitere Events kennt, sollte klar sein. Neben dem Sprint kennt Scrum noch die Sprint Planung, Daily Scrum und die Sprint Retrospektive.
Tipps und Tricks beim Sprint Review
Welche Tipps und Tricks solltest du Auge behalten? Nun zuerst einmal ist es wichtig, Scrum so zu implementieren und zu leben, wie es im Scrum Guide steht. In den meistens Fällen ist es so, dass durch die korrekte Anwendung auch weniger Tipps benötigt werden.
- Um Feedback zu erhalten muss der Fokus des Meetings immer auf erlebbare Elemente im Product Backlog liegen.
- Eine ordentliche und klare Sprint Review Agenda hilft, klares Erwartungsmanagement zu betreiben.
- Jeder muss den Sinn des Sprint Reviews verstehen.
- Es geht immer um die Erlebnisse des aktuellen Sprint. Der Scrum Guide definiert das auch und es hilft den Fokus zu halten.
- Bei Änderungen wir das Product Backlog angepasst.
- Schaffe Klarheit mit einer Agenda für Stakeholder
Und nun?
Wie sind deine Erfahrungen? Welche Tipps hast du? Lass es mich gerne in den Kommentaren wissen!
