A Cluster within the product development Organization is managed by a group of managers. It consists of at least the following roles:
Other management roles complement the Management Circle depending on the type and orientation of the Cluster.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Cluster Planning
. |
Team Product Owner
.
.
|
Team Product Owner Group
. |
Cluster Backlog
Usable Knowledge & System Increment . |
The Cluster Retrospective offers the Cluster Scrum Master (CSM) the opportunity to review the working methods of the cluster, represented by the Cluster Product Owner and the Team System Engineer Group (TSEG) , as well as improvements in the way of working identify and plan for the coming cycle . The Cluster Retrospective takes place between the Cluster Review and the next Cluster Planning and is based on the results of the Team Retrospectives of the teams , mostly from the Team Scrum Master Groupwere processed. An upper limit of four hours is set for this for a quarterly cycle. The meeting is usually shorter for shorter cycles. The CSM ensures that the meeting takes place and that all participants understand its purpose. The CSM ensures that the meeting is constructive and productive and teaches everyone to stick to the time frame (time box). Due to its responsibility for the P4 process, the CSM takes part in the Cluster Retrospective as an equal member. It is carried out to …
The Team Scrum Master Group is working to improve the cluster’s development processes and practices so that the cluster’s teams can work more effectively and satisfactorily in the coming cycle. In each Cluster Retrospective, the Team Scrum Master Group works out ways to improve result quality by adapting the processes accordingly or by defining-of-done, provided these changes are appropriate and do not conflict with product or company standards. At the end of the Cluster Retrospective, the TSMG should have identified improvements for the coming cycle.
In the Cluster Retrospective, the Team Scrum Master Group also checks the workflows between the teams (e.g. using value stream mapping) and adjusts the areas of responsibility of the teams and, if necessary, also the team structures within the Cluster .
The Team Scrum Masters take the suggestions and measures with them into their teams.
Mostly, the Team Scrum Masters bring problems, impediments and improvements from their teams with them to the TSMG, which they have collected in the Team Retrospectives of the teams. These are collected and prioritized in the Cluster Improvement Backlog. During the working hours of TSMG, the highest priority improvements are analyzed and processed during the current cycle. In the Cluster Retrospective, changes are then jointly decided and implemented.
For the determination of further problems, disabilities and ideas for improvement at the Cluster level, the TSMG uses the same methodological approaches and questions as at the team level, e.g.
.
Further suitable links:\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Retrospective
. . |
Cluster Product Owner | Team Product Owner Group | Cluster Backlog |
At the end of each cycle , a Cluster Review is held in which the Team System Engineer Group (TSEG) and the Cluster Product Owner (CPO) present the results to the stakeholders. They receive feedback from the stakeholders on the results so that the CPO can adjust the Cluster Backlog if necessary . Along with any changes to the Cluster Backlog that were incorporated during the Cycle (e.g. in the Cluster Backlog Refinements), they provide the basis for working together on possible new entries that increase the value of the “Cluster products”. The Cluster Review is an informal meeting, not a status report in the classic sense. The presentation of the results is intended as a suggestion for feedback and the basis for cooperation. At the end of the Cluster Review, the Cluster Product Owner can give an update on costs and planned dates or milestones.
For a twelve-week cycle , an upper limit of four hours is set as the time frame for this meeting. A corresponding shorter time frame is estimated for shorter cycles. The Cluster Scrum Master (CSM) ensures that the event takes place and that the participants understand its purpose. The CSM teaches everyone involved to hold the event within the given time frame.
The Cluster Review includes the following elements:
The result of the Cluster Review is a revised Cluster Backlog that corresponds to the common level of knowledge of the participants and through which the TSEG can work on the Cluster Backlog Items with the highest value in the next cycle . The Cluster Backlog can also be extensively reworked to take advantage of new opportunities.
.
Further suitable links:\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Review
. . |
Cluster Product Owner | Team Product Owner Group | Cluster Backlog |
Refinement of the Cluster Backlog is viewed as the process of adding details to backlog entries, making estimates, or determining the order of entries in the Cluster Backlog.
With the Team System Engineer Group at the Cluster / system level, the cluster System Engineer is responsible for the technology and architecture within the product creation process.
The Cluster Product Owner is part of the Team Product Owner Group (TPOG). They have the responsibility for the market and business side of the product development process at the Cluster and System level,. (A general description of the product owner role can be found here …)
Each Cycle begins with a Cluster Planning event. In this, the Cluster Product Owner of the Team System Engineer Group (TSEG) presents the current status of the Cluster Backlog . New entries or changes that have not been known to the TSEG since the last Cluster Backlog Refinement are estimated, supplemented by Acceptance Criteria and prioritized by the Cluster Product Owner within the Cluster Backlog.
The TSEG determines the Capacity for the next Cycle by looking at the previous “working speed” of the Cluster (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 Cycle by pulling the first items from “open” to “in progress”.
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.
.
Further suitable links:\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Cluster Product Owner | Team Product Owner Group | Cluster Backlog |
The Improvement Backlog is the planning and structuring tool of the Scrum Master. There are Improvement Backlogs on all three levels of the P4 framework (Team, Cluster, Organization).
Each Team that identifies more improvements than can currently be implemented stores these improvements in their Team Improvement Backlog , which the Team Scrum Master prioritizes with the Team .
The sum of the improvements of a Cluster is located in the Cluster Improvement Backlog, which the Cluster Scrum Master prioritizes with the Team Scrum Master Group . The Cluster Improvement Backlog is mostly fed by the Teams’ suggestions for improvement.
The total of an Organization’s improvements is in the Organization Improvement backlog , which the Organization Scrum Master prioritizes with the Cluster Scrum Master Group . The Organization Improvement Backlog is mostly fed from the cluster’s suggestions for improvement.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Cluster Planning | Cluster Product Owner | Team Product Owner Group | Team Improvement Backlog
. Usable Knowledge & System Increment . |
The Teams of the Cluster , the Team System Engineer Group , the Team Product Owner Group and the Stakeholders must agree on what it means when a Backlog Item or a result is marked as “done”. Although this can vary significantly from Cluster to cluster, everyone must have a common understanding of when work is done to ensure transparency. This is done through the Definition-of-done of the respective Cluster.
The DoD also guides the Team System Engineer Group in deciding how many Cluster Backlog Items it can pull into the Cycle Backlog during Cluster Planning. The purpose of each Cycle is to provide Inspectable Results, Usable Knowledge, or potentially deliverable functionality within a System Increment that correspond to the current Definition-of-done. Clusters provide an increment of results, knowledge and / or system functionality in each Cycle. This increment is fully usable so that the Cluster Product Owner can choose to release it at any time.
If the Definition-of-done for a product is part of an organization’s conventions, standards, or guidelines, all Clusters must follow them as a minimum goal. If “Done” for a result is not part of the organization’s convention, the Cluster (ie the TSEG) must formulate a definition-of-done that is appropriate for the product. If there are several Clusters working on the same system, all Clusters must create a definition of done together. Each system increment is additive to all previous increments and has been thoroughly tested to ensure that all increments work together. More mature Clusters are expected to expand their respective definition-of-done appropriately to ensure stricter criteria for higher quality. New entries in the definition-of-done can cause
Every single result, product or system should have a definition of done, which is the standard for any work performed on it.
The DoD therefore is the essence of the process descriptions and “standard operation procedures” of a classic organization, but in a strongly condensed form.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Cluster Planning | Cluster Product Owner | Team Product Owner Group | Team DoD
. Usable Knowledge & System Increment . |
Each Cluster consists of several teams and divides the Organization into meaningful value streams. He organizes the various systems, applications (products) and markets. For this he has a Cluster Backlog with system versions consisting of features and Modules as elements, a Cluster Kanban board and the Cluster DoD .