Teams innerhalb der Organisation sind in Cluster strukturiert. Alle zukünftigen Arbeiten des Teams werden im Team-Backlog verwaltet. Aktuelle Arbeit wird im Iterations-Backlog oder auf einem Kanban-Board dargestellt. Je nach Team-Art, erzeugen Teams Features und Applikationen, Module und Systemplattformen oder Dienstleistungen (Services). Die Qualitätsansprüche des Teams sind in der Team-DoD aufgeführt.
Kategorie: Artefakte
System-Inkrement
System-Inkremente sind Teil- oder Vollintegrationen von Systemversionen, die durch interne oder externe Tests, sowie durch Nutzer- und/oder Markttests verifiziert werden.
System-Inkremente werden häufig auf Cluster-Ebene erzeugt d.h. durch die Integration von Teilergebnisse der verschiedenen Teams eines Clusters.
Für das System-Inkrement hat P4 die Arten und Definitionen von Mustern aus dem Design Thinking Framework übernommen. Sie definieren damit auch die Reifegrade der Muster (Samples).
Der Reifegrad wird letztlich über die Art und Anzahl der Knowledge-Gaps definiert. Um Knowledge Gaps zu schließen werden Muster aufgebaut.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Cluster-Planning | Cluster-Product-Owner | Team-Product-Owner-Gruppe | Cluster-Backlog |
Portfolio-Backlog, Portfolio-Cycle-Backlog und Portfolio-Kanban
Die oberste Ebene der Backlogs des P4-Frameworks, die Portfolio- und Organisationsebene, beschreibt Applikationen und Marktvarianten der Systeme und Produkte. Jede dieser Varianten wird durch einen Satz von System-Anforderungen (Feature Set) beschrieben.
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-Product-Owner | Team-Product-Owner-Gruppe | Team-Backlog
. Nutzbares-Wissen & System-Inkrement . |
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-Product-Owner | Working-Team | Inspizierbare-Ergebnisse
. . |
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-Scrum-Master | Working-Team | Team-Backlog
. . |
Team-DoD (Definition-of-Done)
Das Team, der Team-Product-Owner und die Stakeholder müssen sich darauf einigen was es bedeutet, wenn ein Backlog-Eintrag oder ein Ergebnis als „Done“ bezeichnet wird. Obwohl sich dies erheblich von Team zu Team unterscheiden kann, müssen alle Team-Mitglieder ein gemeinsames Verständnis davon haben, wann Arbeit erledigt ist, um Transparenz zu gewährleisten. Dies erfolgt durch die Definition-of-Done des jeweiligen Teams, Clusters bzw. der Organisation.
Die DoD ist das Qualitätsversprechen des Teams
Die DoD leitet das Working-Team auch bei der Entscheidung, wie viele Team-Backlog-Einträge es während des Team-Planning in das Iteration-Backlog ziehen kann. Der Zweck jeder Iteration ist es, inspizierbare Ergebnisse, verwendbares Wissen oder potenziell auslieferbare Funktionalität innerhalb eines System-Inkrements zu liefern, die der aktuellen Definition-of-Done entsprechen. Working-Teams liefern in jeder Iteration ein Inkrement an Ergebnissen, Wissen und/oder Systemfunktionalität. Dieses Inkrement ist vollständig verwendbar, so dass der Team-Product-Owner sich jederzeit dazu entscheiden kann, es zu freizugeben.
Wenn die Definition-of-Done für ein Team Teil von Konventionen, Standards oder Richtlinien des Clusters oder der Organisation ist, müssen alle Teams diese Cluster-DoD als Minimalziel befolgen. Wenn „Done“ für ein Team nicht Teil der Konvention des Clusters oder der Organisation ist, muss das Team eine für die Team-Ergebnisse geeignete Definition-of-Done formulieren. Wenn es mehrere Teams gibt, die am selben System arbeiten, müssen alle Teams 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 Teams wird erwartet, dass sie ihre jeweilige Definition-of-Done geeignet anpassen, 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.
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 |
| Team-Planning | Team-Product-Owner | Working-Team | Team-Backlog
. . |
Integrated System Sample & Increments
System-Inkremente sind Teil- oder Vollintegrationen von Systemversionen, die durch interne oder externe Tests, sowie (je nach Grad der Regulierung) durch Nutzer- oder sogar Markttests verifiziert werden.
System-Inkremente werden häufig auf Cluster-Ebene erzeugt d.h. durch die Integration von Teilprodukten der verschiedenen Teams eines Clusters.
Für das System-Inkrement hat P4 die Arten und Definitionen von Mustern aus dem Design Thinking Framework übernommen. Sie definieren damit auch die Reifegrade der Muster (Samples).
Der Reifegrad wird letztlich über die Art und Anzahl der Knowledge-Gaps definiert. Um Knowledge Gaps zu schließen werden Muster aufgebaut
| Prototype | Name | Description |
| B | Base Prototype | for design space exploration |
| C | Critical Function Prototype | Need finding; feasibility; fail early |
| D | Dark Horse Prototype | The alternative; thinking out of the box |
| E | Emergent Prototype | Combining several functions and ideas; iterative and incremental |
| F | Functional Prototype | Fully functional, but differs in (e.g. form-factor) |
| G | Gap Closing Prototype | Specific to close Knowledge Gaps or prove Hypotheses |
| H | Hindmost Prototype | Closest to series production |
All Prototype can appear as iterating Prototypes, like G1, G2, G3.
.
\r\n
Passende und weiterführende Artikel:
| Events | Rollen | Gruppen | Artefakte |
| Cluster-Planning | Cluster-Product-Owner
. |
Team-Product-Owner-Gruppe
. |
Inspizierbare-Ergebnisse
. Nutzbares-Wissen & System-Inkrement . |
Interne Dienstleistungen
Interne Dienstleistungen sind die Ergebnisse von Service-Teams.
Versionierte Module
Versionierte Module sind Ergebnisse von Modul-Teams.