Backlog – P4-Dev Framework V2

Backlog (allgemein)

11. Januar 20204. Mai 2020 Oliver Schönfeld

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

Cluster-Backlog-Refinement

Cluster-Review

Cluster-Retrospective

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

Cluster-Backlog-Refinement

31. Dezember 20194. Mai 2020 Oliver Schönfeld

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.

Cluster-Backlog, Cycle-Backlog und Cluster-Kanban

29. September 201916. Mai 2020 Oliver Schönfeld

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

25. September 201916. Mai 2020 Oliver Schönfeld

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

Inspizierbare-Ergebnisse

Team-DoD

Team-Improvement-Backlog

Cluster-Backlog

Portfolio-Backlog

Verantwortung von Markt und Business durch den Product Owner

25. September 201915. Mai 2020 Oliver Schönfeld

Das P4-Framework gliedert seine Organisations- und Managementstruktur der Produktentwicklung in drei Bereiche:

Markt und Business (hier weiter ausgeführt)
Organisation, Infrastruktur und Prozesse
Technologie und Architektur

Markt und Business

Die Product-Owner-Rollen der verschiedenen Ebenen tragen die Verantwortung für die Produkte und deren Märkte. Dabei kommunizieren sie mit den Stakeholdern dieses Bereichs: Benutzer, Kunden und der (meist interne) Vertrieb.

Die Rolle des Product-Owners

Product, Product Backlog und Product Owner sind im P4-Framework generische Begriffe, d.h. sie existieren ausschließlich in spezifischen Ausprägungen. So hängen sowohl die generischen Artefakte „Product“, „Product Backlog“ als auch die generische Rolle „Product-Owner“ von der Art des jeweiligen Teams und der Ebene innerhalb der Organisation ab.

Der Product-Owner ist dafür verantwortlich, den Wert des Produktes zu maximieren, das aus der Arbeit des Working-Teams entsteht. Wie dies geschieht, kann je nach Organisation, Cluster oder Team und Einzelpersonen stark variieren. Der Product-Owner ist die einzige Person, die für das Management des Product-Backlogs verantwortlich ist. Das Management des Product-Backlogs umfasst:

Die Product-Backlog-Einträge klar zu formulieren;
Die Reihenfolge der Einträge im Product-Backlog so anzuordnen, dass Ziele und Missionen optimal erreicht werden können;
Den Wert der Arbeit zu optimieren, die das Working-Team durchführt;
Sicherzustellen, dass das Product-Backlog sichtbar, transparent und für alle klar ist und zeigt, woran das Team als nächstes arbeiten wird;
Sicherzustellen, dass das Working-Team die Product-Backlog-Einträge im erforderlichen Maße versteht; und
Die Ergebnisse des Working-Teams zu begutachten und abzunehmen.

Der Product-Owner kann die oben genannten Arbeiten selbst durchführen oder sie durch das Working-Team oder einzelne Mitglieder durchführen lassen. Der Product-Owner bleibt jedoch immer rechenschaftspflichtig (accountable).

Der Product-Owner ist eine einzelne Person, kein Komitee. Er kann zwar die Wünsche eines Komitees im Product-Backlog wiedergeben, aber diejenigen, die einen Eintrag des Product-Backlogs in seiner Priorität verändern möchten, müssen sich an den Product-Owner wenden. Damit der Product-Owner erfolgreich sein kann, muss die gesamte Organisation seine Entscheidungen respektieren. Die Entscheidungen des Product-Owners sind in Inhalt und Reihenfolge des Product-Backlogs sichtbar. Niemand anderer darf dem Working-Team Anforderungen oder Arbeit zuordnen.

Die Product-Owner im P4-Framework

Im P4-Framework wird die generische Rolle des Product-Owners auf allen drei Ebenen konkretisiert und erweitert: Wichtig dabei ist, dass die Product-Owner auf jeder Ebene sich untereinander innerhalb der jeweiligen PO-Gruppe abstimmen und dabei die Prioritäten für ihre Teams aus dem übergeordneten Backlog ableiten. (Mehr zu dem Überlappungsprinzip)

der Team-Product-Owner (TPO) als PO für ein einzelnes Team. Alle TPOs des selben Clusters bilden die Team-Product-Owner-Gruppe (TPOG) dieses Clusters
der Cluster-Product-Owner (CPO) als PO für einen Cluster aus mehreren Teams. Alle CPOs bilden die Cluster-Product-Owner-Gruppe (CPOG) der Organisation
der Portfolio-Owner (PFO) als PO für die gesamte Organisation, bestehend aus mehreren Clustern.

\r\n

Passende und weiterführende Artikel:

Team-Backlog-Refinement

21. Juli 201911. Mai 2020 Oliver Schönfeld

Als Refinement (Verfeinerung) des Team-Backlogs wird der Vorgang angesehen, in dem Details zu Backlog-Einträgen hinzugefügt, Schätzungen erstellt, und die Reihenfolge der Team-Backlog-Einträge bestimmt werden. Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Team-Product-Owner und das Working-Team gemeinsam die Team-Backlog-Einträge detaillieren. Bei der Verfeinerung des Team-Backlogs werden die Einträge begutachtet und revidiert. Es sollte normalerweise nicht mehr als 10% der Kapazität des Working-Teams beanspruchen. Der Team-Product-Owner kann jedoch jederzeit die Einträge im Team-Backlog aktualisieren oder aktualisieren lassen.

Das Team-Backlog-Refinement dient hauptsächlich der Vorbereitung des nächsten Team-Planning. Dabei stellt der Team-Product-Owner dem Working-Team neue Team-Backlog-Einträge vor und lässt diese vom Working-Team schätzen. Stehen Einträge kurz vor dem Beginn der Arbeiten, achtet das Team darauf, dass die Einträge klein genug sind, damit sie in eine Iteration gezogen werden können. (Dies ist eine Voraussetzung für das „Pull“ und wird oft auch als Teil der Definition-of-Ready (DoR) bezeichnet). Ist dies nicht der Fall, verfeinert das Team den entsprechenden Eintrag durch Zerteilen in mehrere Einträge (Splitting).

Arbeitet das Team nicht in Iterationen, sondern kontinuierlich mittels Kanban, vereinbart das Team ein Schätzlimit, ab dem das Zerteilen von Backlog-Items nötig wird.

Schätzung des Realisierungsaufwands von Backlog-Einträgen

Schätzungen durch das gesamte Team sind aus zwei Gründen wichtig

Durch das gemeinsame Schätzen analysiert das komplette Team den jeweiligen Backlog-Eintrag aus verschiedenen Blickwinkeln und reichert diesen dabei mit Informationen an, wie Akzeptanzkriterien und Randbedingungen. Außerdem werden erste Ideen zur Umsetzung erzeugt.
Das Ergebnis der Schätzung ist eine Zahl, mit der einzelne Backlog-Elemente bewertet werden können, z.B. zur Priorisierung. Außerdem lässt sich nun einfach errechnen, wie viele Elemente in eine Iteration gezogen werden können, nämlich durch Vergleich der in den letzten Iterationen fertiggestellten Backlog-Elementen (Velocity des Teams).

Zur Schätzung des Aufwands bedient sich das Team der Methodik des Planning-Poker®.

–

\r\n

Passende und weiterführende Artikel:

Events

Rollen

Gruppen

Artefakte