Backlog Item (generic)

Specific types:Cluster Backlog Item, Improvement Backlog Item, Portfolio Backlog Item, Team Backlog Item
is part ofBacklog
consists ofAcceptance Criteria, Description, Effort Estimation, ID, Info Source, Value Estimation
is constrainted byAcceptance Criteria, Defintion of Done
instanciatesBacklog Item Type
is accepted byProduct Owner (generic)

A Backlog Item contains as attributes a description, an effort estimate, as well as Acceptance Criteria and Test Descriptions, which prove the completeness and describe when it is done.

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/Cluster level, the respective Product Owners estimate the benefit/business value of Applications and Features. For this purpose, benefit values of different applications/features are evaluated relatively against each other by the Product Owners (in most cases by using Planning Poker).
  • To indicate that the team/group in question has performed an analysis and estimation, the estimated effort is noted on the Backlog Item
  • The rank of the Backlog Item within the Backlog is simply its position within the Backlog. If the benefit value and the effort has been estimated, the rough priority can be calculated (by dividing benefit-value by effort)

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


In general, Backlog Items describe work elements for the product development. All Backlog Items of the same type describe the sum of the work for product development in a different dimension. Thus, a product can be described as the sum of its functions, as the sum of the Knowledge Gaps to be clarified and decided, as the sum of the samples and prototypes to be built, or as the sum of all activities of all teams involved. Describing all activities from the beginning corresponds to classical planning and is not supported in the P4 framework. Through the principle of rolling-wave planning, or just-in-time planning, more distant work elements are broken down iteratively and as late as possible, since we expect frequent changes. More about this here.


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.

Size & Level

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.

For a Cluster to work on and finish a Cluster Backlog Item, it must be small enough to fit into an Cycle. Larger Backlog Items span multiple Cycles and have to be divided into several CBIs.