Stakeholder Needs

13. August 201911. May 2020 Oliver Schönfeld

Stakeholders are all persons and groups of people affected by a system, as well as everyone directly interested or involved in the product. Stakeholders are invited to the reviews at all levels and can optionally be invited to backlog refinement meetings to explain their requirements.

In order 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 piece life Cycle (from purchasing the raw material to recycling)

The different stakeholders (= interest groups) can be identified for each product or system.

Product life cycle

Single piece life cycle

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

Stakeholer Needs

Stakeholer Needs are the needs of the stakeholders identified in the first step. They do not represent actual Backlog Item types, but they do allow the benefits of new or changed requirements to become clearer. They represent the top level of requirements and should be constantly updated (not only when new product developments are started). This is usually easy because Stakeholer Needs change relatively slowly.

\r\n

Further suitable links:

Supplier, Supply Chain & Production

23. June 201916. May 2020 Oliver Schönfeld

Suppliers are important external Stakeholders of product development at all levels (Organization , Cluster and Team ) and supply chain and production are important internal Stakeholders. At the Team level, the Module Teams in particular, have close contact with suppliers because they provide important boundary conditions for the technology.

Stakeholders are invited to the review events on all levels, to give feedback to the relevant organizational units. These can be Team Reviews of the teams, Cluster Reviews of the Clusters or Portfolio Reviews .

Stakeholders can be invited to refinement meetings to clarify requirements. These can be Team Backlog Refinements , Cluster Backlog Refinements or Portfolio refinements .

Suitable and further articles:

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:

Team Level: Collaboration within the Teams

7. May 201919. May 2020 Oliver Schönfeld

The Team is the basic element of an agile organization and forms the home of employees.

Most of the work takes place in stable and long-lasting Teams. Due to the stability or “longevity”, the teams are available in the event of problems even if the Application or Market Variant is not currently being revised (ie when the classic project teams no longer exist).

P4 adopts the basic structure of a Scrum team. It consists of a Team Product Owner , Team Scrum Master and the Working Team who works together to create value for the Stakeholders. The principle of the separation of powers creates clearly defined areas of role responsibility that complement each other in the Team.

The Team Product Owner is responsible for maximizing the value of the “Product” resulting from the work of the Working Team. How this happens can vary greatly depending on the organization and Working Team, as well as the experts working in them. The Team Product Owner is the only person responsible for managing the Team Backlog.

The Working Team consists of three to nine members and the Team System Engineer , who work out finished and inspectable results in each Iteration and ideally present a potentially deliverable system or subsystem in the Team Review at the end of the Iteration .

The Team Scrum Master is a “Servant Manager” and is responsible for encouraging and supporting team work in accordance with the Scrum and P4 rules by helping everyone involved to understand the values and practices.