Backlog Item Types

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

Similarities

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 in question has performed an analysis and assessment, the estimated effort is noted on the backlog entry

Subdivision of Backlog Items according to type, level, size and format

Formats

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.

Size

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.

Type and level

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