With organizational modeling, the specific organization is modeled by P4 elements, i.e. the teams, groups and Clusters are represented by their information and work flows.
The processes can now be represented within the organizational model, whereby this is done by defining and documenting the corresponding inputs, responsibilities, actions and outputs. Every organizational unit is described according to the SIPOC method (Supplier – Inputs – Process – Outputs – Customers).
The Team Calendar shows the availability of the Nucleus and Extended Team members for an Iteration. Each Team Member enters planned absences in order to determine the gross capacity of the team before (or at the latest in) the Iteration Planning. The gros capacity is used to adjust the work forecast by relating it to the team’s Velocity, which significantly improves predictability.
The concept of a calendar to determine the gros capacity can also be used for Clusters and cycles, ideally based on public holidays and the longer-term vacation planning of the team members .
If the team does not work with iterations but continuously by means of Kanban, the team calendar is maintained for several weeks in advance on a weekly basis.
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 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 organization. Often the CEO of the Organization is leading this Management Circle.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Portfolio Planning | Team Product Owner
.
|
Team Product Owner Group
. |
Portfolio Backlog |
The Organization Retrospective offers the Organization Scrum Master (OSM) the opportunity to review the working methods of the organization, represented by the Portfolio Owner (PFO) and the Cluster System Engineer Group (CSEG) , as well as improvements to the Identify and plan how to work for the coming cycle . The Organization Retrospective takes place between the Portfolio Review and the next Portfolio Planning and is based on the results of the Cluster Retrospectives , mostly from the Cluster Scrum Master Groupwere processed. An upper limit of four hours is set for this for a quarterly cycle. The Organizational Scrum Master (OSM) ensures that the meeting takes place and that all participants understand its purpose. The OSM 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 OSM takes part in the Organization Retrospective as an equal member. It is carried out to …
The Cluster Scrum Master Group is working to improve the organization’s development processes and practices so that the Clusters can work more effectively and satisfactorily in the coming cycle. In every Organization Retrospective, the Cluster 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 Organization Retrospective, the CSMG should have identified improvements for the coming cycle.
Die CSMG überprüft in der Organisations-Retrospektive ebenfalls die Arbeitsflüsse (Workflows) zwischen den Clustern (z.B. durch Value-Stream-Mapping) und passt die Verantwortungsbereiche der Cluster und ggf. auch die Cluster-Strukturen innerhalb des Organisation an.
Die Cluster-Scrum-Master nehmen die Verbesserungsvorschläge und -maßnahmen mit in ihre Cluster.
Meist bringen die Cluster-Scrum-Master Probleme, Behinderungen (Impediments) und Verbesserungsideen (Improvements) aus ihren Clustern mit in die CSMG, die sie in den Cluster-Retrospektiven der Cluster gesammelt haben. Diese werden im Organisations-Improvement-Backlog gesammelt und priorisiert. In der Arbeitszeit der CSMG werden die am höchsten priorisierten Improvements während des laufenden Cycles analysiert und bearbeitet. In der Organisations-Retrospektive werden Änderungen dann gemeinsam beschlossen und umgesetzt.
Für die Ermittlung von weiteren Problemen, Behinderungen und Verbesserungsideen auf Organisations-Ebene, nutzt die CSMG die gleichen methodischen Ansätze und Fragestellungen, wie auf Team-Ebene, z.B.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Retrospective
. . |
Portfolio Owner | Cluster Product Owner Group | Portfolio Backlog |
At the end of each Cycle, a Portfolio Review is held in which the Cluster System Engineer Group (CSEG) and the Portfolio Owner (PFO) present the results to the Stakeholders. They receive feedback from the Stakeholders on the results so that the Portfolio Owner can adjust the Portfolio Backlog if necessary . Along with any changes to the Portfolio Backlog that were incorporated during the Cycle (e.g. in the Portfolio Backlog Refinements), they provide the basis for working together on possible new items that add value to the Portfolio. The Portfolio Review is an informal meeting, not a status report in the classical sense. The presentation of the results is intended as a suggestion for feedback and a basis for cooperation. At the end of the Portfolio Review, the Portfolio Owner can give an update on budgets and important milestones.
For a twelve-week Cycle, an upper limit of four hours is set as the time frame for this meeting. A correspondingly shorter time frame is estimated for shorter Cycles. The Organizational Scrum Master (OSM) ensures that the event takes place and that the participants understand its purpose. The OSM teaches everyone involved to run the event within the specified time frame.
The Portfolio Review includes the following elements:
The result of the Portfolio Review is a revised Portfolio Backlog that corresponds to the common level of knowledge of the participants and through which the CSEG can work on the Portfolio Backlog Items with the highest value in the next Cycle. The Portfolio Backlog can also be extensively redesigned to take advantage of new opportunities.
.
Suitable and further articles:
| Events | Roles | Groups | Artifacts |
| Team Review
. . |
Portfolio Owner | Cluster Product Owner Group | Portfolio Backlog |
Planning at the Portfolio level is a semi-continuous process in the P4 framework, just like budget planning, for example, which is closely linked to Portfolio Planning. The planning process consists of the preparation through the Portfolio refinement and the Portfolio Planning event. The planning process takes place at the level of the Portfolio Backlog elements. These are:
Time is often planned in the following sections, according to the principle “the closer, the finer”:
Changes to the Portfolio Planning therefore flow into the Organization well prepared and at certain times. When displayed on a Portfolio Kanban board, the entire work of the Organization becomes transparent.
Every cycle for the entire Organization begins with the Portfolio Planning. In this, the Portfolio Owner (PFO) of the Cluster System Engineer Group (CSEG) presents the current status of the Portfolio Backlog . New entries or changes that have not yet been known to the Cluster System Engineer Group since the last Portfolio Backlog Refinement are estimated, supplemented by Acceptance Criteria and prioritized by the Portfolio Owner within the Portfolio Backlog.
The Cluster System Engineer Group determines the capacity for the next Cycle by looking at the previous “working speed” of the Organization (organizational Velocity) and by looking at the capacity of the Clusters in the next cycle.
The Cluster System Engineer Group pulls the number of Portfolio Backlog Items (PFBI), which corresponds to the CSEG’s assessment of the capacity in the next cycle, into the Cycle Backlog of the Organization (pull). The Cluster Product Owners then use the CSEG to refine the PFBIs into Cluster Backlog Items that are required to complete the PFBIs.
Then the CSEG starts the Cycle by pulling the first items from the “open” to “in progress” state.
Alternatively, the entire Portfolio Planning can also be carried out continuously using a Kanban system. The Cycle as a timebox and the Velocity as a measure of the working speed are omitted. The continuous Portfolio Planning is then carried out through regular meetings between the CSEG and the Portfolio Owner (usually once per Iteration). The activities “introducing”, “estimating” and prioritizing backlog elements then take place on the basis of individual elements. Backlog elements are pulled on the basis of Work-in-progress limits (WiP limit).
.
Further suitable links:\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Portfolio Owner | Cluster Product Owner Group | Portfolio Backlog |
Refinement of the Portfolio Backlog is the process of adding details to backlog entries, making estimates, splitting backlog entries, or changing the order of entries in the Portfolio Backlog. Refinement is a continuous process in which the Portfolio Owner and the Cluster System Engineer Group (CSEG) jointly detail the Portfolio Backlog entries. The entries are examined and revised as the Portfolio Backlog is refined. However, the Portfolio Owner can update or have the entries in the Portfolio Backlog updated at any time.
The Portfolio Backlog refinement is mainly used to prepare the next Portfolio Planning . The Portfolio Owner of the Cluster System Engineer Group (CSEG) presents new backlog entries and has them estimated. This is a prerequisite for the “pull” of the CSEG and is often referred to as definition-of-ready . In the case of unclear but highly prioritized backlog entries, the CSEG clarifies the System Requirements , possible System Concepts and capabilities . This can be worked out as a group or a corresponding backlog entry can be created as an order for one of the Clusters.
Estimates by the entire Cluster System Engineer Group are important for two reasons:
The team uses the Planning-Poker ® methodology to estimate the effort .
Further suitable links:\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Backlog Refinement .
. |
Portfolio Owner | Cluster Product Owner Group | Portfolio Backlog |
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 |