Anforderungsmanagement (Requirements Management)_

Als Refinement (Verfeinerung) des Portfolio-Backlogs wird der Vorgang angesehen, in dem Details zu Backlog-Einträgen hinzugefügt, Schätzungen erstellt, Backlog-Einträge zerteilt werden oder die Reihenfolge der Einträge im Portfolio-Backlog geändert werden. Die Verfeinerung ist ein kontinuierlicher Prozess, in dem der Porfolio-Owner und die Cluster-System-Engineer-Gruppe (CSEG) gemeinsam die Portfolio-Backlog-Einträge detaillieren. Bei der Verfeinerung des Portfolio-Backlogs werden die Einträge begutachtet und revidiert. Der Portfolio-Owner kann jedoch jederzeit die Einträge im Portfolio-Backlog aktualisieren oder aktualisieren lassen.

Das Portfolio-Backlog-Refinement dient hauptsächlich der Vorbereitung der nächsten Portfolio-Planung. Dabei stellt der Portfolio-Owner der Cluster-System-Engineer-Gruppe (CSEG) neue Backlog-Einträge vor und lässt diese schätzen. Dies ist eine Voraussetzung für das „Pull“ der CSEG und wird oft auch als Definition-of-Ready bezeichnet. Bei unklaren aber hoch priorisierten Backlog-Einträgen klärt die CSEG die System-Anforderungen, mögliche System-Konzepte und Fähigkeiten. Dies kann sie als Gruppe selbst erarbeiten oder es wird ein entsprechender Backlog-Eintrag als Auftrag für einen der Cluster erzeugt.

Schätzung des Realisierungsaufwands von Backlog-Einträgen

Schätzungen durch die gesamte Cluster-System-Engineer-Gruppe sind aus zwei Gründen wichtig:

Durch das gemeinsame Schätzen analysiert die CSEG 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äßt sich nun einfach errechnen, wie viele Backlog-Elemente in einen Cycle gezogen werden können, nämlich durch Vergleich der in den letzten Cycles fertiggestellten Backlog-Elementen (Velocity der Organisation).

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

Team-Backlog-Refinement

Cluster-Backlog-Refinement

Portfolio-Planung

Organisations-Sync

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

Portfolio-Backlog

Systeme & Applikationen

System-Plattformen & Varianten

Organisations-DoD

Organisations-Improvement-Backlog

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..