Team-Kalender

Der Team-Kalender stellt die Verfügbarkeit der Nucleus- und Extended-Team-Mitglieder für eine Iteration tabellarisch dar. Jedes Team-Mitglied trägt geplante Abwesenheiten ein, um vor (oder spätestens in) der Iterationsplanung die Brutto-Kapazität des Teams zu ermitteln. Dieser Wert wird zur Anpassung des Team-Forecasts genutzt, in dem er ins Verhältnis zur Velocity des Teams gesetzt wird, wodurch sich wird die Vorhersagbarkeit des Teams deutlich verbessert.

Beispiel eines ausgefüllten Team-Kalenders

Das Konzept lässt sich auch für Cluster und Cycles anwenden, am Best auf Basis der Feiertage im Cycle und der längerfristigen Urlaubsplanung der Team-Mitglieder.

Arbeitet das Team nicht mit Iterationen, sondern kontinuierlich mittels Kanban, wird der Team-Kalender für mehrere Wochen im voraus wochenweise geführt.

Definition-of-Ready (DoR)

Die Definition-of-Ready (DoR) ist eine Liste, die festlegt, welche Kriterien bestimmte Artefakte erfüllen müssen, bevor festgelegte Aktionen in einer Organisationseinheit anlaufen. Sie ist damit ist eine Vereinbarung, um klare Qualitätskriterien von Artefakten festzulegen. Z.B. darf im P4-Framework ein Team keine ungeschätzten Backlog-Elemente in eine Iteration ziehen. DoRs gibt es auf allen Ebenen und können für unterschiedliche Organisationseinheiten verschieden sein.

Weiterlesen

Backlog (allgemein)

Ein Backlog ist eine geordnete Liste von allem Bekannten, das von einer Organisationseinheit (Team, Gruppe, Cluster, Organisation) durchgeführt werden soll und dient als einzige Anforderungsquelle für Arbeiten dieser Organisationseinheit. Der Product-Owner ist für das Backlog, seine Inhalte, den Zugriff darauf und die Reihenfolge der Einträge verantwortlich.
Ein Backlog enthält nur die zurzeit bekannten Einträge. Während der Entwicklungsschritte entwickelt es sich mit den Produkten und Dienstleitungen und deren Anwendung weiter. Es wird dynamisch angepasst, um für Produkte und Dienstleitungen klar herauszustellen, was es braucht, um ihre Aufgaben angemessen zu erfüllen, im Wettbewerb zu bestehen und einen möglicht hohen Nutzen zu bieten.
Sofern Produkte und Dienstleitungen existieren, gibt es auch die dazugehörenden Produkt-, System- oder Applikations-Backlogs.

Ein Backlog-Eintrag enthält als Attribute eine Beschreibung, eine Aufwandsschätzung, sowie Akzeptanzkriterien und Testbeschreibungen, die die Vollständigkeit nachweist und beschreibt wann er erledigt [„Done“] ist.

„Das Backlog ist die einzige Quelle von Arbeit.“ Dieses Prinzip sorgt für folgende wichtige Dinge:

  • Eine größtmögliche Transparenz über geplante Arbeiten.
  • Klare Prioritäten. Wie in einem Stapel gibt es nur eine Priorität Eins. Beim Einfügen von neuen Einträgen werden weiter unten liegende Einträge weiter nach unten verschoben.

Auf allen Ebenen im P4-Framework gibt es für jede Organisationseinheit jeweils genau ein Backlog, d.h.

  • für jedes Team ein Team-Backlog. Wenn ein Team an mehreren Applikationen oder Systemen arbeitet, enthält das Team-Backlog Backlog-Elemente, die die Arbeit des Teams zur Realisierung dieser Systeme und Applikationen beschreibt.
  • für jeden Cluster, ein Cluster-Backlog. Das Cluster-Backlog enthält alle Produkt- und Systemversionen, Applikationen und Dienstleistungen des Clusters.
  • für die Organisation, ein Portfolio-Backlog. Das Portfolio-Backlog enthält alle Produkt- und Systemversionen, Applikationen und Dienstleistungen der Organisation.

Improvement-Backlog

Die einige Ausnahme von der „Ein-Backlog-Regel“ ist das Improvement-Backlog der Organisationseinheit. Es beschreibt den Vorrat an Verbesserungen und wird von der entsprechenden Einheit, selbst-organisiert, in die Arbeitsplanung integriert. Eine Regel, die beschreibt, wie viel Arbeitsaufwand von der Gruppe für Verbesserungen investiert wird (z.B. 10-20%), hilft die Planbarkeit und Vorhersagbarkeit von anderen Backlog-Einträgen hoch zu halten.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Team-Planning

Team-Sync

Team-Backlog-Refinement

Team-Review

Team-Retrospektive

.

Cluster-Planning

Cluster-Sync

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

.

Portfolio-Planung

Organisations-Sync

Portfolio-Refinement

Portfolio-Review

Organisations-Retrospektive

Team-Product-Owner

Team-System-Engineer

Team-Scrum-Master

.

Cluster-Product-Owner

Cluster-System-Engineer

Cluster-Scrum-Master

.

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

Working-Team

.

Team-Product-Owner-Gruppe

Team-System-Engineer-Gruppe

Team-Scrum-Master-Gruppe

Managementkreis des Clusters

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Team-Backlog

Team-DoD

Team-Improvement-Backlog

.

Cluster-Backlog

Cluster-DoD

Cluster-Improvement-Backlog

.

Portfolio-Backlog

Organisations-DoD

Organisations-Improvement-Backlog

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

Produkte, Applikationen und Marktvarianten

Das Portfolio-Backlog auf Organisationsebene, der oberste Ebene der Backlogs, enthält Systeme, Produkte und technische Produktvarianten, sowie Produktvarianten für spezielle Märkte. Jede dieser Produktvarianten wird durch einen Satz von System-Anforderungen (Feature Set) beschrieben. Auf diese Weise sind die Produktvarianten sowohl bezüglich des Nutzens, als auch bezüglich des zu investierenden Aufwands gegeneinander abschätzbar. Hierfür wird im P4-Framework das sogenannte Upswing-Gravity-Field verwendet.

Die Portfolio-Ebene ist nicht nötig für Organisationen, die nur ein einziges Produkt erstellen.

.

\r\n


Passende und weiterführende Artikel:

Events Rollen Gruppen Artefakte
Portfolio-Planung

Organisations-Sync

Portfolio-Refinement

Portfolio-Review

Portfolio-Owner

Portfolio-Architekt

Organisations-Scrum-Master

.

Cluster-Product-Owner-Gruppe

Cluster-System-Engineer-Gruppe

Cluster-Scrum-Master-Gruppe

Managementkreis der Organisation

Portfolio-Backlog

Systeme & Applikationen

Organisations-DoD

Cluster-DoD

Die Teams des Clusters, die Team-System-Engineer-Gruppe, die Team-Product-Owner-Gruppe und die Stakeholder müssen sich darauf einigen was es bedeutet, wenn ein Backlog-Eintrag oder ein Ergebnis als erledigt („Done“) bezeichnet wird. Obwohl sich dies erheblich von Cluster zu Cluster unterscheiden kann, müssen alle ein gemeinsames Verständnis davon haben, wann Arbeit erledigt ist, um Transparenz zu gewährleisten. Dies erfolgt durch die Definition-of-Done des jeweiligen Clusters.

Die Cluster-DoD ist das Qualitätsversprechen des Clusters

Die DoD leitet die Team-System-Engineer-Gruppe auch bei der Entscheidung, wie viele Cluster-Backlog-Einträge es während des Cluster-Plannings in das Cycle-Backlog ziehen kann. Der Zweck jedes Zyklus ist es, inspizierbare Ergebnisse, verwendbares Wissen oder potenziell auslieferbare Funktionalität innerhalb eines System-Inkrements zu liefern, die der aktuellen Definition-of-Done entsprechen. Cluster liefern in jedem Zyklus ein Inkrement an Ergebnissen, Wissen und/oder Systemfunktionalität. Dieses Inkrement ist vollständig verwendbar, so dass der Cluster-Product-Owner sich jederzeit dazu entscheiden kann, es zu freizugeben.

Wenn die Definition-of-Done für ein Produkt Teil von Konventionen, Standards oder Richtlinien der Organisation ist, müssen alle Cluster diese als Minimalziel befolgen. Wenn „Done“ für ein Produkt nicht Teil der Konvention der Organisation ist, muss der Cluster (d.h. die TSEG) eine für das Produkt geeignete Definition-of-Done formulieren. Wenn es mehrere Cluster gibt, die am selben System arbeiten, müssen alle Cluster gemeinsam eine Definition-of-Done erstellen. Jedes System-Inkrement ist additiv zu allen früheren Inkrementen und gründlich getestet, um sicherzustellen, dass alle Inkremente gemeinsam funktionieren. Von reiferen Clustern wird erwartet, dass sie ihre jeweilige Definition-of-Done geeignet erweitern, um strengere Kriterien für eine höhere Qualität sicherzustellen. Neue Einträge in der Definition-of-Done können dazu führen, dass noch zu erledigende Arbeit in früheren „Done“ System-Inkrementen aufgedeckt wird (auch als „technische Schulden“ bekannt).

Jedes einzelne Ergebnis, Produkt oder System sollte eine Definition-of-Done haben, die den Standard für jegliche daran durchgeführte Arbeit darstellt.

Die Definition-of-Done entspricht daher in ihrem Wesen, den Prozessbeschreibungen und „Standard-Operation-Procedures“ einer klassischen Organisation, allerdings in einer starkt kondensierten Form.

.

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

.

Cluster-Backlog

Nutzbares-Wissen & System-Inkrement

Cluster-Improvement-Backlog

.

Organisations-DoD