Organisations-Improvement-Backlog

Das Improvement-Backlog ist das Planungs- und Strukturierungswerkzeug des Scrum-Masters. Improvement-Backlogs gibt es auf allen drei Ebenen des P4-Frameworks (Team, Cluster, Organisation).

Jedes Team, das mehr Verbesserungen identifiziert, als momentan umsetzbar sind, legt diese Verbesserungen in ihrem Team-Improvement-Backlog ab, das der Team-Scrum-Master mit dem Team priorisiert.

Die Summe der Verbesserungen eines Clusters befindet sich im Cluster-Improvement-Backlog, das der Cluster-Scrum-Master mit der Team-Scrum-Master-Gruppe priorisiert. Das Cluster-Improvement-Backlog wird meist aus den Verbesserungsvorschlägen der Teams gespeist.

Die Summe der Verbesserungen einer Organisation befindet sich im Organisation-Improvement-Backlog, das der Organisation-Scrum-Master mit der Cluster-Scrum-Master-Gruppe priorisiert. Das Organisations-Improvement-Backlog wird meist aus den Verbesserungsvorschlägen der Cluster gespeist.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Portfolio-Planung

Organisations-Sync

Portfolio-Refinement

Portfolio-Review

Organisations-Retrospektive

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Team-Improvement-Backlog

.

Cluster-Improvement-Backlog

.

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Cluster-Improvement-Backlog

Das Improvement-Backlog ist das Planungs- und Strukturierungswerkzeug des Scrum-Masters. Improvement-Backlogs gibt es auf allen drei Ebenen des P4-Frameworks (Team, Cluster, Organisation).

Jedes Team, das mehr Verbesserungen identifiziert, als momentan umsetzbar sind, legt diese Verbesserungen in ihrem Team-Improvement-Backlog ab, das der Team-Scrum-Master mit dem Team priorisiert.

Die Summe der Verbesserungen eines Clusters befindet sich im Cluster-Improvement-Backlog, das der Cluster-Scrum-Master mit der Team-Scrum-Master-Gruppe priorisiert. Das Cluster-Improvement-Backlog wird meist aus den Verbesserungsvorschlägen der Teams gespeist.

Die Summe der Verbesserungen einer Organisation befindet sich im Organisation-Improvement-Backlog, das der Organisation-Scrum-Master mit der Cluster-Scrum-Master-Gruppe priorisiert. Das Organisations-Improvement-Backlog wird meist aus den Verbesserungsvorschlägen der Cluster gespeist.

.


Passende und weiterführende Artikel:\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Team-Improvement-Backlog

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

.

Organisations-Improvement-Backlog

Cluster-Backlog, Cycle-Backlog und Cluster-Kanban

Jeder Cluster hat für seinen Verantwortungsbereich und seine Aufgaben genau ein Backlog, das Cluster-Backlog. Es besteht in der einfachsten Form aus Elementen nur eines Systems, an dem alle Teams des Clusters arbeiten. In diesem Fall kann das Cluster-Backlog als System-Backlog bezeichnet werden. Werden von dem Cluster mehrere Systeme verantwortet und bearbeitet, befinden sich alle Backlog-Elemente der verschiedenen Systeme im Cluster-Backlog.

Das Cluster-Backlog wird von der Team-Product-Owner-Gruppe verantwortet und priorisiert. Die Team-Product-Owner-Gruppe besteht aus den Product-Ownern der Teams und dem Cluster-Product-Owner des Clusters. Ein großer Teil des Cluster-Backlogs wird durch die Cluster-Product-Owner-Gruppe und die Cluster-System-Engineer-Gruppe aus dem Portfolio-Backlog durch Verfeinerung im Portfolio-Backlog-Refinement abgeleitet.

Der andere Teil des Cluster-Backlogs besteht aus Arbeiten und Maßnahmen, die der Cluster zur Verbesserung der Arbeits- und Ergebnisqualität durchführt, z.B.

  • Qualitätsmaßnahmen und Verbesserung des Cluster-Prozesses
  • Pflege der vom Cluster verantworteten Produkte, Systeme und Module
  • Wartung und Instandhaltung von Werkzeugen und Tools.

Um die Arbeitsgeschwindigkeit der Cluster vorhersagbarer zu machen, sollte der Anteil an Backlog-Einträgen, die aus dem Portfolio-Backlog abgeleitet werden, über die Zeit relativ stabil sein.

Das Cluster-Backlog wird vom Cluster-Product-Owner priorisiert.

Im Cluster-Backlog-Refinement werden die Cluster-Backlog-Items vom Cluster-Product-Owner vorgestellt und von der Team-System-Engineer-Gruppe (TSEG) geschätzt. Da diese aus Mitgliedern aller Teams des Clusters besteht, ist diese Gruppe am besten dazu geeignet.

Im Cluster-Planning zieht die TSEG so viele Cluster-Backlog-Einträge, wie sich die TSEG durch die bisherige Arbeitsgeschwindigkeit des Clusters zutraut. Dies ist dann das Cycle-Backlog, das den Plan für den nächsten Cycle darstellt.

Arbeit in Cycles oder im kontinuierlichen Kanban-Modus

Cluster haben die Wahl, die Planung, Durchführung und Kontrolle ihrer Arbeit in einem Rhythmus von festen Zeiteinheiten, d.h. in Cycles durchzuführen, oder in einem kontinuierlichen Fluss, wobei jedes Backlog-Element einzeln die verschiedene Zustände des Arbeitsprozesses des Clusters durchläuft. Dies wird dann auf einem Kanban-Board transparent gemacht.

Ein Cluster wählt zwischen Cycle- und Kanban-Modus, je nach Produkt und wie Planung und Freigaben erfolgen. Bei einem regelmäßigen Freigabe-Rhythmus, z.B. alle drei Monate, bietet sich die Arbeit in Cycles an.

Cycle-Backlog

Das Cycle-Backlog reflektiert die Arbeit eines Clusters für einen gerade laufenden Cycle. Die abgeschätzten Arbeiten, d.h. Backlog-Elemente, werden dabei zu Beginn des Cycles von der TSEG in das Cycle-Backlog gezogen (Pull) und damit für den nächsten Cycle eingeplant (Forecast).

Cluster-Kanban

Arbeitet der Cluster im Kanban-Modus verwendet er statt des Cycle-Backlogs ein Cluster-Kanban-Board. Hierbei entspricht die erste Spalte dem Cluster-Backlog und die letzte Spalte dem Zustand „Erledigt“ oder „Done“. Alle anderen Spalten werden vom der Team-Scrum-Master-Gruppe des Clusters definiert, entsprechend des Cluster-internen Arbeitsprozesses..

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

Team-Backlog

.

Nutzbares-Wissen & System-Inkrement

Cluster-DoD

Cluster-Improvement-Backlog

.

Portfolio-Backlog

Team-Backlog, Iteration-Backlog und Team-Kanban

Team-Backlog

Jedes Team hat für seinen Verantwortungsbereich und seine Aufgaben genau ein Backlog. Es besteht in der feinsten Granularitätsstufe aus Team-Zielen für das Team. Das Team-Backlog wird vom Team-Product-Owner verantwortet und priorisiert. Ein großer Teil des Team-Backlogs wird durch die Team-Product-Owner-Gruppe und die Team-System-Engineer-Gruppe aus dem Cluster-Backlog, bzw. den System-Backlogs durch Verfeinerung (Refinement) der Einträge abgeleitet.

Der andere Teil des Team-Backlogs besteht aus Arbeiten und Maßnahmen, die das Team zur Verbesserung der Arbeits- und Ergebnisqualität durchführt, z.B.

  • Qualitätsmaßnahmen und Verbesserung des Team-Prozesses aus dem Improvement-Backlog des Teams
  • Pflege der vom Team verantworteten Produkte, Systeme und Module
  • Wartung und Instandhaltung von Werkzeugen und Tools.

Um die Arbeitsgeschwindigkeit des Teams vorhersagbarer zu machen, sollte der Anteil an Backlog-Einträgen, die aus dem Cluster-Backlog abgeleitet werden, über die Zeit relativ stabil sein (z.B. 80% der Kapazität des Teams).

Das Team-Backlog wird vom Team-Product-Owner priorisiert.

Im Team-Backlog-Refinement werden die Team-Backlog-Items vom Team-Product-Owner vorgestellt und vom Working-Team geschätzt.

In der Iterationsplanung zieht das Working-Team so viele Team-Backlog-Einträge, wie es das Team sich durch seine bisherige Arbeitsgeschwindigkeit zutraut. Dies ist dann das Iteration-Backlog, das den Plan für die nächste Iteration darstellt.

Arbeit in Iterationen oder im kontinuierlichen Kanban-Modus

Teams haben die Wahl, die Planung, Durchführung und Kontrolle ihrer Arbeit in einem Rhythmus von festen Zeiteinheiten, d.h. in Iterationen durchzuführen, oder in einem kontinuierlichen Fluss, wobei jedes Backlog-Element einzeln die verschiedene Zustände des Arbeitsprozesses des Teams durchläuft. Dies wird dann auf einem Kanban-Board transparent gemacht.

In der Regel arbeiten Teams, die ein Dienstleistung für andere Teams erbringen (Service-Teams) mit Kanban, da hier jederzeit neue Arbeiten geplant und begonnen werden können, sowie jederzeit fertiggestellte Arbeit ausgeliefert werden kann.

Iteration-Backlog

Das Iteration-Backlog reflektiert die Arbeit eines Teams für eine gerade laufende Iteration. Die geplanten Arbeiten, reflektiert durch Backlog-Elemente, werden dabei zu Beginn der Iteration vom Working-Team in das Iteration-Backlog gezogen, was als Pull bezeichnet wird.

Team-Kanban

Arbeitet das Team im Kanban-Modus verwendet es statt des Iteration-Backlogs ein Team-Kanban-Board. Hierbei entspricht die erste Spalte dem Team-Backlog und die letzte Spalte dem Zustand „Erledigt“ oder „Done“. Alle anderen Spalten werden vom Team definiert, entsprechend des team-internen Arbeitsprozesses.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Working-Team Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

.

Cluster-Backlog

.

Portfolio-Backlog

Team-Improvement-Backlog

Das Improvement-Backlog ist das Planungs- und Strukturierungswerkzeug des Scrum-Masters. Improvement-Backlogs gibt es auf allen drei Ebenen des P4-Frameworks (Team, Cluster, Organisation).

Jedes Team, das mehr Verbesserungen identifiziert, als momentan umsetzbar sind, legt diese Verbesserungen in ihrem Team-Improvement-Backlog ab, das der Team-Scrum-Master mit dem Team priorisiert.

Die Summe der Verbesserungen eines Clusters befindet sich im Cluster-Improvement-Backlog, das der Cluster-Scrum-Master mit der Team-Scrum-Master-Gruppe priorisiert. Das Cluster-Improvement-Backlog wird meist aus den Verbesserungsvorschlägen der Teams gespeist.

Die Summe der Verbesserungen einer Organisation befindet sich im Organisation-Improvement-Backlog, das der Organisation-Scrum-Master mit der Cluster-Scrum-Master-Gruppe priorisiert. Das Organisations-Improvement-Backlog wird meist aus den Verbesserungsvorschlägen der Cluster gespeist.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Retrospektive

Team-Scrum-Master Working-Team Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

.

Cluster-Improvement-Backlog

.

Organisations-Improvement-Backlog

Team-Retrospektive

Die Team-Retrospektive bietet dem Team die Gelegenheit, sich selbst zu überprüfen und Verbesserungen der Arbeitsweise für die kommende Iteration zu identifizieren und zu einzuplanen. Sie findet zwischen dem Team-Review und der nächsten Team-Planning statt. Für eine vierwöchige Iteration wird hierfür eine Obergrenze von drei Stunden angesetzt. Bei kürzeren Iterationen ist das Meeting in der Regel kürzer. Der Scrum-Master sorgt dafür, dass das Meeting stattfindet und alle Teilnehmer dessen Zweck verstehen. Der Scrum-Master sorgt dafür, dass das Meeting konstruktiv und produktiv ist. Der Scrum-Master lehrt alle, den Zeitrahmen einzuhalten (Time-box). Aufgrund seiner Verantwortung für den P4-Prozess nimmt der Scrum-Master als gleichberechtigtes Mitglied an der Team-Retrospektive teil. Die Team-Retrospektive wird durchgeführt, um …

  • zu überprüfen wie die vergangene Iteration in Bezug auf die beteiligten Personen, Beziehungen, Prozesse, Infrastruktur und Werkzeuge verlief;
  • die wichtigsten und mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen; und
  • einen Plan für die Umsetzung von Verbesserungen der Arbeitsweise des Teams zu erstellen.

Der Scrum-Master bestärkt das Team darin, seine Entwicklungsprozesse und -praktiken innerhalb des P4-Frameworks zu verbessern, um in der kommenden Iteration effektiver und befriedigender arbeiten zu können. In jeder Team-Retrospektive erarbeitet das Team Wege zur Verbesserung der Produktqualität durch die entsprechende Anpassung der Prozesse oder der Definition-of-Done, sofern diese Änderungen angemessen sind und nicht im Widerspruch mit Produkt- oder Unternehmensstandards stehen. Zum Ende der Team-Retrospektive sollte das Team Verbesserungen für die kommende Iteration identifiziert haben. Die Umsetzung dieser Verbesserungen in der nächsten Iteration ist die Anpassungsleistung zur Selbstüberprüfung des Teams.

Für den Ablauf der Team-Retrospektive gibt inzwischen sehr viele methodische Ansätze und Fragestellungen, z.B.

  • Glad, Sad, Mad
  • Keep, Change, Puzzled
  • Good, Problems, Questions
  • Start, Stop, Keep, More, Less

Unter Fun-Retrospectives oder dem Retromat findet man viele weitere Ideen und Anregungen.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

.

Cluster-Retrospective

.

Organisations-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

Working-Team

Community-of-Practice

Team-Backlog

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog