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 …)
Category: Market & Business
Cluster Product Owner (CPO)
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 …)
System Increment
System increments are partial or full integrations of system versions that are verified by internal or external tests, as well as by user and / or market tests.
System increments are often generated at the Cluster level, ie by integrating partial results from the different teams in a cluster.
For the system increment, P4 has adopted the types and definitions of patterns from the Design Thinking Framework. You also use it to define the maturity levels of the samples.
The level of maturity is ultimately defined by the type and number of Knowledge Gaps. Patterns are built to close Knowledge Gaps.
.
\r\n
Further suitable links:
Events | Roles | Groups | Artifacts |
Cluster Planning | Cluster Product Owner | Team Product Owner Group | Cluster Backlog |
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).
Product Owner is responsible for Market & Business
The P4 framework divides its organizational and management structure of product development into three areas:
- Market and Business (see below)
- Organization, infrastructure and processes
- Technology and Architecture
Market and Business
The Product Owner roles at the various levels bear responsibility for the products and their markets. In doing so, they communicate with the Stakeholders in this area: Users, Customers and the (mostly internal) Sales Department.
The role of the Product Owner
Product, Product Backlog and Product Owner are generic terms in the P4 framework, that is, they only exist in specific forms. The generic artifacts “Product” and “Product Backlog” and the generic role “Product Owner” depend on the level within the organization (Team, Cluster, Organization/Portfolio) or on the specific type of team.
The Product Owner is responsible for maximizing the value of the Product resulting from the results of the Working Team. How this is done can vary greatly between Organizations, Clusters or Teams. The Product Owner is the only person responsible for managing the Product Backlog. The management of the Product Backlog includes:
- To clearly formulate the Product Backlog Items (PBI) = Entries of the Product Backlog;
- Order the entries in the Product Backlog in such a way that goals and missions can be optimally achieved;
- To optimize the value of the work carried out by the Working Team;
- Ensure that the Product Backlog is visible, transparent and clear to all Stakeholders and shows what the Team will work on next;
- Ensure that the Working Team understands the Product Backlog entries to the extent necessary; and
- To review and approve the results of the Working Team.
The Product Owner can carry out the above mentioned work himself or have it carried out by the Working Team or individual members. However, the Product Owner remains accountable at all times.
The Product Owner is an individual person, not a committee. She/he can reflect the wishes of a committee in the Product Backlog, but those who wish to change the priority of a Product Backlog Item must contact the Product Owner. For the Product Owner to be successful, the entire organization must respect her/his decisions. The decisions of the Product Owner are visible in the content and order of the Product Backlog. No one else may assign requirements or work to the Working Team.
Product Owners in the P4 framework
In the P4 framework, the generic role of the Product Owner is concretized on all three levels: It is important that the Product Owners on each level coordinate with each other within the respective POG and derive the priorities for their teams from the superior backlog. See “The overlap principal” for more information.
- the Team Product Owner (TPO) as the PO for a single Team. All TPOs of the same team Cluster form the Team Product Owner Group (TPOG) of that Cluster, which is lead and moderated by the Cluster Product Owner.
- the Cluster Product Owner as the PO for a Cluster of several Teams. All CPOs form the Cluster Product Owner Group (CPOG) of the Organization, which is lead and moderated by the Portfolio Owner.
- the Portfolio Owner as the PO for the entire Organization.
.
Further suitable articles:
Events | Rollen | Gruppen | Artefakte |
Team Planning
. . |
Team System Engineer
. . |
Team Product Owner Gruppe
. |
Team Backlog
. Usable Knowledge & System Increment . |
System Requirements & Functions
Systems are described at the top level by System Requirements and Functions (features). Requirements only describe abilities or properties in the “problem area”, so they are still independent of concrete system solutions. The solution space is already limited by the Quality Attributes & Constraints .
Interfaces to neighboring systems in the environment and their properties are also specified here. For this a sogn. Context diagram created and used.
Functional System Requirements of the stakeholders are often written in the form of User Stories * and later specified using “Use cases“.
*) P4 introduces the term “Stakeholder Stories” in this context, since they are suitable for the specification of requirements of all stakeholders, not just the user.
**) Non-functional requirements (NFR) are not written directly into the system backlog in P4 (see Quality Attributes & Constraints )
\r\n
Further suitable links:
System Requirements on Wikipedia
Events | Roles | Groups | Artifacts |
Cluster Planning | .
. |
Team Product Owner Group
. |
Inspectable Results
. 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 . |
Cluster Product Owner Group (CPOG)
The Cluster Product Owner Group consists of the Cluster Product Owners of all Clusters in the Organization, plus the Portfolio Owner. It has the overall responsibility for market and business side of the product development process on the Portfolio and organizational level.
Team Product Owner Group (TPOG)
The Team Product Owner Group consists of all Team Product Owners of a Cluster and the Cluster Product Owner . At the Cluster and system level, it is responsible for the Market and Business side of the product development process.
Users, Customers and Sales
These are the primary Stakeholders in product development at all levels (Organization , Cluster and Team ). At the Team level, the Application Teams in particular have close contact with Users, Customers and sales, as they give and evaluate the ultimate requirements for the products, systems and applications.
Stakeholders are invited to the Review meetings (ie the Team Reviews, Cluster Review, Portfolio Review) to give feedback to the appropriate team.
Stakeholders can be invited to Team Refinement meetings to clarify requirements.
.
Suitable and further articles:
Events | roll | groups | Artifacts |
Team Backlog Refinement
. . |
Team Product Owner
. .
|
Working team
. Management circle of the cluster . |
Team Backlog
. Usable Knowledge & system increment . |