Requirements Management – P4-Dev Framework V2

Refinement of the Portfolio Backlog is the process of adding details to backlog entries, making estimates, splitting backlog entries, or changing the order of entries in the Portfolio Backlog. Refinement is a continuous process in which the Portfolio Owner and the Cluster System Engineer Group (CSEG) jointly detail the Portfolio Backlog entries. The entries are examined and revised as the Portfolio Backlog is refined. However, the Portfolio Owner can update or have the entries in the Portfolio Backlog updated at any time.

The Portfolio Backlog refinement is mainly used to prepare the next Portfolio Planning . The Portfolio Owner of the Cluster System Engineer Group (CSEG) presents new backlog entries and has them estimated. This is a prerequisite for the “pull” of the CSEG and is often referred to as definition-of-ready . In the case of unclear but highly prioritized backlog entries, the CSEG clarifies the System Requirements , possible System Concepts and capabilities . This can be worked out as a group or a corresponding backlog entry can be created as an order for one of the Clusters.

Estimation of the effort required to implement backlog entries

Estimates by the entire Cluster System Engineer Group are important for two reasons:

By jointly estimating, the CSEG analyzes the respective backlog entry from different perspectives and enriches it with information such as acceptance criteria and boundary conditions. The first ideas for implementation are also generated.
The result of the estimation is a number with which individual backlog elements can be evaluated, for example for prioritization. In addition, it is now easy to calculate how many backlog elements can be dragged into a cycle, namely by comparing the backlog elements completed in the last cycles ( organization velocity ).

The team uses the Planning-Poker ® methodology to estimate the effort .

Further suitable links:\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Team Backlog Refinement .

Cluster Backlog Refinement

Portfolio Planning

Organization Sync

Portfolio Review

Organization retrospective

Portfolio Owner

Portfolio Architect

Organization Scrum Master

Cluster Product Owner Group

Cluster System Engineer Group

Cluster Scrum Master Group

Organization Management Circle

Portfolio Backlog

Systems & Applications

System Platforms & Variants

Organization DoD

Organization Improvement Backlog

Each Cluster has exactly one Backlog for its area of responsibility and tasks , the Cluster Backlog. In its simplest form, it consists of elements of just one System development that all Teams in the Cluster are working on. In this case, the Cluster Backlog can be referred to as the System Backlog. If the Cluster is responsible for several systems, all backlog elements of the different systems are contained within the Cluster Backlog.

The Team Product Owner Group is responsible for and prioritizes the Cluster Backlog .The Team Product Owner Group consists of all Team Product Owners of the Cluster and the Cluster Product Owners. A large part of the Cluster Backlog is derived by the Cluster Product Owner Group and the Cluster System Engineer Group from the Portfolio Backlog by refinement in the Portfolio Backlog Refinements .

The other part of the Cluster Backlog consists of work and measures that the Cluster carries out to improve the quality of work and results, e.g.

Quality measures and improvement of the Cluster process (ie the Cluster Improvement Backlog)
Maintenance of the products, systems and Modules responsible for the cluster
Maintenance and servicing of tools and tools.

In order to make the working speed of the Clusters more predictable, the proportion of backlog items derived from the Portfolio Backlog should be relatively stable over time.

The Cluster Backlog is prioritized by the Cluster Product Owner.

In the Cluster Backlog Refinement , the Cluster Backlog Items are presented by the Cluster Product Owner and estimated by the Team System Engineer Group (TSEG). Since this consists of members of all Teams in the Cluster, this group is best suited for this.

In the Cluster Planning, the TSEG pulls as many Cluster Backlog Items into the Cycle as the TSEG believes due to the previous working speed of the cluster. This is the Cycle Backlog that represents the plan for the next cycle.

Work in cycles or in continuous Kanban mode

Clusters have the choice of planning, executing and controlling their work in a rhythm of fixed time units, ie in Cycles, or in a continuous flow, with each Backlog item individually going through the different states of the work process of the Cluster. This is made transparent on a Kanban board.

A Cluster chooses between Cycle-mode and Kanban-mode, depending on the product and how planning and approval are carried out. With a regular release rhythm, for example every three months, work in Cycles is recommended.

Cycle Backlog

The Cycle Backlog reflects the work of a Cluster for a currently running Cycle . The estimated work, ie backlog elements, is pulled into the Cycle Backlog by the TSEG at the beginning of the Cycle (pull) and thus scheduled for the next Cycle (forecast).

Cluster Kanban

If the Cluster works in Kanban-mode, it uses a Cluster Kanban Board instead of the Cycle Backlog. The first column corresponds to the Cluster Backlog and the last column to the status “Done”. All other columns are defined by the Team Scrum Master Group of the cluster, according to the internal Cluster work process.