Ein Sprint Review bietet dir die Möglichkeit, die Ergebnisse des letzten Sprints mit deinem Team und Stakeholdern zu teilen. Hier kannst du direktes Feedback einholen und gemeinsam reflektieren, um den nächsten Sprint noch erfolgreicher zu gestalten. Es ist der perfekte Moment, um Erfolge zu feiern und Verbesserungen für die Zukunft zu identifizieren.
In diesem Artikel lernst du, was das Sprint Review 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 sogenannte Sprint Review Meeting, obwohl es sich genau genommen um ein Scrum Event handelt. Dieser Unterschied hat allerdings eine untergeordnete Relevanz für die Praxis hat. Denn das Sprint Review immer als ein Termin bzw. Meeting durchgeführt.
Das Sprint Review folgt einem recht einfachen Ablauf. Zum Termin lädt meistens wahlweise der Product Owner oder der Scrum Master ein. Letzterer kann auch moderativ unterstützen, wenn Bedarf besteht.
Der Termin ist meist kürzer als er
Input, Inhalt, Output
Input
Inhalt
Output
Eine typische Agenda
Eine Agenda läuft in der Regel in einem einfachen Muster ab, dass sich so mehr oder weniger immer wiederholt.
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.