Integrated and tested features are the results of application teams .
Category: Artefacts
Usable Knowledge & Documented Decisions
Usable Knowledge also represents the first stage of reuse (see principles).
At a higher level, however, this also represents knowledge of the possibilities and limitations of integrated system solutions. To achieve this, partially or fully integrated prototypes and structures are usually necessary, the suitability of which can be verified by appropriate tests.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning
. . |
Team Product Owner
. . |
Working Team
. . |
Inspectable Results
. . |
Team Tasks
Team Tasks are activities and actions that a Working Team plans and carries out in order to achieve Team Goals . Team tasks are part of the Iteration Backlog and are usually only crated and planned in the Team Planning event.
.
\r\n
Further suitable links:
| Events | Roles | Groups | Artifacts |
| Team Planning | Team Product Owner | Working Team
. |
Team Backlog |
Team Goals
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 (Backlog Item Type)
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 . |
Knowledge Gaps
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
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:
- Areas with an accumulation of knowledge gaps require more attention
- The sum of all weighted knowledge gaps results in the (remaining) effort of product development! The weighting or effort estimate is carried out by the implementing, interdisciplinary team, for example using planning poker .
- Knowledge gaps are backlog elements at a high altitude and are broken down into smaller, executable elements by refinement. Knowledge gaps thus represent the content plan of product development.
- Knowledge gaps enable easy risk management because they represent the product-related uncertainties. (Attention: Organizational risk management is also necessary)
- When all red post-its have been changed to green post-its, product development is finished
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, System Architecture & Capabilities
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 . |
System Requirements & Functions
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 . |
Stakeholder Needs
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
- Market & Business : Users, Customers and Sales
- Technology & Architecture : Suppliers, Supply Chain & Production
- Infrastructure & processes : Managers of other areas of the Organization
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:
| Events | Roles | Groups | Artifacts |
| Team Backlog Refinement
. . |
Team Product Owner
. . |
Team Product Owner Group
. |
Team Backlog
. Usable Knowledge & System Increment . |
Quality Attributes & Constraints
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 . |