Category: Team Level

Team Calendar

Oliver Schönfeld

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.

Team Backlog, Iteration Backlog & Team Kanban

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 Review

Team Retrospective

 Team Product Owner

Team System Engineer

Team Scrum Master

 Working Team Inspectable Results

Team DoD

Team Improvement Backlog

.

Cluster Backlog

.

Portfolio Backlog

 

Team Improvement Backlog

Oliver Schönfeld

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

Team Retrospective

 Team Scrum Master Working Team Team Backlog

Inspectable Results

Team DoD

.

Cluster Improvement Backlog

.

Organisation Improvement Backlog

 

Team Product Owner

Oliver Schönfeld

The Team Product Owner prioritizes the Team Backlog and approves the results of the Working Team. The Team Backlog can contain several product developments or parts of them. (A general description of the Product Owner role can be found here …)

Depending on the type and area of responsibility of the Team (“team flavor”), the results of the teams vary greatly. Therefore, the Team Product Owners in P4 can have different names:

Service-Owner

Service owners are the technical leaders of teams who are responsible for an expertise or competence. Often members of such Service Teams are too specialized or too few to be able to work in interdisciplinary teams on a permanent basis. Another reason for a Service Team is that it operates a special infrastructure, e.g. a laboratory. These teams are often a kind of internal service provider within the organization and are usually visited or invited by other teams.

The Service Owner is responsible for prioritizing the service orders of her/his team. In the simplest case, the team uses a Kanban board with a first-come-first-serve principle (FIFO). However, the Service Owner can also divide the services offered by the team into service classes, for example, by means of different service level agreements at different costs.

To achieve an optimal flow of system development, the Service Owner adopts the priorities from the Portfolio Backlog or the Cluster Backlog in the simplest case. In addition, the Service Owner coordinates regularly with the other Team Product Owners within the Team Product Owner Group (TPOG).

Module-Owner

In the development of complex systems there will often be subsystems or Modules to make complexity more manageable (modules encapsulate complexity) or to enable the reuse of Modules and Components by means of a platform or modular concept.

A Module Owner is therefore the manager who ensures that the appropriate Modules are available for application and system development. On the other hand, She/he is responsible for ensuring that the Modules are reusable. Stable interfaces for a platform or modular system are particularly important.

Feature Owner and Application Owner

Feature Owners are the Team Product Owners of interdisciplinary teams who develop and are responsible for one or more Functions (Features) of a system variant (=applications) and make them available to users. Together with the other feature owners and the application owner, the feature owner is responsible for improving the customer value of his Application Team’s product. The application owner is the direct interface to the users of the application to decide on requirements and changes to the application.

Application Owners are the Team Product Owners of the interdisciplinary teams that develop and are responsible for marketable System Variants (=Applications) and make them available to users. The Application Owner is responsible for improving the customer value of the Application Team’s products. The Application Owner is the direct interface to the users and Stakeholders of the application to decide on requirements and changes.

The Application Team with the Application Owner are the internal clients of the Module and Service Teams. Application Teams integrate the Modules provided by the Module Teams with the help of the services provided by the Service Teams.

 

\r\n

Further suitable links:

Events Roles Groups Artifacts
Iteration Planning

Team Sync

Team Backlog Refinement

Team Review

Team Retrospective

 Team System Engineer

Team Scrum Master

.

Cluster Product Owner

.

Portfolio Owner

 Working Team

.

Team Product Owner Group

 Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog

Team System Engineer (TSE)

Oliver Schönfeld

The Team System Engineer represents the technical expertise and responsibility of his Team in the Team System Engineer Group of the Cluster . If the team does not agree on any other regulation, he also represents the Team in the Cluster Syncs (scrum-of-scrums) . For this, he should have the broadest possible knowledge of the topics within his Team. This can vary significantly depending on the type and area of ​​responsibility.

If a Service Team represents certain expertise (e.g. EMC or acoustics), the Team System Engineer is usually the most experienced of the team.

Within a Module Team , the Team System Engineer knows the modules of his team, their strengths and weaknesses, and their areas of application.

Within an Application Team , the Team System Engineer knows best the technical possibilities for implementing the applications that his team is responsible for.

Within the Working Team, the Team System Engineer has the role of moderating and driving technical decisions and, when in doubt, making them. He is not above the Working Team, but is the “first among equals” (Primus inter paris).

.

\r\n

Further suitable links:

Events Roles Groups Artifacts
Team Planning

Team Sync

Team Backlog Refinement

Team Review

Team Retrospective

 Team Product Owner

Team Scrum Master

.

Cluster System Engineer

.

Portfolio Architect

 Working Team

Community of Practice

 Team Backlog

Inspectable Results

Team DoD

Team Improvement Backlog

 

Team DoD (Definition of Done)

Oliver Schönfeld

The Team , the Team Product Owner and the Stakeholders must agree on what it means when a backlog entry or a result is referred to as “done”. Although this can vary significantly from team to team, all Team Members must have a common understanding of when work is done to ensure transparency. This is realized through the definition-of-done of the respective Team , Cluster or Organization .

The DoD is the team’s promise of quality

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

If the Definition-of-done for a Team is part of the conventions, standards, or guidelines of the Cluster or Organization, all Teams must use this Cluster DoD as a minimal goal. If “done” for a Team is not part of the convention of the Cluster or Organization, the Team must formulate a Definition-of-done that is appropriate for the Team results. If there are several teams working on the same system, all teams have to 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 Teams are expected to adjust their respective Definition-of-done appropriately to ensure stricter criteria for higher quality. New entries in the Definition-of-done can result in work to be done being uncovered in earlier “done” system increments. 

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

Team Sync

Team Backlog Refinement

Team Review

Team Retrospective

 Team Product Owner

Team System Engineer

Team Scrum Master

 Working Team

Community of Practice

 Team Backlog

Inspectable Results

Team Improvement Backlog

.

Cluster DoD

.

Organisation DoD