Als Refinement (Verfeinerung) des Cluster-Backlogs wird der Vorgang angesehen, in dem Details zu Backlog-Einträgen hinzugefügt, Schätzungen erstellt, oder die Reihenfolge der Einträge im Cluster-Backlog bestimmt werden.
Kategorie: Organisatorische Ebenen
Portfolio-Architekt (PFA)
Der Portfolio-Architekt hat mit der Cluster-System-Engineer-Gruppe auf der Portfolio- und Organisationsebene die Verantwortung für die Technologie- und Architekturseite des gesamten Produktentwicklungsprozesses.
Der Portfolio-Architekt bildet mit dem Portfolio-Owner und dem Organisation-Scrum-Master das Management der gesamten Organisation.
Cluster-System-Engineer (CSE)
Der Cluster-System-Engineer hat mit der Team-System-Engineer-Gruppe auf der Cluster/System-Ebene die Verantwortung für die Technologie und Architektur innerhalb des Produktentstehungsprozesses.
Portfolio-Owner (PFO)
Der Portfolio-Owner ist der Product Owner der Organisation. Er hat zusammen mit der Cluster-Product-Owner-Gruppe (CPOG) auf der Portfolio- bzw. Organisationsebene die Gesamtverantwortung für die Markt- und Geschäftsseite des Produktentwicklungsprozesses. (Eine allgemeine Beschreibung des Product-Owner-Rolle befindet sich hier …)
Cluster-Product-Owner (CPO)
Der Cluster-Product-Owner hat mit der Team-Product-Owner-Gruppe auf der Cluster- und System-Ebene die Verantwortung für die Markt- und Geschäftsseite innerhalb des Produktentwicklungsprozesses. (Eine allgemeine Beschreibung des Product-Owner-Rolle befindet sich hier …)
Cluster-Planning
Cluster-Planning in Cycles
Jeder Cycle beginnt mit einem Cluster-Planning-Event. In diesem präsentiert der Cluster-Product-Owner der Team-System-Engineer-Gruppe (TSEG) den aktuellen Stand des Cluster-Backlogs. Neue Einträge oder Änderungen, die der Team-System-Engineer-Gruppe seit dem letzten Cluster-Backlog-Refinement noch nicht bekannt sind, werden geschätzt, ggf. durch Akzeptanzkriterien ergänzt und vom Cluster-Product-Owner innerhalb des Cluster-Backlogs priorisiert.
Die Team-System-Engineer-Gruppe ermittelt die Kapazität für den nächste Cycle durch einen Blick auf die bisherige Arbeitsgeschwindigkeit des Clusters (Cluster-Velocity) und durch einen Blick auf die Kapazität der Teams im nächsten Cycle.
Die Team-System-Engineer-Gruppe zieht die Anzahl von Cluster-Backlog-Items (CBI), die der Einschätzung des TSEG über die Kapazität im nächsten Cycle entspricht, in das Cycle-Backlog des Clusters (Pull). Danach verfeinern die Team-Product-Owner mit den TSEG die CBIs in Team-Backlog-Items, die zur Fertigstellung des CBIs nötig sind.
Danach startet die TSEG den Cycle durch ziehen der ersten Aufgaben von „open“ nach „in progress“.
Kontinuierliches Cluster-Planning
Alternativ zum Planungsrhythmus in Cycles, kann die Planung der Arbeiten für den Cluster auch kontinuierlich erfolgen. Hierfür werden die Cluster-Backlog-Refinements genutzt, wobei ein Cluster-Backlog-Items direkt nach der Analyse und Schätzung, in Bearbeitung gehen kann.
.
\r\n
Passende und weiterführende Artikel:
Events | Rollen | Gruppen | Artefakte |
Team-Planning
. . |
Cluster-Product-Owner | Team-Product-Owner-Gruppe | Cluster-Backlog |
Artefakte der Organisation
Die Organisation ist die oberste Ebene in P4 und organisiert das Portfolio. Hierfür besitzt die Organisation ein Portfolio-Backlog mit Applikationen als Elemente, ein Portfolio-Kanban-Board und die Organisations-DoD.
Organisations-Sync
Organisations-Sync (Scrum-of-Scrums-of-Scrums)
Dieses Event ermöglicht, dass mehrere Cluster miteinander kommunizieren, um Abhängigkeiten, Störungen, neue Erkenntnisse und Entscheidungen, etc. während der laufenden Arbeit untereinander abzustimmen. Die Cluster entscheiden selbst, wie häufig dies benötigt wird (z.B. täglich, wöchentlich).
Die Vertreter des Clusters können die Cluster-System-Engineers der Cluster sein. Es können aber auch andere technische Vertreter des Clusters dazu bestimmt werden.
Das Organisation-Sync findet (meist im Halbkreis) vor dem Portfolio-Kanban-Board der Organisation statt, da die Mitglieder im Organisations-Sync die Portfolio-Backlog-Items bewegen.
Die drei Fragen im Organisations-Sync lauten:
- Was hat mein Cluster seit dem letzten Organisations-Sync gemacht?
- Was wird mein Cluster voraussichtlich bis zum nächsten Organisations-Sync tun?
- An welchen Stellen ist mein Cluster blockiert und benötigt Unterstützung?
In ähnlicher Weise kann die Struktur des Organisations-Sync auch für den Austausch bestimmter Rollen oder Expertisen genutzt werden, z.B. ein Sync der Cluster-Scrum-Master, der Cluster-Product-Owner, der Tester, der Konstrukteure, Designer, etc. eines Clusters.
Durch die Kürze von maximal 15 Minuten ist das Organisations-Sync nur dazu geeignet, Probleme zu identifizieren, nicht aber diese zu diskutieren oder zu lösen. Für die Diskussion von Problemen können die benötigten Mitglieder die Zeit nach dem Organisations-Sync nutzen, während die nicht benötigten Mitglieder weiterarbeiten können.
Besucher im Organisations-Sync
Besucher, die das Organisations-Sync miterleben wollen, können mit Erlaubnis der Mitglieder teilnehmen. Dabei stehen die Besucher in der zweiten Reihe und hören nur zu, außer sie werden von einem aktiven Mitglied angesprochen. Besucher können sein:
.
\r\n
Passende und weiterführende Artikel:
Events | Rollen | Gruppen | Artefakte |
Team-Sync
. . |
Portfolio-Owner | Cluster-Product-Owner-Group | Portfolio-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 | Portfolio-Owner | Cluster-Product-Owner-Gruppe | Team-Improvement-Backlog
. . |
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-Product-Owner | Team-Product-Owner-Gruppe | Team-Improvement-Backlog
. Nutzbares-Wissen & System-Inkrement . |