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. Ein Team-Planning-Event für die erste Iteration wird dabei direkt anschließend durchgeführt.
Wichtige Anmerkungen:
- Es ist sehr wichtig, dass bei der Cluster-Planung genügend Gestaltungsfreiraum für die Team-Product-Owner und die Teams bleibt. Im Idealfall werden auf der Cluster-Ebene ausschließlich die Arbeiten geplant, die von mehreren Teams übergreifend bearbeitet werden, für die also eine zeitliche und inhaltliche Abstimmung notwendig ist. Eine geeignete Cluster- und Teamstruktur fördert die Unabhängigkeit der Teams und ihrer Planung.
- Dadurch dass Service-Teams und Modul-Teams Zulieferer der Applikationsteams sind, kommt den Applikationsteams eine führende Rolle bei der Planung zu. Der TPO eines Applikationsteams entscheidet, welche Funktionen für das Produkt entwickelt werden sollen; daraus ergeben sich meist die nötigen Zulieferungen der Modul-Teams und Service-Teams.
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 |