User Requirement – P4-Dev Framework V2

Product Owner is responsible for Market & Business

25. September 201915. May 2020 Oliver Schönfeld

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:

Backlog Item Types

11. August 201915. May 2020 Oliver Schönfeld

“The Backlog is the only source of the work.” The general description of Backlogs and their properties can be found here.

Backlog entries or Backlog Items are the individual building blocks of backlogs. They are clearly ranked within the backlogs, i.e. clearly prioritized. The higher a backlog entry is, the more important it is and the earlier it is processed.

Similarities

All backlog entries have the following properties and attributes:

A unique short name or other identification (e.g. a number)
A description that is as short as possible but meaningful
An indication of who the source or author of the backlog entry is. This should make it clear who you can ask if anything is unclear.
Acceptance criteria are defined for concretization and delimitation
(Optional) At the Portfolio and system level, the respective Product Owners estimate the benefit/value of Applications and Features. For this purpose, benefit values of different applications/features are evaluated relatively against each other, whereby the Product Owners use Planning Poker, for example.
To indicate that the team in question has performed an analysis and assessment, the estimated effort is noted on the backlog entry

Subdivision of Backlog Items according to type, level, size and format

Formats

In software development, specifying Backlog Items in the format of User Stories has become established. Here, a user request is described in the form of a sentence (who wants what, why). P4 prefers the term Stakeholder Story here, since the users of the system represent only a part of the requestors.

Use Cases that can be divided into different scenarios are often used for further elaboration .

Using Text Requirements , individual Components, interfaces and their abilities and properties can be described.

Size

For a team to edit a Story , it must be small enough to fit into an iteration. Larger stories are Epics by definition , whereby epics in turn have to be divided into several stories.

Type and level

The sum of each Backlog Item level represents the total effort of product development or a System, Market or Application variant that can be delivered.

This is also the idea of epics, stories and tasks that many teams use when using Scrum. The sum of the effort in all epics corresponds to the sum of the effort in all stories. This is based on the (theoretical) assumption that a story is done when all tasks are done and an epic is done when all the contained stories are done. It is the same with the total effort.

If an Application Team or the Cluster System Engineer Group is able to estimate all backlog entries based on the System Requirements & Functions with the limiting Quality Attributes & Constraints , the total effort of an application is completely estimated. Since this is usually not easy, the requirements must be broken down further to the solution level of the System Concepts, architecture and capabilities . At this level, too, it will usually not be possible to estimate all concept elements precisely enough, as there are still many unknowns and uncertainties (in P4: Knowledge Gaps ) regarding the feasibility and the type of implementation.

The concept of Knowledge Gaps is based on the assumption that after all Knowledge Gaps have been closed, product development is successfully completed. The sum of the efforts to close all Knowledge Gaps also corresponds to the total effort of product development. However, making the estimation possible at this level requires a certain amount of time before the organization has learned to do so with sufficient accuracy.

Organizations normally estimate their efforts based on the Samples & Integrations , since the efforts to close the Knowledge Gaps, their boundary conditions and assumptions are defined in a much more concrete way and the backlog entries are refined down to the level of the simulations, patterns and prototypes to be built. It is important here that the incremental and possibly multiple generation and integration of patterns is sufficiently taken into account and depending on the degree of innovation and the degree of risk of Knowledge Gaps, several “proven-of-concepts” or disposable prototypes may be necessary.

A further breakdown at the working level is necessary when Samples & Integrations are implemented by several teams. For this purpose, the backlog entries are divided into Team Goals according to the teams involved , and each team estimates the effort they incur. These can be retrospectively assigned to actual expenses and the relative estimates standardized or calibrated.

At every level of the backlog types, product development is completely described and appreciated. When using relative points for the assessment, a separate “currency” is used at each level. The currencies can be converted into each other if, after some time, data are available that show the speed at which the organization is developing at the various levels (Velocity ).

\r\n

Further suitable links:

Users, Customers and Sales

20. June 201915. May 2020 Oliver Schönfeld

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: