de_DE

Regeln für Scrum-Zeremonien – Sprint Review Meeting

Das Sprint-Review-Meeting ist auf 4 Stunden begrenzt.

  • Das Team sollte nicht mehr als 1 Stunde damit verbringen, sich auf die Sprint-Überprüfung vorzubereiten.
  • Der Zweck des Sprint-Reviews besteht darin, dass das Team dem Product Owner und den Stakeholdern die fertige Funktionalität präsentiert. Obwohl die Bedeutung von „erledigt“ von Organisation zu Organisation variieren kann, bedeutet dies normalerweise, dass die Funktionalität vollständig entwickelt wurde und möglicherweise ausgeliefert oder implementiert werden könnte. Wenn „erledigt“ eine andere
    Bedeutung hat, stellen Sie sicher, dass der Product Owner und die Stakeholder es verstehen.
  • Funktionalität, die nicht „fertig“ ist, kann nicht präsentiert werden.
  • Artefakte, die keine Funktionalität sind, können nur präsentiert werden, wenn sie zur Unterstützung des Verständnisses der demonstrierten Funktionalität verwendet werden.
    Artefakte können nicht als Arbeitsergebnisse gezeigt werden, und ihre Verwendung muss minimiert werden, um zu vermeiden, dass die Beteiligten verwirrt werden oder dass sie verstehen müssen, wie die Systementwicklung funktioniert.
  • Die Funktionalität sollte auf den Arbeitsstationen der Teammitglieder präsentiert und von dem Server ausgeführt werden, der der Produktion am nächsten ist – normalerweise ein Server in einer Qualitätssicherungsumgebung (QA).
  • Das Sprint-Review beginnt damit, dass ein Teammitglied das Sprint-Ziel, das festgelegte Product Backlog und das abgeschlossene Product Backlog vorstellt. Verschiedene Teammitglieder können dann diskutieren, was im Sprint gut und was nicht gut gelaufen ist.
  • Der Großteil des Sprint-Reviews wird damit verbracht, dass Teammitglieder Funktionalität präsentieren, Fragen von Stakeholdern bezüglich der Präsentation beantworten und gewünschte Änderungen notieren.
  • Am Ende der Präsentationen werden die Stakeholder einzeln nach ihren Eindrücken, gewünschten Änderungen und der Priorität dieser Änderungen befragt.
  • Der Product Owner bespricht mit den Stakeholdern und dem Team eine mögliche Neuordnung des Product Backlogs basierend auf dem Feedback.
  • Stakeholdern steht es frei, zwischen den Präsentationen Kommentare, Beobachtungen oder Kritik bezüglich der Erhöhung der potenziell lieferbaren Produktfunktionalität zu äußern.
  • Stakeholder können Funktionen identifizieren, die nicht oder nicht wie erwartet geliefert wurden, und verlangen, dass solche Funktionen zur Priorisierung in das Product Backlog aufgenommen werden.
  • Stakeholder können jede neue Funktionalität identifizieren, die ihnen einfällt, wenn sie sich die Präsentation ansehen, und anfordern, dass die Funktionalität zum Product Backlog zur Priorisierung hinzugefügt wird.

Artikel zu Scrum-Events

Ein Kommentar

Kommentar hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht.