Backlog – P4-Dev Framework V2

Backlog (generic)

11. January 20204. May 2020 Oliver Schönfeld

A backlog is an ordered list of everything known that should be carried out by an organizational unit ( team , group, cluster , organization ) and serves as the only source of requests for work by this organizational unit. The product owner is responsible for the backlog, its content, access to it and the order of the entries.
A backlog contains only the currently known entries. During the development steps it develops with the products and services and their application. It is dynamically adjusted to clearly indicate for products and services what it takes to perform their tasks appropriately, to survive in the competition and to offer the greatest possible benefit.
If products and services exist, there are also the associated product, system or application backlogs.

A backlog entry 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 [“Done”].

“The backlog is the only source of work.” This principle does the following important things:

The greatest possible transparency about planned work.
Clear priorities . As in a stack, there is only one priority one. When new entries are inserted, entries below are moved further down.

At all levels in the P4 framework there is exactly one backlog for each organizational unit , ie

a Team Backlog for each team . If a team works on several applications or systems, the Team Backlog contains backlog elements that describe the team’s work in realizing these systems and applications.
for each cluster, a Cluster Backlog . The Cluster Backlog contains all product and system versions, applications and services of the cluster.
for the organization, a Portfolio Backlog . The Portfolio Backlog contains all product and system versions, applications and services of the organization.

Improvement backlog

The one exception to the “one backlog rule” is the organizational unit’s Improvement Backlog. It describes the supply of improvements and is integrated into the work planning by the relevant unit, self-organized. A rule that describes how much work the group spends on improvements (e.g. 10-20%) helps to keep the predictability and predictability of other backlog entries high.

Further suitable links:\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Team Planning

Team Sync

Team Backlog Refinement

Cluster Backlog Refinement

Cluster Review

Cluster Retrospective

Organization retrospective

Team Product Owner

System engineer

Team Scrum Master

Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master

Portfolio Owner

Portfolio Architect

Organization 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

Organization Management Circle

Team Backlog

Team DoD

Team Improvement Backlog

Cluster Backlog

Cluster DoD

Cluster Improvement Backlog

Portfolio Backlog

Organization DoD

Organization Improvement Backlog

Cluster Backlog Refinement

31. December 20194. May 2020 Oliver Schönfeld

Refinement of the Cluster Backlog is viewed as the process of adding details to backlog entries, making estimates, or determining the order of entries in the Cluster Backlog.

Cluster Backlog

29. September 201916. May 2020 Oliver Schönfeld

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.

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Cluster Planning

Cluster Sync

Cluster Backlog Refinement

Cluster Review

Cluster Retrospective

Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master

Team Product Owner Group

Team System Engineer Group

Team Scrum Master Group

Cluster Management Circle

Team Backlog

Usable Knowledge & System Increment

Cluster DoD

Cluster Improvement Backlog

Portfolio Backlog

Team Backlog, Iteration Backlog & Team Kanban

25. September 201916. May 2020 Oliver Schönfeld

Team Backlog

Each Team has exactly one Backlog for its area of responsibility and tasks . It consists in the finest level of granularity of Team Goals for the Team. The Team Product Owner is responsible for and prioritizes the Team Backlog . A large part of the Team Backlog is derived by the Team Product Owner Group and the Team System Engineer Group from the Cluster Backlog , or the System Backlogs by refinement of the entries.

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

Quality measures and improvement of the team process from the team’s Improvement Backlog
Maintenance of the products, systems and Modules responsible for the team
Maintenance and servicing of tools and tools.

In order to make the team’s working speed more predictable, the proportion of backlog entries derived from the Cluster Backlog should be relatively stable over time (e.g. 80% of the team’s capacity).

The Team Backlog is prioritized by the Team Product Owner.

In Team Backlog Refinement , the Team Backlog Items are presented by the Team Product Owner and estimated by the Working Team.

In Team Planning, the Working Team pulls as many Team Backlog Items as the it believes it can handle due to its previous speed of work. This is the Iteration Backlog, which is the plan for the next Iteration.

Work in iterations or in continuous Kanban-mode

Teams have the choice of planning, executing and controlling their work in a rhythm of fixed time units, ie in Iterations, or in a continuous flow, with each Backlog Item individually going through the different states of the team’s work process. This is then made transparent on a Kanban Board.

As a rule, teams that provide a service for other teams (Service Teams) work with Kanban, since new work can be planned and started at any time, and finished work can be delivered at any time.

Iteration Backlog

The Iteration Backlog reflects the work of a Team for a currently running iteration. The planned work, reflected by backlog elements, is pulled into the Iteration Backlog by the Working Team at the start of the Iteration, which is referred to as Pull.

Team Kanban

If the Team works in Kanban-mode, it uses a Team Kanban Board instead of the Iteration Backlog. The first column corresponds to the Team Backlog and the last column to the status “Done”. All other columns are defined by the Team, according to the team’s internal work process.

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Team Planning

Team Sync

Team Backlog Refinement

Team Improvement Backlog

Cluster Backlog

Portfolio Backlog

Product Owner is responsible for Market & Business

25. September 201915. May 2020 Oliver Schönfeld

The P4 framework divides its organizational and management structure of product development into three areas:

Market and Business (see below)
Organization, infrastructure and processes
Technology and Architecture

Market and Business

The Product Owner roles at the various levels bear responsibility for the products and their markets. In doing so, they communicate with the Stakeholders in this area: Users, Customers and the (mostly internal) Sales Department.

The role of the Product Owner

Product, Product Backlog and Product Owner are generic terms in the P4 framework, that is, they only exist in specific forms. The generic artifacts “Product” and “Product Backlog” and the generic role “Product Owner” depend on the level within the organization (Team, Cluster, Organization/Portfolio) or on the specific type of team.

The Product Owner is responsible for maximizing the value of the Product resulting from the results of the Working Team. How this is done can vary greatly between Organizations, Clusters or Teams. The Product Owner is the only person responsible for managing the Product Backlog. The management of the Product Backlog includes:

To clearly formulate the Product Backlog Items (PBI) = Entries of the Product Backlog;
Order the entries in the Product Backlog in such a way that goals and missions can be optimally achieved;
To optimize the value of the work carried out by the Working Team;
Ensure that the Product Backlog is visible, transparent and clear to all Stakeholders and shows what the Team will work on next;
Ensure that the Working Team understands the Product Backlog entries to the extent necessary; and
To review and approve the results of the Working Team.

The Product Owner can carry out the above mentioned work himself or have it carried out by the Working Team or individual members. However, the Product Owner remains accountable at all times.

The Product Owner is an individual person, not a committee. She/he can reflect the wishes of a committee in the Product Backlog, but those who wish to change the priority of a Product Backlog Item must contact the Product Owner. For the Product Owner to be successful, the entire organization must respect her/his decisions. The decisions of the Product Owner are visible in the content and order of the Product Backlog. No one else may assign requirements or work to the Working Team.

Product Owners in the P4 framework

In the P4 framework, the generic role of the Product Owner is concretized on all three levels: It is important that the Product Owners on each level coordinate with each other within the respective POG and derive the priorities for their teams from the superior backlog. See “The overlap principal” for more information.

the Team Product Owner (TPO) as the PO for a single Team. All TPOs of the same team Cluster form the Team Product Owner Group (TPOG) of that Cluster, which is lead and moderated by the Cluster Product Owner.
the Cluster Product Owner as the PO for a Cluster of several Teams. All CPOs form the Cluster Product Owner Group (CPOG) of the Organization, which is lead and moderated by the Portfolio Owner.
the Portfolio Owner as the PO for the entire Organization.

Further suitable articles:

Team Backlog Refinement

21. July 201911. May 2020 Oliver Schönfeld

The Team Backlog Refinement is the process of adding details to the Team Backlog entries, making estimates, and determining the order of the Team Backlog entries. Refinement is a continuous process in which the Team Product Owner and the Working Team together detail the Team Backlog entries. When the Team Backlog is refined, the entries are examined and revised. It should normally not take up more than 10% of the Working Team’s capacity. However, the Team Product Owner can update or have the entries in the Team Backlog updated at any time.

The Team Backlog Refinement mainly serves to prepare the next Team Planning . In this case, the Team Product Owner the Working Team new team Backlog Items before and can appreciate this from the Working Team. If entries are about to begin, the team makes sure that the entries are small enough that they can be dragged into an iteration. (This is a prerequisite for the “pull” and is often also referred to as part of the Definition of Ready (DoR) ). If this is not the case, the team refines the corresponding entry by splitting it into several entries (splitting).

If the team does not work in iterations, but continuously using Kanban, the team agrees on an estimate limit from which it is necessary to split Backlog Items.

Estimation of the implementation effort of backlog entries

Estimates by the entire team are important for two reasons

By estimating together, the entire team 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 estimate 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 elements can be dragged into an iteration, namely by comparing the backlog elements completed in the last iterations (team velocity ).

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

–

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts