Each Cluster has exactly one Backlog for its area of responsibility and tasks , the Cluster Backlog. In its simplest form, it consists of elements of just one System development that all Teams in the Cluster are working on. In this case, the Cluster Backlog can be referred to as the System Backlog. If the Cluster is responsible for several systems, all backlog elements of the different systems are contained within the Cluster Backlog.
The Team Product Owner Group is responsible for and prioritizes the Cluster Backlog .The Team Product Owner Group consists of all Team Product Owners of the Cluster and the Cluster Product Owners. A large part of the Cluster Backlog is derived by the Cluster Product Owner Group and the Cluster System Engineer Group from the Portfolio Backlog by refinement in the Portfolio Backlog Refinements .
The other part of the Cluster Backlog consists of work and measures that the Cluster carries out to improve the quality of work and results, e.g.
- Quality measures and improvement of the Cluster process (ie the Cluster Improvement Backlog)
- Maintenance of the products, systems and Modules responsible for the cluster
- Maintenance and servicing of tools and tools.
In order to make the working speed of the Clusters more predictable, the proportion of backlog items derived from the Portfolio Backlog should be relatively stable over time.
The Cluster Backlog is prioritized by the Cluster Product Owner.
In the Cluster Backlog Refinement , the Cluster Backlog Items are presented by the Cluster Product Owner and estimated by the Team System Engineer Group (TSEG). Since this consists of members of all Teams in the Cluster, this group is best suited for this.
In the Cluster Planning, the TSEG pulls as many Cluster Backlog Items into the Cycle as the TSEG believes due to the previous working speed of the cluster. This is the Cycle Backlog that represents the plan for the next cycle.
Work in cycles or in continuous Kanban mode
Clusters have the choice of planning, executing and controlling their work in a rhythm of fixed time units, ie in Cycles, or in a continuous flow, with each Backlog item individually going through the different states of the work process of the Cluster. This is made transparent on a Kanban board.
A Cluster chooses between Cycle-mode and Kanban-mode, depending on the product and how planning and approval are carried out. With a regular release rhythm, for example every three months, work in Cycles is recommended.
Cycle Backlog
The Cycle Backlog reflects the work of a Cluster for a currently running Cycle . The estimated work, ie backlog elements, is pulled into the Cycle Backlog by the TSEG at the beginning of the Cycle (pull) and thus scheduled for the next Cycle (forecast).
Cluster Kanban
If the Cluster works in Kanban-mode, it uses a Cluster Kanban Board instead of the Cycle Backlog. The first column corresponds to the Cluster Backlog and the last column to the status “Done”. All other columns are defined by the Team Scrum Master Group of the cluster, according to the internal Cluster work process.
.
\r\n
Further suitable links:
