Am Ende jedes Cluster-Cycles wird ein Cluster-Review abgehalten, in dem die Team-System-Engineer-Gruppe (TSEG) mit dem Cluster-Product-Owner (CPO), den Stakeholdern die Ergebnisse vorstellen. Dabei bekommen sie Feedback von den Stakeholdern zu den Ergebnissen, damit der CPO bei Bedarf das Cluster-Backlog anzupasst. Zusammen mit eventuellen Änderungen am Cluster-Backlog, die während des Cycles eingeflossen sind (z.B. in den Cluster-Backlog-Refinements), bieten diese die Basis für die gemeinsame Arbeit an möglichen neuen, den Wert der „Cluster-Produkte“ steigernden Einträgen. Beim Cluster-Review handelt es sich um ein informelles Meeting, keinen Statusreport im klassischen Sinn. Die Vorführung der Ergebnisse ist als Anregung für Feedback und die Basis für die Zusammenarbeit gedacht. Am Ende des Cluster-Reviews kann der Cluster-Product-Owner ein Update zu Kosten und geplanten Terminen bzw. Meilensteinen geben.
Für einen zwölfwöchigen Cluster-Cycle wird für dieses Meeting eine Obergrenze von vier Stunden als Zeitrahmen angesetzt. Für kürzere Cycles wird ein entsprechender kürzerer Zeitrahmen veranschlagt. Der Cluster-Scrum-Master (CSM) stellt sicher, dass das Event stattfindet und die Teilnehmer seinen Zweck verstehen. Der CSM bringt allen Beteiligten bei, das Event innerhalb des vorgegebenen Zeitrahmens durchzuführen.
Das Cluster-Review beinhaltet die folgenden Elemente:
- Die Teilnehmer, bestehend aus der Team-System-Engineer-Gruppe (TSEG) und wichtigen Stakeholdern, die vom Cluster-Product-Owner eingeladen werden. Dies sind häufig auch die POs der Teams, d.h. die Team-Product-Owner-Gruppe.
- Der Cluster-Product-Owner erklärt, welche Cluster-Backlog-Einträge (CBI) erledigt sind.
- Die TSEG stellt dar, was während des Cluster-Cycles gut lief, welche Probleme aufgetaucht sind, und wie sie diese Probleme gelöst hat. Die TSEG erfragt dabei ggf. Unterstützung durch die Stakeholder.
- Die TSEG führt die erledigten Arbeitsergebnisse vor, und beantwortet Fragen dazu. Arbeitsergebnisse können sein:
- Der Cluster-Product-Owner stellt den aktuellen Stand des Cluster-Backlogs vor. Er gibt bei Bedarf eine aktualisierte Prognose von wahrscheinlichen Ziel- und Lieferterminen auf der Basis des Entwicklungsfortschritts, z.B. durch Nutzung eines Burn-up-Charts auf Basis der Arbeitsgeschwindigkeit des Clusters (Velocity)
- Alle Teilnehmer erarbeiten gemeinsam, was als nächstes zu tun ist, so dass der Cluster-Product-Owner wertvollen Input für die kommende Cluster-Planung bekommt.
- Anschließend werden Zeitplan, Budget, sowie die potentiellen Eigenschaften und Markterwartungen für die nächste Version der Applikation (Release) überprüft.
Das Ergebnis des Cluster-Reviews ist ein überarbeitetes Cluster-Backlog, das dem gemeinsamen Wissenstand der Teilnehmer entspricht und durch das die TSEG im nächsten Cluster-Cycle, an den Cluster-Backlog-Einträgen mit dem höchsten Wert arbeiten kann. Das Cluster-Backlog kann auch umfassend umgearbeitet werden, um neue Chancen zu nutzen.
Cluster-Review-Alternativen
Häufig werden die Team-Reviews direkt vor dem Cluster-Review durchgeführt, wobei die Team-Review meist eher technischer sind und auf Cluster-Ebene eher die gesamtheitlichen Aspekte, wie Kosten, Meilensteine, gezeigt werden. Dadurch lässt sich das Cluster-Review deutlich kürzer gestalten. Inklusive der Team-Reviews muss aber ein halber bis ganzer Tag eingerechnet werden.
Sind mehr als vier Teams im Cluster, bietet sich auch die Gestaltung der Team-Reviews innerhalb des Cluster-Reviews mittels „Messeständen“ an. Dabei zeigen die Teams ihre Ergebnisse, wie auf einer Messe und die Stakeholder sind dabei die Besucher.
.
Passende und weiterführende Artikel:
Events | Rollen | Gruppen | Artefakte |
Team-Review
. . |
Cluster-Product-Owner | Team-Product-Owner-Gruppe | Cluster-Backlog |