Category: Events

Cluster Backlog Refinement

Cluster Review

Cluster Retrospective

Organisation Retrospective

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

Team System Engineer Group

Team Product Owner Group

Team Scrum Master Group

Cluster Management Circle

Cluster Product Owner Group

Cluster System Engineer Group

Cluster Scrum Master Group

Organisation Management Circle

Usable Knowledge & System Increment

Cluster Backlog

Cluster DoD

Cluster Improvement Backlog

Portfolio Backlog

Systems & Applications

System Platforms & Variants

Organisation DoD

Organisation Improvement Backlog

Cycle Daily Meeting (Scrum-of-Scrums)

25. July 201911. May 2020 Oliver Schönfeld

Cluster Sync (scrum-of-scrums)

This event enables multiple Working Teams to communicate with each other in order to coordinate dependencies, disruptions, new findings and decisions, etc. with one another during ongoing work. The teams decide how often this is needed (e.g. daily or weekly).

The team representatives can be the Team System Engineers of the teams. However, other technical representatives of the teams can also be appointed.

The Cluster Sync takes place (usually in a semicircle) in front of the Cluster Kanban Board because the members move the Cluster Backlog Items in the Cluster Sync.

The three questions in Cluster Sync are:

What has my team done since the last Cluster Sync?
What will my team expect to do until the next Cluster Sync?
Where is my team blocked and needs support?

The structure of the Cluster Sync can also be used for the exchange of certain roles or expertise, for example a Cluster Sync of the Team Scrum Masters , the Team Product Owners, the testers, the designers, designers, etc.

Due to the shortness of a maximum of 15 minutes, the Cluster Sync is only suitable for identifying problems, but not for discussing or solving them. The required members can use the time after the Cluster Sync to discuss problems, while the unnecessary members can continue to work.

Visitors in Cluster Sync

Visitors who want to experience the Cluster Sync can participate with the permission of the members. The visitors are in the second row and only listen, unless they are addressed by an active member. Visitors can be:

The Cluster Product Owner
Members of other Clusters
Stakeholders

Extended Cluster Sync

One or more times a week, members of teams that work for several Clusters also come into extended Cluster Sync (similar to Extended Team Sync at team level). They answer their three questions accordingly …

What has my team done and achieved for this Cluster since the last extended Cluster Sync ?
What will my team expect to do for this Cluster until the next extended Cluster Sync ?
Where is my team blocked and needs support?

For the teams that work for several Clusters, it must be ensured that the extended Cluster Syncs of the Clusters take place at different times, so that the members of such teams also have the opportunity to participate. Within the Organization, a coordinated cadence of events enables minimal overlap and an optimal workflow.

Joint Cluster Sync

If two Clusters work very closely together, it may make sense to carry out a joint (joint) Cluster Sync one or more times a week. The representatives of one Cluster listen while the representatives of the other Cluster are doing their Cluster Sync and then the reverse is done.

Further suitable links:\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Cluster Backlog Refinement

Cluster planning

Cluster Review

Cluster Retrospective

Organization Sync

Cluster Product Owner

Cluster System Engineer

Cluster Scrum Master

Team Product Owner Group

Team System Engineer Group

Team Scrum Master Group

Cluster Management Circle

Cluster Backlog

Usable Knowledge & System Increment

Cluster DoD

Cluster Improvement Backlog

Cycle

24. July 201911. May 2020 Oliver Schönfeld

The basic idea of the Iteration as a time-box for the Teams is used at Cluster level by the Cycle as a larger fixed period as a basic rhythm for the Cluster. Frequently, the System versions, products and Applications are also brought to the market in the rhythm of the Cycles. The advantage of a fixed rhythm is its predictability for the teams, managers and stakeholders. In practice, a Cycle length of a quarter of a year has proven itself. There are the following options:

3 four-week iterations + 1 interCycle week
4 three-week iterations + 1 interCycle week
6 two-week iterations + 1 interCycle week

This results in 13 weeks per quarter, which corresponds quite accurately to the actual duration (4 x 13 = 52 weeks).

So, one Cycle consists of:

Portfolio Planning by the Cluster Product Owner Group (CPOG)
Cycle Pre-Planning by the Team Product Owner Group (TPOG)
Cluster Planning (all Teams incl. their POs)
Cycle Post Planning (again TPOG)
3, 4 or 6 Iterations (of 4, 3 or 2 weeks).During the Iterations:
- Team Sync Meetings (Daily Scrums)
- Cluster Sync Meetings (Scrum-of-Scrums)
- Organization Sync (Scrum-of-Scrum-of-Scrums)
- Portfolio Backlog Refinement (by CPOG and CSEG)
- Cluster Backlog Refinements (by TPOGs and TSEGs)
- Team Backlog Refinements (by Working Teams and POs), and
- Team Reviews and Team Retrospectives
Cluster Reviews (TPOGs + TSEGs + Stakeholder)
Portfolio Review (CPOG + CSEG + Stakeholder)
Cluster Retrospectives (all Clusters)
Organization Retrospective

All Cycle meetings are held within the InterCycle Week, starting with the Cluster Review and ending with the Cycle Post-Planning.

\r\n

Further suitable links:

Team Retrospective

22. July 201911. May 2020 Oliver Schönfeld

The Team Retrospective gives the team the opportunity to review themselves and to identify and plan improvements in the way they work for the upcoming iteration . It takes place between the Team Review and the next iteration planning. For a four-week iteration, an upper limit of three hours is set. The meeting is usually shorter for shorter iterations. The Scrum Master ensures that the meeting takes place and that all participants understand its purpose. The Scrum Master ensures that the meeting is constructive and productive. The Scrum Master teaches everyone how to adhere to the time frame (time box). Due to its responsibility for the P4 process, the Scrum Master takes part in the Team Retrospective as an equal member. The Team Retrospective is being held to …

to review how the past iteration was in terms of people, relationships, processes, infrastructure and tools involved;
identify the most important and possible improvements and put them in order; and
create a plan for implementing improvements to the way the team works.

The Scrum Master encourages the team to improve their development processes and practices within the P4 framework to work more effectively and satisfactorily in the upcoming iteration. In each Team Retrospective, the team works out ways to improve result quality by adapting the processes accordingly or by defining-of-done, provided these changes are appropriate and do not conflict with product or company standards. At the end of the Team Retrospective, the team should have identified improvements for the upcoming iteration. The implementation of these improvements in the next iteration is the adaptation effort for self-examination of the team.

In the meantime, there are many methodological approaches and questions for the course of the Team Retrospective, e.g.

Glad, Sad, Mad
Keep, change, puzzled
Good, problems, questions
Start, stop, keep, more, less

There are many more ideas and suggestions under Fun Retrospectives or Retromat .

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Organisation Retrospective

Team Review

Cluster Retrospective

Team Review

22. July 201915. May 2020 Oliver Schönfeld

At the end of each iteration, an Team Review is held in which the Team presents the results to the Stakeholders, with the Team receiving feedback from the Stakeholders and then jointly adjusting the Team Backlog when needed. Together with any changes to Team Backlog during the past Iteration (within the Team Backlog Refinement meetings), these provide the basis for the work on possible new value-added items. The Team Review is an informal meeting, not a status report. The demonstration of the results is intended as a stimulus for feedback and the basis for cooperation. At the end of the Team Review, the Product Owner may present an update on costs and scheduled dates or milestones.

For a four-week Iteration, an upper limit of four hours is used as the timebox for this meeting. For shorter Iterations, a shorter timebox is used. The Team Scrum Master ensures that the event takes place and the participants understand its purpose. The Team Scrum Master teaches all participants to complete the event within the given timebox.

The Team Review includes the following elements:

The participants, consisting of the Team and the Stakeholders invited by the Product Owner.
The Product Owner explains which Team Backlog entries are done.
The Working Team explains what went well during the Iteration, what Impediments and problems arose, and how the Team solved those. If necessary, the Team asks for support from the Stakeholders regarding Impediments
The Working Team presents the “done” work results and answers questions. Work results can be:
- Inspectable Results,
- Usable Knowledge,
- an integrated sample of the System, Platform or Application
The Product Owner presents the current status of the Team Backlog. If required, he provides an updated forecast of delivery dates based on the development progress, e.g. by using a Burn-up-Chart based on the Velocity of the Team
All participants work together on what to do next so that the Product Owner gets valuable input for the upcoming Team Planning.
All participants reviews the schedule, budget, potential properties, and market expectations for the next version of the System or Application (aka Release).

The result of the Team Review is a reworked Team Backlog that matches the participants’ common knowledge and allows the Team to work on the highest value Team Backlog Items in the next Iteration. The Team Backlog can also be extensively redesigned to take advantage of new opportunities.

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Cluster Backlog Refinement

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

Team Sync (Daily Scum)

21. July 201911. May 2020 Oliver Schönfeld

The Team Sync is a daily recurring team event of no more than 15 minutes in which the members of the Working Team synchronize themselves “on eye-level” without reporting to a supervisor. The Team Product Owner only takes part if the team invites him. Even the Team Scrum Master does not have to participate, but is needed especially for not yet mature teams as support.

The Team Sync takes place in front of the team’s task board, usually in a semicircle. Team Members move task cards and TBI cards during this event.

Typically, each team member answers three questions:

What have I done and achieved since the last Daily Meeting? (The team member moves cards to “done” if necessary)
What will I do until the next Daily? (The team member may draw a card from “open” to “in progress”)
Where am I blocked and need help from other Team Members?

To support the process, many teams use an item as a “token” that moves from team member to team member indicating who’s turn it is.

Due to the shortness of the maximum of 15 minutes, the Daily is only suitable for identifying problems, but not discussing them. For discussion of issues, the required team members can do so after the Daily, while the unneeded team members can continue to work.

Visitors in the Daily

Visitors who want to witness the Daily can participate with the permission of the Working Team. The visitors stand in the second row and only listen, unless they are addressed by a team member. Visitors can be:

The Team Product Owner
Members of other teams
Stakeholders

Extended Daily

Once or several times a week, members of the Extended Team come to the Daily, which is referred to as the Extended Daily. They answer their three questions accordingly …

What have I done and achieved for this team since the last Extended Daily?
What will I do to the next Extended Daily for the team?
In which places am I blocked and need help from other team members?

Because members of the Extended Team are by definition working with several teams, it is important to ensure that the extended dailies of these teams take place at different times, so members of the Extended Team have the opportunity to attend. Within the organization, at least within the cluster, a coordinated cadence of events allows for minimal overlap and optimal workflow.

Joint Daily

If two teams work together very closely, it may make sense to have a joint daily or weekly session. One team listens while the other carries out his daily and vice versa.

–

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts

Iteration

21. July 201919. May 2020 Oliver Schönfeld

The Iteration is a fixed length timebox for each of the Teams within a Cluster and corresponds to a constant basic rhythm. Usually, all Teams within the Cluster choose the same Iteration length, especially if they have interdependencies or supply relationships with each other.

Team Planning

21. July 201916. May 2020 Oliver Schönfeld

Iteration Planning (Scrum)

Each Iteration begins with the Team Planning event of the Team. Here, the Team Product Owner presents the Working Team with the current state of the Team Backlog. New entries or changes that are not yet known to the Working Team since the last Team Backlog Refinement are estimated, and if necessary supplemented by Acceptance Criteria and prioritized by the Team Product Owner within the Team Backlog.
The Working Team determines the capacity for the next Iteration by looking at the team’s previous work rate (Team Velocity) and filling the Team Calendar, which shows the time that each Team Member can spend for the Working Team.
The Working Team pulls the number of TBIs into the Iteration Backlog that matches the teams capacity for the next Iteration. Afterwards the Working Team refines the TBIs by creating Tasks, depending on the complexity.

Then, the Working Team starts the Iteration by pulling the first Tasks (or TBIs) from “open” to “in progress”.

Continuous Team Planning (Kanban-mode)

As an alternative to the planning rhythm in Iterations, the planning of work for the team can also be done continuously. This is done during, the Team Backlog Refinements, whereby the work on a Team Backlog Item can be started directly after the analysis and estimation.

–

\r\n

Further suitable links:

Events

Roles

Groups

Artifacts