Teams within the organization are structured in clusters . All future work of the team will be managed in the Team Backlog . Current work is shown in the Iteration Backlog or on a Kanban board . Depending on the type of team, teams create features and applications , modules and system platforms or services . The team’s quality requirements are listed in the team DoD .
Category: Artefacts
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).
Cluster Backlog
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 Product Owner | Team Product Owner Group | Team Backlog
. Usable Knowledge & System Increment . |
Team Backlog, Iteration Backlog & Team Kanban
Team Backlog
Each Team has exactly one Backlog for its area of responsibility and tasks . It consists in the finest level of granularity of Team Goals for the Team. The Team Product Owner is responsible for and prioritizes the Team Backlog . A large part of the Team Backlog is derived by the Team Product Owner Group and the Team System Engineer Group from the Cluster Backlog , or the System Backlogs by refinement of the entries.
The other part of the Team Backlog consists of work and measures that the team carries out to improve the quality of work and results, e.g.
- Quality measures and improvement of the team process from the team’s Improvement Backlog
- Maintenance of the products, systems and Modules responsible for the team
- Maintenance and servicing of tools and tools.
In order to make the team’s working speed more predictable, the proportion of backlog entries derived from the Cluster Backlog should be relatively stable over time (e.g. 80% of the team’s capacity).
The Team Backlog is prioritized by the Team Product Owner.
In Team Backlog Refinement , the Team Backlog Items are presented by the Team Product Owner and estimated by the Working Team.
In Team Planning, the Working Team pulls as many Team Backlog Items as the it believes it can handle due to its previous speed of work. This is the Iteration Backlog, which is the plan for the next Iteration.
Work in iterations or in continuous Kanban-mode
Teams have the choice of planning, executing and controlling their work in a rhythm of fixed time units, ie in Iterations, or in a continuous flow, with each Backlog Item individually going through the different states of the team’s work process. This is then made transparent on a Kanban Board.
As a rule, teams that provide a service for other teams (Service Teams) work with Kanban, since new work can be planned and started at any time, and finished work can be delivered at any time.
Iteration Backlog
The Iteration Backlog reflects the work of a Team for a currently running iteration. The planned work, reflected by backlog elements, is pulled into the Iteration Backlog by the Working Team at the start of the Iteration, which is referred to as Pull.
Team Kanban
If the Team works in Kanban-mode, it uses a Team Kanban Board instead of the Iteration Backlog. The first column corresponds to the Team Backlog and the last column to the status “Done”. All other columns are defined by the Team, according to the team’s internal work process.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning | Team Product Owner | Working Team | Inspectable Results
. . |
Team Improvement Backlog
The Improvement Backlog is the planning and structuring tool of the Scrum Master. There are Improvement Backlogs on all three levels of the P4 framework (Team, Cluster , Organization ).
Each Team that identifies more Improvements than can currently be implemented stores these Improvements in their Team Improvement Backlog, which the Team Scrum Master prioritizes with the Team .
The sum of the Improvements of a Cluster is located in the Cluster Improvement Backlog , which the Cluster Scrum Master prioritizes with the Team Scrum Master Group . The Cluster Improvement Backlog is mostly fed by the teams’ suggestions for Improvement.
The total of an organization’s improvements is in the Organization Improvement Backlog , which the Organization Scrum Master prioritizes with the Cluster Scrum Master Group . The Organization Improvement Backlog is mostly fed from the cluster’s suggestions for Improvement.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning | Team Scrum Master | Working Team | Team Backlog
. . |
Team DoD (Definition of Done)
The Team , the Team Product Owner and the Stakeholders must agree on what it means when a backlog entry or a result is referred to as “done”. Although this can vary significantly from team to team, all Team Members must have a common understanding of when work is done to ensure transparency. This is realized through the definition-of-done of the respective Team , Cluster or Organization .
The DoD is the team’s promise of quality
The DoD also guides the Working Team in deciding how many Team Backlog Items it can pull into the Iteration Backlog during the Team Planning. The purpose of each Iteration is to provide inspectable results, Usable Knowledge, or potentially deliverable Features within a System Increment that correspond to the current Definition-of-done. Working Teams deliver an increment of results, knowledge and / or system functionality in each Iteration . This increment is fully usable, so the Team Product Owner can choose to release it at any time.
If the Definition-of-done for a Team is part of the conventions, standards, or guidelines of the Cluster or Organization, all Teams must use this Cluster DoD as a minimal goal. If “done” for a Team is not part of the convention of the Cluster or Organization, the Team must formulate a Definition-of-done that is appropriate for the Team results. If there are several teams working on the same system, all teams have to create a definition of done together. Each System Increment is additive to all previous increments and has been thoroughly tested to ensure that all increments work together. More mature Teams are expected to adjust their respective Definition-of-done appropriately to ensure stricter criteria for higher quality. New entries in the Definition-of-done can result in work to be done being uncovered in earlier “done” system increments.
Every single result, product or system should have a Definition of done, which is the standard for any work performed on it.
The DoD therefore is the essence of the process descriptions and “standard operation procedures” of a classic organization, but in a strongly condensed form.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning | Team Product Owner | Working Team | Team Backlog
. . |
Integrated System Sample
System-Inkremente sind Teil- oder Vollintegrationen von Systemversionen, die durch interne oder externe Tests, sowie (je nach Grad der Regulierung) durch Nutzer- oder sogar Markttests verifiziert werden.
System-Inkremente werden häufig auf Cluster-Ebene erzeugt d.h. durch die Integration von Teilprodukten der verschiedenen Teams eines Clusters.
Für das System-Inkrement hat P4 die Arten und Definitionen von Mustern aus dem Design Thinking Framework übernommen. Sie definieren damit auch die Reifegrade der Muster (Samples).
Der Reifegrad wird letztlich über die Art und Anzahl der Knowledge-Gaps definiert. Um Knowledge Gaps zu schließen werden Muster aufgebaut
| Prototype | Name | Description |
| B | Base Prototype | for design space exploration |
| C | Critical Function Prototype | Need finding; feasibility; fail early |
| D | Dark Horse Prototype | The alternative; thinking out of the box |
| E | Emergent Prototype | Combining several Functions and ideas; iterative and incremental |
| F | Functional Prototype | Fully functional, but differs in (e.g. form-factor) |
| G | Gap Closing Prototype | Specific to close Knowledge Gaps or prove Hypotheses |
| H | Hindmost Prototype | Closest to series production |
All Prototype can appear as iterating Prototypes, like G1, G2, G3.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Cluster Planning | .
. |
Team Product Owner Group
. |
Inspectable Results
. Usable Knowledge & System Increment . |
Internally provided Services
Internal services are the result of Service Teams.
Versioned Modules
Versioned modules are the results of Module Teams .