PmBok Guide 6th und agiles Projektmanagement (Teil 2)

DSVGO konform! Falls es gefällt, belohne den Autor! Teile diesen Beitrag!
Der Entwickler meldet dem Product Owner, dass das Inkrement noch nicht fertig ist. Der Product Owner meint aber, der Sprint ist beendet.
Passiert dies in jedem Sprint, wird dich das Backlog allmählich aufstapeln. Ohne "Unterlast-Ressourcen" kann so etwas oft passieren.

Im Teil 1 haben wir unter anderem geklärt, dass inkrementell und iterativ nicht synonym zu verwenden sind.

 

Auf Seite 22 im PmBok Guide 6th, wird der Prozess „Vorgänge definieren“ im Kontext der „rollierenden Planung“ oder „adaptiven Planung (u.a. agil)“ genannt. Genau genommen fokussiert der PmBok Guide schon immer, lange vor dem Aufkommen agiler Frameworks, agile Planung. 

Der Begriff der „rollierenden Planung“ ist mir jetzt seit 15 Jahren bekannt. Rollierend bedeutet, dass Planung immer nur die Anforderungen dediziert plant, über die „konkretes Wissen“ besteht. Damit soll verhindert werden, dass zu viele Änderungsanträge zu Stande kommen. Allerdings implizierten die PmBoks 1 – 5th immer Use Case bezogene Projekte, wobei die adaptiven Projekte ja primär User Story bezogen geplant werden. 

Auch die Total Cost of Ownerships frequentieren des Projektlebenszyklus.
Buchen Sie einen der erfahrensten PMP Trainer Deutschlands!

Tatsache aber ist, dass Frameworks im agilen Bereich, durchaus positiv durch Prozessbeschreibungen wie bspw. „Vorgänge definieren“ befruchtet werden können. Dieser Prozess besteht aus drei Eingangswerten, vier Werkzeugen und Methoden sowie fünf Ausgangswerten. Auch innerhalb eines Sprints müssen Vorgänge oder Aufgaben geplant werden. Dafür vorgesehen ist das Backlog, dass auf Basis von User Stories erstellt wird. Das Backlog kann und sollte aber auch als Projektstrukturplan PSP im Rahmen des Sprint Plannings dargestellt werden.  Im Gegensatz zum Backlog stellt der PSP die User Stories in Form einer Baumstruktur oder eines Mindmap dar. Der Unterschied besteht darin, dass es sich beim PSP um eine zusätzliche grafische Darstellung des Scopes handelt, wogegen wenn schon möglich, User Stories in Arbeitspakete umgewandelt werden.

Ein PSP kann dabei helfen, Interdependenzen zwischen den Aufgaben deutlich zu machen, Storiepoints den Aufgaben zuzuweisen sowie dem Team einen gemeinsamen View auf das große Ganze eines Sprints zu präsentieren.

Im Sprint Planning werden die User Stories und/oder Arbeitspakete in Aufgaben oder Vorgänge umgewandelt. Die Prozesse des PmBok Guides werden hier für jeden Sprint iterativ wiederholt. Beispiel S. 131 3.Absatz: Für jede Iteration werden die Prozesse Anforderungen sammeln, Inhalt und Umfang definieren, Projektstrukturplan erstellen wiederholt. Wie schon weiter oben beschrieben, stellen die Prozessbeschreibungen mit Ihren Werkzeugen und Methoden auch für agile Projekte einen erheblichen Nutzen dar.

Zudem verweisen die Inputs und Outputs wiederum auf Prozesse, die Inputs erzeugen oder Outputs aufnehmen. So erzeugen diese Interdependenzen oder Schnittstellen eine stringente Struktur, die dem Team hilft, einen ganzheitlichen Content für einen Sprint zu entwickeln. Die „Entwicklung des  Projektstrukturplans“ bspw. beschreibt einen Prozess, der den Input für den Prozess „Vorgänge definieren“ leistet.

 Lesen Sie im 3. Teil: Iterative und Bedarfsorientierte Terminplanung 

 

Auch MS Project hilft Projektmanagement zu unterstützen. MS Project ist quasi der Spiegel der Methoden.
MS Project Trainer seit der Version 4.0.
DSVGO konform! Falls es gefällt, belohne den Autor! Teile diesen Beitrag!

Schreibe einen Kommentar