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 |
With the Cluster System Engineer Group at Portfolio and organizational level, the Portfolio architect is responsible for the technology and architecture side of the entire product development process.
The Portfolio architect forms the management of the entire Organization together with the Portfolio Owner and the Organization Scrum Master .
The Portfolio Owner is the “Product Owner” the Organization and has, together with the Cluster Product Owner Group (CPOG) on the Portfolio- or Organizational level, overall responsibility for the Market and Business side of the product development process. (A general description of the Product Owner role can be found here …)
The Organization is the top level in P4 and organizes the portfolio. For this purpose, the Organization has a Portfolio Backlog with applications as elements, a Portfolio Kanban board and the organization DoD .
This event enables several Clusters to communicate with each other in order to coordinate dependencies, disruptions, new findings and decisions, etc. during ongoing work. The Clusters themselves decide how often this is needed (e.g. daily, weekly).
The representatives of the Cluster can be the Cluster System Engineers of the Clusters. However, other technical representatives of the Cluster can also be designated.
The Organization Sync takes place (usually in a semicircle) in front of the Portfolio Kanban Board of the Organization , since the members move the Portfolio Backlog Items in the Organization Sync.
The three questions in Organization Sync are:
In a similar way, the structure of the Organization Sync can also be used for the exchange of certain roles or expertise, e.g. a sync of the Cluster Scrum Masters , the Cluster Product Owners , the testers, the designers, designers, etc. of a Cluster .
Due to the shortness of a maximum of 15 minutes, the Organization Sync is only suitable for identifying problems, but not for discussing or solving them. The required members can use the time after the Organization Sync to discuss problems, while the unnecessary members can continue to work.
Visitors who want to experience the Organization Sync can participate with the permission of the members. The visitors are in the second row and only listen, unless they are addressed by an active member. Visitors can be:
.
Further suitable links:\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Sync
. . |
Portfolio Owner | Cluster Product Owner Group | Portfolio 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 |
| Portfolio Planning | Portfolio Owner | Cluster Product Owner Group | Team Improvement Backlog
. . |