Cluster-Planning in Cycles
Jeder Cluster-Cycle beginnt mit einem Cluster-Planning-Event. In diesem präsentiert der Cluster-Product-Owner den aktuellen Stand des Cluster-Backlogs der Team-System-Engineer-Gruppe (TSEG) Neue Einträge oder Änderungen, die der Team-System-Engineer-Gruppe seit dem letzten Cluster-Backlog-Refinement noch nicht bekannt sind, werden geschätzt, ggf. durch Akzeptanzkriterien ergänzt und vom Cluster-Product-Owner innerhalb des Cluster-Backlogs priorisiert.
Die Team-System-Engineer-Gruppe ermittelt die Kapazität des Clusters für den nächste Cycle durch einen Blick auf die bisherige Cluster-Arbeitsgeschwindigkeit (Cluster-Velocity) und durch einen Blick auf die Kapazität der Teams im nächsten Cycle.
Die Team-System-Engineer-Gruppe zieht die Anzahl von Cluster-Backlog-Items (CBI), die der Einschätzung des TSEG über die Kapazität im nächsten Cycle entspricht, in das Cycle-Backlog des Clusters (Pull). Danach verfeinern die Team-Product-Owner mit den TSEG die CBIs in Team-Backlog-Items, die zur Fertigstellung des CBIs nötig sind.
Danach startet die TSEG den Cluster-Cycle durch ziehen der ersten Aufgaben von „open“ nach „in progress“.
Das Cluster-Planning lässt sich auch als Big-Room-Planning-Event* gestalten. Dabei wird in einem ein- oder zweitätigen Workshop mit allen Teams der Plan für den nächsten Cluster-Cycle erarbeitet.
Kontinuierliches Cluster-Planning
Alternativ zum Planungsrhythmus in Cycles, kann die Planung der Arbeiten für den Cluster auch kontinuierlich erfolgen. Hierfür werden die Cluster-Backlog-Refinements genutzt, wobei ein Cluster-Backlog-Item direkt nach der Analyse und Schätzung, in Bearbeitung gehen kann. Durch das kontinuierliche Refinement und Planen kann der Cluster noch viel besser auf kurzfristige Änderungen reagieren. Es besteht allerdings die Gefahr, dass dadurch auch viel Unruhe in den Teams entsteht, besinders, wenn Änderungen ungefiltert weitergegeben werden.
Cluster-Planning mit Transparenz und Velocity
Egal, ob die Cluster-Planung in Cycles oder kontinuierlich durchgeführt wird, ist eine geeignete Darstellung der geplanten Aktivitäten wichtig und eine größtmögliche Transparenz herzustellen. Eine mögliche Darstellung ist hier drgestellt, wobei jede Karte ein Cluster-Backlog-Item vom Typ Samples & Integrations darstellt.
.
*) Das Big-Room-Planning wird im SAFe-Framework als PI-Planning bezeichnet.
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Team-Planning
. . |
Cluster-Product-Owner | Team-Product-Owner-Gruppe | Cluster-Backlog |