Warum Sprint Reviews mehr verdienen als ein Gut Check

Im agilen Projektmanagement ist der Sprint Review eines der fünf Kernereignisse von Scrum, aber oft das am meisten missverstandene. Viele Teams behandeln ihn als einfache Demo oder Status-Update, verpassen die Gelegenheit, echte Prozessverbesserungen voranzutreiben. Um einen Sprint Review von einer passiven Präsentation in eine strategische Feedbackschleife zu verwandeln, müssen Teams objektive Metriken und Key Performance Indicators (KPIs) integrieren. Diese Tools liefern datengestützte Einblicke, wie gut Sprintziele erreicht werden, wo Engpässe bestehen und welche Anpassungen die Lieferung beschleunigen.

Dieser Artikel untersucht, wie man die richtigen Metriken für Sprint-Reviews auswählt, implementiert und interpretiert, mit praktischen Anleitungen für Engineering-Leads, Product Owner und Agile-Coaches. Wir werden grundlegende Konzepte, spezifische Metriken und KPIs, Implementierungsstrategien, gemeinsame Fallen und eine reale Fallstudie behandeln, die alles miteinander verbindet.

Kennzahlen und KPIs im agilen Kontext verstehen

Bevor wir uns mit spezifischen Maßnahmen befassen, ist es wichtig, den Unterschied zwischen Metriken und KPIs zu klären und wie sie innerhalb eines agilen Frameworks funktionieren.

Was sind Metriken?

Metriken sind quantitative Messungen, die bestimmte Aspekte eines Prozesses oder Produkts verfolgen. In Sprint-Reviews helfen Metriken Teams, Fragen zu beantworten wie: Wie viel Arbeit haben wir erledigt? Wie schnell haben wir Aufgaben erledigt? Wie stabil ist das Produkt? Metriken sind Rohdatenpunkte, die eine sachliche Grundlage für Diskussionen bieten.

Was sind KPIs?

Key Performance Indicators (KPIs) sind eine Teilmenge von Metriken, die direkt mit strategischen Zielen verknüpft sind. Während alle KPIs Metriken sind, sind nicht alle Metriken KPIs. Ein KPI beantwortet die Frage: Bewegen wir uns auf unsere Geschäfts- und Teamziele zu? Zum Beispiel ist Geschwindigkeit eine Metrik, aber wenn das Ziel darin besteht, die Vorhersagbarkeit zu erhöhen, wird die Geschwindigkeitskonsistenz zu einem KPI. KPIs werden von organisatorischen Prioritäten bis hin zu Sprintzielen auf Teamebene kaskadiert.

Zusammen bilden Metriken und KPIs eine ausgewogene Scorecard für Sprint-Reviews, die subjektive Meinungen durch objektive Beweise ersetzen und es Teams ermöglichen, produktive, schuldfreie Gespräche darüber zu führen, was funktioniert und was sich ändern muss.

Warum die Messung der Wirksamkeit von Sprint Reviews entscheidend ist

Ohne Messung verlassen sich Teams auf Gedächtnis und Intuition, was unzuverlässig sein kann.

  • Zielgerichtete Entscheidungsfindung: Metriken ersetzen Rätselraten durch Fakten und helfen Teams zu entscheiden, ob sie Umfang, Prozess oder Teamzusammensetzung anpassen möchten.
  • Frühe Erkennung von Problemen: Trends in Metriken wie Defektdichte oder Zykluszeit können tiefere Probleme signalisieren (z. B. technische Schulden, schlechte Schätzung oder Kommunikationslücken), bevor sie eskalieren.
  • Stakeholder Alignment: Wenn Produktbesitzer, Entwickler und Unternehmensleiter die gleichen Daten betrachten, verbessert sich die Ausrichtung. Metriken schaffen eine gemeinsame Sprache, um Fortschritte und Erwartungen zu diskutieren.
  • Kontinuierliche Verbesserung: Die Sprint-Retrospektive konzentriert sich auf den Prozess, während sich die Sprint-Review auf die Ergebnisse konzentriert. Metriken machen die Überprüfung umsetzbar und fließen direkt in die nächste Iteration ein.
  • Team Moral und Motivation: Sichtbare Fortschritte (durch Burndown-Charts oder abgeschlossene Story-Punkte) steigern die Moral, während ehrliche Daten über Herausforderungen die Schuld reduzieren und die Zusammenarbeit fördern.

Kurz gesagt, Measurement verwandelt Sprint Reviews von einem Ritual in ein wertschöpfendes Ereignis. Teams, die messen, was zählt, sind besser gerüstet, um qualitativ hochwertige Software in einer vorhersehbaren Kadenz zu liefern.

Key Metrics für den Erfolg von Sprint Review

Es gibt Dutzende von potenziellen Metriken, aber eine Handvoll ist besonders relevant für Sprint-Reviews. Der Schlüssel ist, Metriken zu wählen, die mit der aktuellen Reife und den Zielen Ihres Teams übereinstimmen.

Geschwindigkeit

Die Geschwindigkeit misst den Arbeitsaufwand, den ein Team in einem Sprint erledigt, typischerweise ausgedrückt in Story Points oder Stunden. Es ist die am häufigsten verwendete Sprintmetrik, da sie eine einfache, hochrangige Ansicht des Durchsatzes bietet.

Wie man es in einem Sprint-Review verwendet: Vergleichen Sie die tatsächliche Geschwindigkeit mit dem Sprint-Plan. Wenn das Team konsequent unterbietet, wird die Überprüfung zu einer Diskussion über die Genauigkeit der Schätzung, das Umfangsmanagement oder Prozesshindernisse. Geschwindigkeit ist auch nützlich für die Vorhersage zukünftiger Sprints, aber nur, wenn sie im Laufe der Zeit stabil ist.

Achte auf: Geschwindigkeitsmanipulation. Wenn Teams den Druck verspüren, höhere Zahlen zu zeigen, können sie Story-Punkte aufblasen oder Qualitätseinbußen einsparen. Geschwindigkeit sollte als Trendindikator und nicht als Ziel verwendet werden. Wie Scrum.org warnt, Geschwindigkeit ist kein Maß für Produktivität; es ist ein Maß für Kapazität für Planungszwecke.

Burndown Chart

Das Burndown-Diagramm zeichnet die verbleibenden Arbeiten (in Story-Punkten oder Stunden) im Laufe eines Sprints nach und bietet einen Überblick darüber, ob das Team auf dem richtigen Weg ist, um alle geplanten Arbeiten bis zum Ende des Sprints abzuschließen.

Wie man es in einem Sprint-Review verwendet: Zeigen Sie das Burndown-Diagramm während des Reviews, um zu veranschaulichen, wie das Team Tag für Tag vorangekommen ist. Ein idealer Burndown neigt sich stetig nach unten. Wenn das Chart eine flache Linie (kein Fortschritt) oder einen Spike (Scope hinzugefügt) zeigt, wird das Review zu einer Diskussion über die Ursache. Burndown-Diagramme sind besonders effektiv, um Scope-Creep- und Mid-Sprint-Änderungen zu identifizieren.

Achten Sie auf: Veraltete Daten. Wenn das Burndown-Diagramm nicht täglich aktualisiert wird, verliert es seinen Wert. Teams, die digitale Tools wie Jira oder Trello verwenden, sollten diesen Prozess automatisieren. Außerdem gehen Burndown-Diagramme davon aus, dass alle Arbeiten gleich groß sind, was selten der Fall ist. Verwenden Sie sie zusammen mit anderen Metriken für ein vollständiges Bild.

Zykluszeit

Die Zykluszeit misst die Zeit, die eine Aufgabe benötigt, um von "Work In Progress" zu "Done" zu wechseln. Es ist ein leistungsstarker Indikator für Prozesseffizienz und -fluss.

Wie man es in einem Sprint-Review verwendet: Wenn die Zykluszeit zunimmt, schlägt es Engpässe im Workflow vor (z. B. Code-Review-Warteschlangen, Testverzögerungen). Teams können anhand von Zykluszeitdaten ermitteln, welche Arten von Arbeit am längsten dauern und entscheiden, ob sie in Automatisierung, Schulung oder Prozessänderungen investieren. Eine verwandte Metrik, Vorlaufzeit, misst die Zeit von der Anfrage bis zur Lieferung, was kundenorientierter ist.

Achten Sie auf: Durchschnitte können irreführend sein. Zykluszeit folgt oft einer schiefen Verteilung (einige sehr lange Aufgaben). Verwenden Sie Perzentil-Metriken (z. B. die 85. Perzentil-Zykluszeit), um eine realistische Ansicht zu erhalten. Teams, die Kanban verwenden, profitieren besonders von Zykluszeit-Tracking.

Defektdichte

Die Fehlerdichte zählt die Anzahl der Fehler oder Probleme, die während eines Sprints entdeckt wurden, normiert gegenüber der Größe der gelieferten Arbeit (z. B. Defekte pro 100 Story Points).

Wie man es in einem Sprint-Review verwendet: Ein Anstieg der Fehlerdichte legt nahe, dass Qualitätspraktiken (z. B. Testen, Code-Review, Definition von Done) Aufmerksamkeit erfordern. Der Sprint-Review ist das richtige Forum, um zu diskutieren, ob das Team mehr Zeit für Tests aufwenden, Akzeptanzkriterien verbessern oder automatisierte Prüfungen hinzufügen sollte. Die Verknüpfung der Fehlerdichte mit der Zykluszeit kann auch zeigen, ob Qualitätsprobleme Nacharbeit verursachen, die die Lieferung verlangsamt.

Achte auf: Underreporting. Teams zögern möglicherweise, alle Fehler zu melden, aus Angst, schlecht auszusehen. Pflegen Sie eine Kultur, in der Fehler als Lernmöglichkeiten und nicht als Ausfälle angesehen werden. Außerdem ist die Fehlerdichte am sinnvollsten, wenn sie über Sprints hinweg verglichen wird, nicht isoliert.

Kapazität des Teams

Die Teamkapazität misst die Gesamtmenge an Arbeit, die ein Team in einem Sprint realistisch erledigen kann, unter Berücksichtigung von Urlauben, Zeremonien und anderen Verpflichtungen.

Wie man es in einem Sprint-Review verwendet: Vergleichen Sie die geplante Kapazität mit der tatsächlichen Kapazität zu Beginn jedes Sprints. Wenn das Team konsequent überfordert ist, muss die Kapazitätsplanung verfeinert werden. Der Sprint-Review kann eine Diskussion darüber beinhalten, ob externe Faktoren (z. B. teamübergreifende Abhängigkeiten, ungeplante Support-Arbeiten) die verfügbare Zeit aushöhlen.

Achte auf: Mikromanagement. Kapazitätsmetriken sind nützlich für die Planung, aber sie sollten nicht dazu verwendet werden, Teammitglieder dazu zu zwingen, längere Arbeitszeiten zu arbeiten.

Effektive KPIs für Sprint-Erfolg

Während Metriken Rohdaten liefern, konzentrieren sich KPIs auf Ergebnisse, die für das Unternehmen und das Team von Bedeutung sind.

Kundenzufriedenheit

Dieser KPI erfasst das Feedback der Stakeholder zu den gelieferten Arbeiten. Es kann durch eine einfache Umfrage nach jedem Sprint-Review gemessen werden (z. B. "Auf einer Skala von 1-5, wie gut hat der Sprint den Nutzern einen Mehrwert gebracht?").

Warum es wichtig ist: Die Zufriedenheit des Kunden (oder Stakeholders) ist der ultimative Test für den Erfolg des Sprints. Wenn das Team schnell liefert, aber die Ausgabe nicht den Benutzeranforderungen entspricht, ist Geschwindigkeit bedeutungslos. Produktbesitzer sollten Stakeholder-Feedback in die Sprint-Überprüfung einbringen und das Team sollte darüber diskutieren, wie es in den nächsten Sprint integriert werden kann.

Wie man es verbessert: Investieren Sie in bessere Akzeptanzkriterien, User Story Mapping und häufige Demos. Laden Sie echte Benutzer ein, wenn möglich, Sprint-Reviews zu erstellen. Wie Atlassian vorschlägt, sollten sprint-Reviews kollaborative Arbeitssitzungen sein, keine Präsentationen.

Qualitätsmetriken (First-Time Pass Rate)

Die First-Time-Pass-Rate misst den Prozentsatz der Arbeit, der die Definition of Done erfüllt, ohne dass eine Nacharbeit erforderlich ist, und ist ein direkter Indikator für die Prozessqualität.

Warum es wichtig ist: Niedrige Erstpassraten führen zu verschwendetem Aufwand, langsamerer Lieferung und niedrigerer Teammoral. Die Verfolgung dieses KPI im Laufe der Zeit zeigt, ob Qualitätsinitiativen (z. B. testgesteuerte Entwicklung, Paarprogrammierung) Auswirkungen haben.

Wie man es verbessern kann: Verschärfung der Definition von Done, Investition in automatisierte Tests und Sicherstellung, dass die Akzeptanzkriterien klar sind, bevor die Entwicklung beginnt.

Scope Creep

Scope Creep misst den Prozentsatz der Arbeit, die nach dem Sprint hinzugefügt oder geändert wurde. Es ist ein KPI, der sich direkt auf die Vorhersagbarkeit auswirkt.

Warum es wichtig ist: Agile nimmt Veränderungen an, aber ein uneingeschränkter Scope Creep untergräbt die Fähigkeit des Teams, Verpflichtungen zu erfüllen. Das Tracking Scope Creep während des Sprint-Reviews hilft dem Team und dem Produktbesitzer zu entscheiden, ob sie Änderungen widerstehen oder sie bewusst akzeptieren wollen.

Wie man es verbessert: Legen Sie einen klaren Prozess für Änderungsanforderungen im mittleren Sprint fest. Jede Hinzufügung zum Sprint-Backlog sollte durch die Entfernung eines gleichen Arbeitsaufwands ausgeglichen werden. Die Sprint-Überprüfung ist ein ausgezeichneter Zeitpunkt, um zu diskutieren, ob der aktuelle Prozess für die Bearbeitung von Änderungen funktioniert.

Teamzufriedenheit (Happiness Metric)

Die Teamzufriedenheit misst, wie Teammitglieder den Sprintprozess, die Zusammenarbeit und die Ergebnisse empfinden. Sie wird oft über eine einfache anonyme Umfrage am Ende jedes Sprints gesammelt.

Warum es wichtig ist: Unzufriedene Teams sind weniger produktiv, gehen eher aus und sind weniger kreativ. Die Teamzufriedenheit ist ein führender Indikator für die langfristige Leistung. Wenn die Zufriedenheit sinkt, sollten die Sprint-Überprüfung und die Retrospektive die Ursache angehen.

Wie kann man es verbessern: Handeln Sie auf die Daten. Wenn das Team aufgrund von Überlastung eine geringe Zufriedenheit meldet, reduzieren Sie die Besprechungszeiten. Wenn es aufgrund unklarer Anforderungen ist, investieren Sie in eine bessere Nachbesserung des Rückstands. Der Schlüssel ist, dem Team zu zeigen, dass sein Feedback die Aktion antreibt.

Lieferfrequenz

Die Lieferhäufigkeit misst, wie oft das Team brauchbare Produktinkremente an die Benutzer freigibt. Bei Teams, die kontinuierlich eingesetzt werden, kann dieser KPI in Tagen oder Stunden gemessen werden. Bei Teams mit längeren Zyklen kann er pro Sprint liegen.

Warum es wichtig ist: Häufige Lieferung ermöglicht schnellere Feedbackschleifen und reduziert das Risiko großer, fehlgeschlagener Releases. Im Sprint-Review kann das Team diskutieren, was häufigere Releases verhindert (z. B. manuelle Bereitstellungsschritte, Integrationsherausforderungen) und Verbesserungen planen.

Wie man es verbessert: Investieren Sie in CI/CD-Automatisierung, Feature-Flags und modulare Architektur. Der Sprint-Review kann neben Produktfunktionen eine Demonstration der Verbesserungen der Bereitstellungspipeline beinhalten.

So implementieren Sie Metriken und KPIs in Ihren Sprint Reviews

Die Auswahl der richtigen Metriken und KPIs ist nur die halbe Miete. Die Art und Weise, wie Sie sie in den Sprint-Review-Prozess integrieren, bestimmt, ob sie Verbesserungen vorantreiben oder bürokratisch werden.

Schritt 1: Definieren Sie, wie der Erfolg für Ihren Sprint aussieht

Bevor der Sprint beginnt, sollten sich Produktbesitzer und Team auf ein Sprintziel einigen. Dieses Ziel sollte spezifisch, messbar und an den Geschäftswert gebunden sein. Zum Beispiel: "Füllen Sie den Checkout-Flow mit 100% Testabdeckung und null kritischen Defekten ab." Das Sprintziel bestimmt dann, welche Metriken und KPIs am relevantesten sind. Wenn das Ziel Geschwindigkeit ist, konzentrieren Sie sich auf Zykluszeit und Geschwindigkeit. Wenn das Ziel Qualität ist, konzentrieren Sie sich auf Fehlerdichte und Erstpassrate.

Schritt 2: Verwenden Sie ein Sprint Review Dashboard

Erstellen Sie ein gemeinsames Dashboard (mit Tools wie Tableau, Power BI oder integrierten Agile Tool Dashboards), das die vereinbarten Metriken und KPIs anzeigt. Aktualisieren Sie es in Echtzeit oder mindestens täglich. Projizieren Sie das Dashboard und gehen Sie durch jede Metrik. Dadurch bleibt die Diskussion datengesteuert und fokussiert. Vermeiden Sie es, mehr als 5-7 Metriken anzuzeigen, um eine Informationsüberlastung zu verhindern.

Schritt 3: Pflege einer schuldfreien Datenkultur

Metriken sind nur nützlich, wenn das Team ihnen vertraut. Betonen Sie, dass der Zweck der Messung Lernen ist, nicht Bewertung. Wenn eine Metrik einen negativen Trend zeigt, stellen Sie Fragen wie: "Was ist passiert?" "Was können wir lernen?" "Was sollten wir als nächstes versuchen?" und nicht "Wer hat das verursacht?" Führungskräfte müssen dieses Verhalten konsistent modellieren.

Schritt 4: Iterieren Sie Ihre Metriken

Wenn das Team reift und sich die Projektprioritäten ändern, sollten sich die Metriken und KPIs weiterentwickeln. Überprüfen Sie die Maßnahmen alle 3-6 Monate während einer retrospektiven oder vierteljährlichen Planungssitzung. Lassen Sie Metriken fallen, die nicht mehr die Entscheidungsfindung beeinflussen, und fügen Sie Metriken hinzu, die aktuelle Herausforderungen ansprechen. Zum Beispiel könnte ein Team, das die Geschwindigkeit stabilisiert hat, den Fokus auf Qualität oder Kundenzufriedenheit verlagern.

Schritt 5: Verbinden von Metriken mit Aktionselementen

Die Sprint-Überprüfung sollte mit spezifischen, messbaren Aktionspunkten enden, die aus den Daten abgeleitet werden. Zum Beispiel "Zykluszeit auf 'mittleren' Geschichten um 20% erhöht in diesem Sprint. Aktionspunkt: Untersuchen Sie, ob Code-Review-Engpässe die Ursache sind und experimentieren Sie mit rotierenden Rezensenten nächsten Sprint." Weisen Sie Besitzer zu und überprüfen Sie den Fortschritt in der nächsten Überprüfung.

Häufige Fallstricke bei der Verwendung von Metriken zu vermeiden

Selbst gut gemeinte Messbemühungen können nach hinten losgehen. Hier sind die häufigsten Fallen und wie man sie vermeidet:

  • Gaming the system: Wenn Metriken zu Zielen werden, finden die Leute Wege, sie zu manipulieren. Zum Beispiel könnten Teams ihre Geschwindigkeitsschätzung künstlich senken, um Fortschritte besser aussehen zu lassen.
  • Bestätigungsvorurteil: Teams können Metriken auswählen, die ihre bevorzugte Erzählung unterstützen. Vermeiden Sie dies, indem Sie vor dem Start des Sprints einen ausgewogenen Satz von Metriken vordefinieren und sie alle, insbesondere die unbequemen, überprüfen.
  • Vanity-Metriken: Einige Metriken sehen beeindruckend aus, bieten aber wenig umsetzbare Einblicke (z. B. gesamte Codezeilen geschrieben).
  • Mikromanagement: Metriken sollten informieren, nicht diktieren. Wenn Teammitglieder das Gefühl haben, dass jede Bewegung verfolgt wird, erodiert das Vertrauen. Verwenden Sie Metriken auf Teamebene und nicht auf individueller Ebene und vermeiden Sie es, sie für Leistungsüberprüfungen zu verwenden.
  • Datenüberlastung: Die Präsentation zu vieler Metriken lähmt die Entscheidungsfindung. Halten Sie sich an die wenigen wichtigen, die sich direkt auf das Sprintziel und die allgemeine Teamgesundheit beziehen.
  • Qualitativer Kontext ignorieren: Metriken sagen Ihnen, was passiert ist, aber nicht immer warum. Kombinieren Sie quantitative Daten immer mit qualitativen Erkenntnissen des Teams und der Stakeholder während des Sprint-Reviews.

Case Study: Wie ein Fintech-Team seine Sprint-Bewertungen transformiert hat

Betrachten wir ein hypothetisches, aber realistisches Szenario: ein 7-köpfiges Fintech-Entwicklungsteam, das mit unvorhersehbarer Lieferung zu kämpfen hat. Bei jedem Sprint-Review blieben die Stakeholder frustriert, weil die versprochenen Funktionen unvollständig waren. Das Team gab externen Abhängigkeiten die Schuld, während Produktbesitzer schlechte Planung verantwortlich machten. Die Atmosphäre war angespannt und das Umsatzrisiko war hoch.

Sie beschlossen, eine metrische Sprint-Review einzuführen. Zunächst veranstalteten sie einen Workshop, um zu definieren, wie der Erfolg ihres Produkts aussieht: "Zuverlässige Lieferung von hochwertigen Funktionen mit Null-P0-Fehlern in der Produktion." Sie wählten drei Hauptmetriken aus: Geschwindigkeit (für die Planung), Zykluszeit (für die Effizienz) und Defektdichte (für die Qualität). Sie fügten außerdem zwei KPIs hinzu: Kundenzufriedenheit (durch Benutzertests) und Teamzufriedenheit (durch anonyme wöchentliche Umfragen).

Sie erstellten ein Dashboard und verpflichteten sich, es jeden Sprint zu überprüfen. Die ersten paar Reviews waren unbequem. Die Zykluszeit war doppelt so hoch wie ihre Schätzung und die Fehlerdichte war höher als erwartet. Aber weil sich die Kultur zu schuldfreiem Lernen verlagert hatte, begann das Team, schwierige Fragen zu stellen. Sie entdeckten, dass Code-Reviews ein großer Engpass waren, weil der leitende Entwickler des Teams zu viele Reviews allein annahm. Sie drehten die Reviewer und sahen, dass die Zykluszeit in drei Sprints um 30% fiel.

Die Kundenzufriedenheit war auch gering, weil Funktionen ohne ordnungsgemäße Benutzertests geliefert wurden. Sie begannen, einen einfachen Usability-Test in die Definition of Done aufzunehmen. Nach zwei Sprints stiegen die Zufriedenheitswerte von 2,8 auf 4,1 von 5. Die Teamzufriedenheit verbesserte sich ebenfalls, weil das Team sich besser in der Kontrolle über seinen Prozess fühlte.

Innerhalb von sechs Monaten entwickelten sich die Sprint Reviews von Schuldzuweisungen zu produktiven Strategiemeetings. Die Stakeholder begannen eifrig teilzunehmen, weil sie wussten, dass sie echte Fortschritte und datengesteuerte Entscheidungen sehen würden. Die Vorhersagbarkeit des Teams verbesserte sich und der Umsatz sank auf Null.

Diese Fallstudie verdeutlicht eine universelle Wahrheit: Metriken lösen Probleme nicht von selbst, aber wenn sie mit einer gesunden Teamkultur und einem klaren Rahmen verwendet werden, bieten sie die Klarheit, die erforderlich ist, um nachhaltige Verbesserungen voranzutreiben.

Fazit: Aufbau einer Kultur der kontinuierlichen Verbesserung

Sprint-Reviews sind eines der am wenigsten genutzten Ereignisse in Agile. Durch die Integration der richtigen Metriken und KPIs können Teams diese Reviews in Motoren der kontinuierlichen Verbesserung umwandeln. Der Schlüssel ist, klein anzufangen, ein paar Metriken auszuwählen, die mit Ihrem Sprint-Ziel übereinstimmen, und zu wiederholen. Konzentrieren Sie sich auf Trends im Laufe der Zeit, kombinieren Sie quantitative Daten mit qualitativem Kontext und fördern Sie eine schuldfreie Kultur, in der Daten zum Lernen und nicht zum Urteilen verwendet werden.

Wenn Sie diese Praktiken umsetzen, werden Sie wahrscheinlich feststellen, dass der Sprint-Review zu einem Höhepunkt des Sprint-Zyklus wird, einem Moment, in dem das Team, der Product Owner und die Stakeholder zusammenkommen, um Siege zu feiern, Herausforderungen zu analysieren und den nächsten Schritt nach vorne mit Zuversicht zu planen.

Für weitere Informationen zu agilen Metriken und Sprint-Reviews finden Sie Ressourcen aus Scrum.org und Martin Fowlers Analyse der Metrikrisiken.