Cluster-Planning in Cycles
Each Cluster-Cycle begins with a Cluster Planning event. In this, the Cluster Product Owner presents the current status of the Cluster Backlog to the Team System Engineer Group (TSEG). New entries or changes that have not been introduced to the TSEG since the last Cluster Backlog Refinement are estimated and supplemented by Acceptance Criteria by the TSEG and prioritized by the Cluster Product Owner within the Cluster Backlog.
The TSEG determines the capacity of the Cluster for the next Cycle by looking at the previous “working speed” (Cluster Velocity) and by looking at the capacity of the Teams in the next Cycle.
The TSEG pulls the number of Cluster Backlog Items (CBI), which corresponds to the TSEG’s assessment of the Capacity in the next Cycle, into the Cycle Backlog of the Cluster. The Team Product Owners then use the TSEG to refine the CBIs in Team Backlog Items that are required to complete the CBIs.
Then the TSEG starts the Cluster Cycle by pulling the first items from “open” to “in progress”.
The Cluster Planning can also be conducted as a Big Room Planning event (aka PI Planning) where all Teams of the Cluster are participating a one- or two-day-workshop.
Continuous Cluster Planning
As an alternative to the planning rhythm in Cycles, the work for the Cluster can also be planned continuously. The Cluster Backlog Refinements are used for this, whereby the work on a Cluster Backlog Item can be started immediately after its analysis and estimation.
Transparent Custer Planning with Velocity
Regardless of whether cluster planning is performed in cycles or continuously, it is important to have a suitable representation of the planned activities and to establish the greatest possible transparency. One possible representation is shown here, where each card represents a cluster backlog item of type Samples & Integrations.
.
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Cluster Product Owner | Team Product Owner Group | Cluster Backlog |