Sprint Review Meeting

Kurzbeschreibung und Zielsetzung

Das Sprint Review ist ein zentrales Ereignis im Scrum-Prozess. Ziel des Meetings ist, dem Product Owner und den Stakeholdern am Ende eines Sprints den aktuellen Entwicklungsstand vorzustellen. Das Entwicklungsteam präsentiert die im Sprint entstandenen Ergebnisse (Inkremente), demonstriert neue Funktionalitäten und diskutiert offene Punkte sowie mögliche Verbesserungen. Das Review sorgt für Transparenz, gemeinsames Verständnis und fördert ein kontinuierliches Feedback – so werden Entwicklung und Zielerreichung regelmäßig überprüft und gesteuert.

Erwartungshaltung an Entwickler:innen

  • Entwickler:innen präsentieren die von ihnen bearbeiteten Stories und Bugfixes selbständig und verständlich im Review.

  • Jeder und jede geht auf die eigenen Stories sowie auf Bugs ein: Sie demonstrieren das Ergebnis, erklären Lösungsweg und Herausforderungen.

  • Auch bei nicht vollständig erledigten oder verschobenen Aufgaben übernimmt die verantwortliche Person (bzw. das Paar) aktiv die Kommunikation:

    • Der Grund für den ausstehenden Abschluss wird sachlich und ehrlich erläutert (z.B. technische Komplexität, unerwartete Blocker, fehlende Informationen).

    • Es wird aufgezeigt, was bereits unternommen wurde und welche Schritte als nächstes geplant sind.

    • Falls erforderlich, werden Unterstützungsbedarfe oder Risiken offen angesprochen.

  • Fragen von Product Owner und Stakeholdern werden offen beantwortet, Feedback wird aktiv aufgenommen.

  • Ziel ist es, Verantwortung für den eigenen Arbeitsbereich zu übernehmen, Zuverlässigkeit und Transparenz gegenüber dem Team und Stakeholdern herzustellen und zur kontinuierlichen Verbesserung beizutragen.

Präsentation von Bug-Stories im Sprint Review

Folgende Leitfragen können Entwickler:innen bei der Vorstellung von Bugfixes im Sprint Review helfen:

  • Was war das ursprüngliche Problem (Bug)?

    • Wie hat sich der Fehler für den Nutzer/die Nutzerin gezeigt?

    • Welche Auswirkungen hatte der Bug (z.B. Funktionsausfall, Fehlermeldung, Datenverlust, …​)?

  • Wie wurde der Bug gefunden?

    • War es ein Nutzer-Feedback, ein Testergebnis oder ein automatischer Test?

  • Wie ließ sich der Fehler reproduzieren?

    • Gab es eine bestimmte Schrittfolge, mit der der Fehler sicher erkennbar war?

    • Gibt es vielleicht Screenshots, Logfiles, Fehlermeldungen oder einen kurzen Screencast als Demo des Problems?

  • Was wurde zur Behebung des Fehlers konkret geändert?

    • Die Lösung kurz erklären (z.B. "Wir haben die Nullprüfung an Stelle X ergänzt, weil …​").

    • Wurde auch angrenzende Funktionalität geprüft/angepasst?

  • Wie wurde sichergestellt, dass der Fehler nun behoben ist?

    • Gibt es neue/angepasste Tests?

    • Wurde die Fehlerreproduktion erneut versucht – mit erfolgreichem Ergebnis?

  • Gab es besondere Herausforderungen oder Learnings?

    • Ist ein Folgeproblem aufgefallen?

    • Welche Lehren ziehen wir daraus für die Zukunft (z.B. Monitoring, Testabdeckung, Coding-Standards)?

  • Optional: Gibt es offene Folgeaufgaben oder Risiken im Zusammenhang mit dem Bugfix?

Im Ticket #5678 wurde gemeldet, dass der Export als PDF manchmal eine leere Datei erzeugt hat. Der Fehler trat auf, wenn Nutzer keinen Zeitraum auswählten und dann direkt auf 'Export' klickten. Ich konnte das Problem nachstellen, indem ich…​ [Schritte aufzählen]. Es gab eine NullPointerException im Serverlog. Die Lösung: Ich habe im Controller einen zusätzlichen Check für leere Zeiträume eingebaut. Zusätzlich habe ich einen neuen Testfall für diesen Edge Case ergänzt. Nach der Änderung ist der Export in allen Fällen erfolgreich. Das habe ich geprüft und die Tests laufen auch grün. Herausforderung war, dass der Fehler nur bei bestimmten Usern mit speziellen Rechteprofilen auftrat; das war eine wichtige Erkenntnis. Im Code Review mit Alex haben wir beschlossen, dass wir ähnliche Abfragen künftig mit einer Utility-Methode absichern.
— Beispiel-Präsentation eines Bugfixes

Beispielhafter Ablauf des Sprint Reviews

  1. Begrüßung und Einleitung durch Product Owner oder Scrum Master: Kurzüberblick zu Sprint-Zielen und Ablauf.

  2. Präsentation der Sprint-Ergebnisse durch die jeweiligen Entwickler:innen:

    • Für jede fertiggestellte Story:

      • Kurze Zusammenfassung der Aufgabe (Ziel, Hintergrund)

      • Live-Demonstration oder Präsentation des Inkrements

      • Beschreibung von Herausforderungen, Besonderheiten oder Abweichungen

      • Klärung, ob alle Akzeptanzkriterien erfüllt sind

    • Bei unfertigen Stories erläutert der zuständige Entwickler/das verantwortliche Teammitglied:

      • Grund für die Verzögerung (kurz, sachlich)

      • Was wurde zur Lösung bereits getan?

      • Was sind die nächsten konkreten Schritte?

      • Wird zusätzliche Unterstützung oder Information benötigt?

      • Einschätzung, wann der Abschluss realistisch ist

  3. Fragen und Feedback

    • Product Owner und Stakeholder bringen Rückfragen und Feedback ein

    • Entwickler:innen beantworten Fragen und nehmen Anregungen auf

  4. Bewertung des Sprint-Fortschritts

    • Was wurde geschafft, was nicht? Gründe erläutern, ggf. Nachholbedarf identifizieren

    • Gemeinsame Reflexion zu Prozess und Ergebnissen

  5. Abschluss

    • Festhalten von spezifischem Feedback, Anmerkungen oder Risiken für den nächsten Sprint

    • Verabschiedung und ggf. Ausblick auf nächste Schritte