The teams of all Clusters in the organization , the Cluster System Engineer Group , the Cluster Product Owner Group and the stakeholders must understand what it means when a backlog entry or a result is referred to as “done”. Although the Cluster DoDs can differ significantly from Cluster to cluster, there is only one portfolio-level DoD for the entire Organization.
Category: Organization Level
Products, Applications and Market Variants
The Portfolio Backlog at the Organizational level, the top level of all Backlogs, contains Systems, Products and Application variants, as well as product variants for special markets. Each of these product variants is described by a set of System Requirements (feature set). In this way, the product variants can be estimated against each other with regard to both the benefits and the effort to be invested . The so-called Upswing Gravity Field is used for this in the P4 framework .
The Portfolio level is not necessary for organizations that create only one product.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Portfolio Planning | Portfolio Owner | Cluster Product Owner Group | .
|
Portfolio Backlog, Portfolio Cycle Backlog & Portfolio Kanban
The top level of the Backlogs of the P4 framework, the Portfolio and Organizational level , describes Applications and market variants of the Systems and Products. Each of these variants is described by a set of System Requirements (feature set).
Oranization Level
Die Organisationsebene repräsentiert die oberste Ebene in der Produktentwicklung, und damit alle Personen, Rollen und Gruppen. Sie wird auch als Portfolio-Ebene bezeichnet. Alle Arbeiten der Organisation sind im Portfolio-Backlog mit größtmöglicher Transparenz dargestellt.
Cluster System Engineer Group (CSEG)
The Cluster System Engineer Group (CSEG) consists of the Cluster System Engineers of all Clusters in the Organization . At the organizational level, it corresponds to the role of the Working Team at the team level.
Together with the Portfolio Architect , the Cluster System Engineer Group is responsible for the Technology and Architecture side of the product development process at the organizational and portfolio level .
Cadence of a year
The Cadence is a centrally defined event planning for the Organization. Similar to a schedule at a school or university, it enables …
- all roles within the organization can participate in the events intended for them. (No overlapping invitations)
- all private events of the Teams and Groups take place at the same time in order to allow as much free working time as possible within the Teams and Groups
The Cadence of a year in the P4 Framework consists of four Cycles, each of which is a quarter. Various organizational and cluster events take place at the transitions between the Cycles, similar to the Iteration transfer in Scrum. It is advisable not to set the Cycle transfer to calendar four-year boundaries, so that a change does not, for example, collide with the turn of the year and the previous Christmas season.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Team Product Owner
. . |
Working Team
. . |
Team Backlog
. Usable Knowledge & System Increment . |
Applications and Market Variants
Applications and market versions are integrated, tested and approved products of the organization that can be sold in target markets to customers. They meet the requirements specified as a group from the Stakeholer Needs in the ” feature sets “. These are individually defined in the System Requirements & Functions as well as the Quality Attributes & Constraints (QA&C) .
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Cluster Planning
. |
.
. |
Team Product Owner Group
. |
Inspectable Results
. Usable Knowledge & System Increment . |
Marketable Systems and Applications
Applications and market variants are the organization’s integrated, tested and approved products that can be sold to customers in the target markets. They meet the requirements specified as a group from the Stakeholer Needs in the ” feature sets “. These are individually defined in the System Requirements & Functions as well as the Quality Attributes & Constraints (QA&C) .
.
Suitable and further articles:
| Events | Roles | Groups | Artifacts |
| Cluster planning
. |
Cluster Product Owner
. |
Team Product Owner Group
Management circle of the cluster . |
Inspectable results
. Usable Knowledge & system increment . |
Practice Lead
Practice leads are professional coaches or trainers within the organization who take care of expertise or technical discipline. They lead a community of practice , train their members and take care of the further development of the topic and the employees within the Organization.
In the transition from classic organizations, the former line managers can become Practice Leads.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Iteration
.
|
Community of Practice
. . |
Practice Backlog |
Communities of Practice
Communities-of-Practice (CoP) are groups that deal with specific knowledge and experience topics. All employees have the opportunity to work in the self-organized CoPs within their “practice time” or training period. The P4 framework provides about 10% of the working time for this.