Backlog Item Types

Specific types:Applications, Market & Variants, Knowledge Gaps & Issues, Samples & Integrations, System Concepts, Architecture & Capabilities, System Requirement & Functions, Team Goal, Team Task
classifiesBacklog Item

“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.

Common Attributes

All backlog entries have the following properties and attributes:

  • A unique short name or other identification (e.g. a number)
  • A description that is as short as possible but meaningful
  • An indication of who the source or author of the backlog entry is. This should make it clear who you can ask if anything is unclear.
  • Acceptance criteria are defined for concretization and delimitation
  • (Optional) At the Portfolio and system level, the respective Product Owners estimate the benefit/value of Applications and Features. For this purpose, benefit values of different applications/features are evaluated relatively against each other, whereby the Product Owners use Planning Poker, for example.
  • To indicate that the team/group in question has performed an analysis and estimation, the estimated effort is noted on the backlog entry

Subdivision of Backlog Items according to Type, Level, Size and Format


In software development, specifying Backlog Items in the format of User Stories has become common practice. Here, a user requirement 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 stakeholders.

Use Cases that can be divided into different scenarios are often used for further elaboration.

Using Text Requirements , individual Components, interfaces and their capabilities, abilities and properties can be described.

Significantly more information can be represented in graphical form. Standard diagrams, as defined in UML and SysML, can describe many structures and processes in such a way that only a few additional explanations are necessary. In order to describe requirements (and solutions) in a compact and “lean” way, UML and SysML diagrams have a clear advantage.


For a Team to work on and finish a Team Backlog Item, it must be small enough to fit into an Iteration. Larger Backlog Items span multiple Iterations and have to be divided into several TBIs. Backlog items on team level are typically Stories in many tools (e.g. Jira or Azure Boards). Larger backlog items are often called Epic, Feature, Initiative or Theme.

Type and level

Each Backlog Item Type is described by its own Definition-of-Done. The DoDs can be different in different Clusters and Teams, but they must be consistent with the Definitions-of-Ready (DoRs = “Definition of Ready”) of the supplying organizational unit or the organizational unit to be supplied.

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 closing all Knowledge Gaps, the 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 experience 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 multiple teams. For this purpose, the Backlog Items 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 “effort 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 ).


Further suitable links:

Events Roles Groups Artifacts
Team Planning

Team Backlog Refinement

Team Review


Cluster Planning

Cluster Backlog Refinement

Cluster Review


Portfolio Planning

Portfolio Refinement

Portfolio Review

Team Product Owner

Team System Engineer

Team Scrum Master


Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master


Portfolio Owner

Portfolio Architect

Organisation Scrum Master

Working Team

Community of Practice


Team Product Owner Group

Team System Engineer Group

Team Scrum Master Group

Cluster Management Circle


Cluster Product Owner Group

Cluster System Engineer Group

Cluster Scrum Master Group

Organisation Management Circle

Team Backlog

Team DoD

Team Improvement Backlog


Cluster Backlog

Cluster DoD

Cluster Improvement Backlog


Portfolio Backlog

Organisation DoD

Organisation Improvement Backlog