Team goals are the most used elements of the Team Backlog . They describe the goals and (interim) results of the team regarding a Feature, a Module or a Service , depending on the type and responsibility of the Team .
Generally speaking, the Working Team turns Team Goals into Inspectable Results.
Samples & Integrations represent all work that is required to develop, build and test prototype samples (whether virtual or physical). These Samples can be concepts, simulations, prototypical partial assemblies, virtual prototypes, rapid prototypes, up to pre-series samples, which may be tested in user studies. Samples & Integrations are created to close Knowledge Gaps through learning. For this reason, the samples are always deliberately planned in such a way that they can be generated and tested with minimal expenditure of time, so that Knowledge Gaps can be converted into Usable Knowledge. Samples that do not close any Knowledge Gaps will not be built!
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Cluster Planning | .
. |
Team Product Owner Group
. |
Inspectable Results
. Usable Knowledge & System Increment . |
Today, product developments very rarely start “on the green field”. Depending on the competence of the organization, certain things are already known and can be reused. The P4 framework describes all unknown things as “knowledge gaps”. The idea behind this is that product development can be considered complete once all knowledge gaps have been turned into Usable Knowledge and documented Decisions .
(Note for process experts: Knowledge gaps represent a new concept. They combine the idea of ”hypotheses” from the Lean Startup with the “knowledge-based” development of LPPD, the risk management of classic processes and the risk-based approach of the Unified Process.)
The gap map shows, against the background of a suitable representation of the “system under development” and its context, the associated knowledge gap as a red post-it. Green Post-its visualize elements and interfaces that have not been changed or that have already been decided in the course of the project based on what has been learned .
The following things can be read on the gap map:
Due to the simplicity and clarity, a gap map is an excellent means of communication between the team and the management.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Cluster Planning | .
. |
Team Product Owner Group
. |
Inspectable Results
. Usable Knowledge & System Increment . |
System concepts describe possible solutions for system and product variants (applications = feature sets) and their requirements . System concepts implement the System Requirements within the restrictions (contraints) and balance the quality requirements (Quality Attributes)out. The P4 framework explicitly provides several System Concepts as solution options for the implementation of System Requirements in the system backlog. This means that several solutions to a problem may be identified and developed further (divergence in the solution space). The goal of product development is to only develop so many different System Concepts (in parallel or in succession) until some concepts are disqualified and ideally a clear favorite emerges. Depending on the degree of innovation in the development, this can be a very large number of concepts at first, or new concepts may even arise during product development.
In today’s product development, the concept of reuse and thinking in building blocks, product lines and platforms has become very popular. This is reflected in the P4 framework by the architectural aspect of this level. The requirements for the platform are contained in the ” Quality Attributes & Constraints ” (eg modularity, reusability, markets and applications).
The responsibility of the Cluster System Engineer is also the division of so-called capabilities into Modules, which are described as services in more complex systems. The basic idea is that certain Modules provide skills that can be used by other Modules.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Cluster Planning | .
. |
Team Product Owner Group
. |
Inspectable Results
. Usable Knowledge & System Increment . |
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 . |
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 different stakeholders (= interest groups) can be identified for each product or system.
The P4 framework distinguishes three groups of stakeholders, which are assigned to the three areas
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:
| Events | Roles | Groups | Artifacts |
| Team Backlog Refinement
. . |
Team Product Owner
. . |
Team Product Owner Group
. |
Team Backlog
. Usable Knowledge & System Increment . |
Quality attributes are non-functional requirements that more or less restrict the Functions and features of a system. These are mostly how questions, i.e. how fast, how big, how heavy, how expensive, how long-lasting, how robust, how safe? These requirements often have to be balanced against each other. For this purpose, minimum achievable and desired values are often given. P4 also requires that these are put in a clear order (in the form of a QA/C backlog) so that decisions can be made more easily in the event of conflicts.
Constraints are restrictions that must be observed. They correspond to Quality Attributes that have only a minimum value. The sources of Constraints are often regulatory or legal requirements, as well as norms and standards. Due to their severely restrictive effect, the Constraints are usually the top priority in the QA/C backlog.
(see also FURPS and ISO / IEC 9126 )
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Cluster Planning | .
. |
Team Product Owner Group
. |
Inspectable Results
. Usable Knowledge & System Increment . |
“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.
All backlog entries have the following properties and attributes:
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.
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.
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:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Team Product Owner
. . |
Working Team
. . |
Team Backlog
. . |