Stakeholder

15. April 202028. April 2020 Oliver Schönfeld

Stakeholders are all persons and groups affected by a system, as well as all those directly interested or involved in the product. Stakeholders are invited to Review meetings at all levels and can optionally be invited to Backlog Refinement meetings to explain their requirements.

To identify stakeholders, the P4 framework uses two different life cycles as conceptual guidelines. These are:

the product life Cycle (from the idea to the end of product maintenance) and
the single item life Cycle (from purchase of raw material to recycling)

For each product or system, the different stakeholders (= interest groups) can be identified from these.

Product life cycle

Item life cycle

The P4 framework distinguishes between three groups of stakeholders, which are assigned to the three areas

Other stakeholders

In addition to the “direct” stakeholders, other, “more general” stakeholders are usually defined in requirements management. These are, for example

the society, consisting of public and government organizations
the environment (mostly affected by emissions and waste)
competitors

In the P4 framework, these stakeholders are not represented by Stakeholder Needs, but by specific goals (e.g. to describe the competitive situation) or they are represented by norms and standards in the area of Quality Attributes & Constraints (QA&C).

Stakeholder map

A Stakeholder map shows the various stakeholders with their needs and the strength of their influence on the team or system.

\r\n

Further suitable links:

Definition on Wikipedia: Stakeholder

Cluster Review

31. December 201911. May 2020 Oliver Schönfeld

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 participants, consisting of the Team System Engineer Group (TSEG) and important stakeholders who are invited by the Cluster Product Owner . These are often also the POs of the teams, ie the Team Product Owner Group .
The Cluster Product Owner explains which Cluster Backlog Items (CBI) have been completed.
The TSEG shows what went well during the cycle , which problems arose , and how it solved these problems. The TSEG may ask for support from the stakeholders.
The TSEG shows the completed work results and answers questions about them. Work results can be:
- Usable Knowledge and (design) decisions made by TSEG ,
- an integrated version of the system, platform or application
The Cluster Product Owner presents the current status of the Cluster Backlog . If necessary, it provides an updated forecast of probable target and delivery dates based on the development progress, e.g. by using a burn-up chart based on the working speed of the Cluster ( velocity )
All participants work together on what to do next, so that the Cluster Product Owner receives valuable input for the upcoming Cluster Planning .
Then the schedule, budget, as well as the potential properties and market expectations for the next version of the application (release) are checked.

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 planning

Cluster Sync

Cluster Backlog Refinement

Cluster Retrospective

Portfolio Review

Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master

Team Product Owner Group

Team System Engineer Group

Team Scrum Master Group

Cluster Management Circle

Cluster Backlog

Usable Knowledge & System Increment

Cluster DoD

Cluster Improvement Backlog

Cluster Backlog

29. September 201916. May 2020 Oliver Schönfeld

Each Cluster has exactly one Backlog for its area of responsibility and tasks , the Cluster Backlog. In its simplest form, it consists of elements of just one System development that all Teams in the Cluster are working on. In this case, the Cluster Backlog can be referred to as the System Backlog. If the Cluster is responsible for several systems, all backlog elements of the different systems are contained within the Cluster Backlog.

The Team Product Owner Group is responsible for and prioritizes the Cluster Backlog .The Team Product Owner Group consists of all Team Product Owners of the Cluster and the Cluster Product Owners. A large part of the Cluster Backlog is derived by the Cluster Product Owner Group and the Cluster System Engineer Group from the Portfolio Backlog by refinement in the Portfolio Backlog Refinements .

The other part of the Cluster Backlog consists of work and measures that the Cluster carries out to improve the quality of work and results, e.g.

Quality measures and improvement of the Cluster process (ie the Cluster Improvement Backlog)
Maintenance of the products, systems and Modules responsible for the cluster
Maintenance and servicing of tools and tools.

In order to make the working speed of the Clusters more predictable, the proportion of backlog items derived from the Portfolio Backlog should be relatively stable over time.

The Cluster Backlog is prioritized by the Cluster Product Owner.

In the Cluster Backlog Refinement , the Cluster Backlog Items are presented by the Cluster Product Owner and estimated by the Team System Engineer Group (TSEG). Since this consists of members of all Teams in the Cluster, this group is best suited for this.

In the Cluster Planning, the TSEG pulls as many Cluster Backlog Items into the Cycle as the TSEG believes due to the previous working speed of the cluster. This is the Cycle Backlog that represents the plan for the next cycle.

Work in cycles or in continuous Kanban mode

Clusters have the choice of planning, executing and controlling their work in a rhythm of fixed time units, ie in Cycles, or in a continuous flow, with each Backlog item individually going through the different states of the work process of the Cluster. This is made transparent on a Kanban board.

A Cluster chooses between Cycle-mode and Kanban-mode, depending on the product and how planning and approval are carried out. With a regular release rhythm, for example every three months, work in Cycles is recommended.

Cycle Backlog

The Cycle Backlog reflects the work of a Cluster for a currently running Cycle . The estimated work, ie backlog elements, is pulled into the Cycle Backlog by the TSEG at the beginning of the Cycle (pull) and thus scheduled for the next Cycle (forecast).

Cluster Kanban

If the Cluster works in Kanban-mode, it uses a Cluster Kanban Board instead of the Cycle Backlog. The first column corresponds to the Cluster Backlog and the last column to the status “Done”. All other columns are defined by the Team Scrum Master Group of the cluster, according to the internal Cluster work process.

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Cluster Planning

Cluster Sync

Cluster Backlog Refinement

Cluster Review

Cluster Retrospective

Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master

Team Product Owner Group

Team System Engineer Group

Team Scrum Master Group

Cluster Management Circle

Team Backlog

Usable Knowledge & System Increment

Cluster DoD

Cluster Improvement Backlog

Portfolio Backlog

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: