Team Calendar

The Team Calendar shows the availability of the Nucleus and Extended Team members for an Iteration. Each Team Member enters planned absences in order to determine the gross capacity of the team before (or at the latest in) the Iteration Planning. The gros capacity is used to adjust the  work forecast by relating it to the team’s Velocity, which significantly improves predictability.

Example of a Team Calendar

The concept of a calendar to determine the gros capacity can also be used for Clusters and cycles, ideally based on public holidays and the longer-term vacation planning of the team members .

If the team does not work with iterations but continuously by means of Kanban, the team calendar is maintained for several weeks in advance on a weekly basis.

Definition of Ready (DoR)

The definition-of-ready (DoR) is a list that defines which criteria certain artifacts must meet before defined actions start in the organizational unit (Team, Group, Cluster). It is an agreement to set clear quality criteria for artifacts. In the P4 framework, a team shouldn’t pull unestimated Backlog Items into an Iteration. DoRs exist at all levels and may differ between organizational units.

Read More

Backlog (generic)

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

Team Review

Team Retrospective

.

Cluster planning

Cluster Sync

Cluster Backlog Refinement

Cluster Review

Cluster Retrospective

.

Portfolio Planning

Organization Sync

Portfolio refinement

Portfolio Review

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

Organisation Improvement Backlog

The Improvement Backlog is the planning and structuring tool of the Scrum Master. There are Improvement Backlogs on all three levels of the P4 framework (Team, Cluster, Organization).

Each Team that identifies more improvements than can currently be implemented stores these improvements in their Team Improvement Backlog, which the Team Scrum Master prioritizes with the Team .

The sum of the improvements of a Cluster is located in the Cluster Improvement Backlog , which the Cluster Scrum Master prioritizes with the Team Scrum Master Group . The Cluster Improvement Backlog is mostly fed by the Teams’ suggestions for improvement.

The total of an Organization’s improvements is in the Organization Improvement Backlog, which the Organization Scrum Master prioritizes with the Cluster Scrum Master Group . The Organization Improvement Backlog is mostly fed from the Cluster’s suggestions for improvement.

.

 

\r\n


Further suitable links:

Events Roles Groups Artifacts
Portfolio Planning

Organisation Sync

Portfolio Refinement

Portfolio Review

Organisation Retrospective

Portfolio Owner

Portfolio Architect

Organisation Scrum Master

Cluster Product Owner Group

Cluster System Engineer Group

Cluster Scrum Master Group

Organisation Management Circle

Team Improvement Backlog

.

Cluster Improvement Backlog

.

Portfolio Backlog

Systems & Applications

System Platforms & Variants

Organisation DoD

Cluster Improvement Backlog

The Improvement Backlog is the planning and structuring tool of the Scrum Master. There are Improvement Backlogs on all three levels of the P4 framework (Team, Cluster, Organization).

Each Team that identifies more improvements than can currently be implemented stores these improvements in their Team Improvement Backlog , which the  Team Scrum Master prioritizes with the Team .

The sum of the improvements of a Cluster is located in the Cluster Improvement Backlog, which the Cluster Scrum Master prioritizes with the Team Scrum Master Group . The Cluster Improvement Backlog is mostly fed by the Teams’ suggestions for improvement.

The total of an Organization’s improvements is in the Organization Improvement backlog , which the Organization Scrum Master prioritizes with the Cluster Scrum Master Group . The Organization Improvement Backlog is mostly fed from the cluster’s suggestions for improvement.

.

 

\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 Improvement Backlog

.

Cluster Backlog

Usable Knowledge & System Increment

Cluster DoD

.

Organisation Improvement Backlog

Products, Applications and Market Variants

The Portfolio Backlog at the Organizational level, the top level of all Backlogs, contains Systems, Products and Application variants, as well as product variants for special markets. Each of these product variants is described by a set of System Requirements (feature set). In this way, the product variants can be estimated against each other with regard to both the benefits and the effort to be invested . The so-called Upswing Gravity Field is used for this in the P4 framework .

The Portfolio level is not necessary for organizations that create only one product.

 

\r\n


Further suitable links:

Events Roles Groups Artifacts
Portfolio Planning

Organisation Sync

Portfolio Refinement

Portfolio Review

Organisation Retrospective

Portfolio Owner

Portfolio Architect

Organisation Scrum Master

Cluster Product Owner Group

Cluster System Engineer Group

Cluster Scrum Master Group

Organisation Management Circle

.

Portfolio Backlog

Systems & Applications

Organisation DoD

 

 

Cluster DoD

The Teams of the Cluster , the Team System Engineer Group , the Team Product Owner Group and the Stakeholders must agree on what it means when a Backlog Item or a result is marked as “done”. Although this can vary significantly from Cluster to cluster, everyone must have a common understanding of when work is done to ensure transparency. This is done through the Definition-of-done of the respective Cluster.

The Cluster DoD is the quality promise of the Cluster

The DoD also guides the Team System Engineer Group in deciding how many Cluster Backlog Items it can pull into the Cycle Backlog during Cluster Planning. The purpose of each Cycle is to provide Inspectable Results, Usable Knowledge, or potentially deliverable functionality within a System Increment that correspond to the current Definition-of-done. Clusters provide an increment of results, knowledge and / or system functionality in each Cycle. This increment is fully usable so that the Cluster Product Owner can choose to release it at any time.

If the Definition-of-done for a product is part of an organization’s conventions, standards, or guidelines, all Clusters must follow them as a minimum goal. If “Done” for a result is not part of the organization’s convention, the Cluster (ie the TSEG) must formulate a definition-of-done that is appropriate for the product. If there are several Clusters working on the same system, all Clusters must create a definition of done together. Each system increment is additive to all previous increments and has been thoroughly tested to ensure that all increments work together. More mature Clusters are expected to expand their respective definition-of-done appropriately to ensure stricter criteria for higher quality. New entries in the definition-of-done can cause

Every single result, product or system should have a definition of done, which is the standard for any work performed on it.

The DoD therefore is the essence of the process descriptions and “standard operation procedures” of a classic organization, but in a strongly condensed form.

.

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

.

Cluster Backlog

Usable Knowledge & System Increment

Cluster Improvement Backlog

.

Organisation DoD