Artefacts

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…

Stakeholder Story

In the P4 framework, the Stakeholder Story represents the extension of the User Story to all stakeholders. It can and should be used to formulate the needs and requirements of all Stakeholders for the product. These are much more than just the users, especially in the environment of physical product development. Stakeholder Stories can also…

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…

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 mostly created by the Application teams of the Cluster i.e. by integrating partial results of the different teams of a cluster (module and platform…

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…

Picture by FreepikTAPIR Decision Guideline

The “TAPIR Decision Guideline” is an effective approach to find and make decisions in a group and to agree on them. Triage & Time: A quick assessment about criticality and decision time. Questions: Regarding the time, how deep should the analysis be? Who, what and how much time is needed? Analysis: Depending on the available…

Team Backlog Item (TBI)

Team Backlog Items (TBI) are the individual elements (Backlog Items) of a Team Backlog and describe work for a single Team. The size of  a TBI is initially not limited. It must be small enough in size or devided (refined) into several individual items that can be done in one Iteration, before it can be pulled…

Team Backlog

Team Backlog Each Team has exactly one Backlog for its area of ​​responsibility and tasks . Its elements (Team Backlog Items) consist in the finest level of granularity of Team Goals. The Team Product Owner is  responsible for and prioritizes the Team Backlog. A large part of the Team Backlog is derived by the Team…

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…

Team Improvement Backlog

The Improvement Backlog describes the supply of improvements and is integrated into the work planning by the relevant group, self-organized. A rule that describes how much work the group spends on improvements (e.g. 10-20%) helps to keep the predictability of other Backlog Items high. The Improvement Backlog is the planning and structuring tool of the…