Agiles Projektmanagement mit Scrum

Der Ansatz des agilen Projektmanagements lässt sich sehr gut mit Scrum kombinieren. Die Rollen, Meetings und Verantwortungen aus Scrum werden dabei 1 zu 1 übernommen. Allerdings ergänzen wir Scrum mit Werkzeugen aus dem agilen Projektmanagement und nehmen das Project Inception und die Projektbeauftragung hinzu.

Der Scrum-Zyklus verändert sich ein wenig uns sieht wie im folgenden Beispiel aus:

img_20161028_123257

Vision

Der Auftraggeber (z.B. CEO, Marketingchef, externer Kunde) hat eine Produktvision und kommt mit dieser Vision zum Projektteam, um über die Machbarkeit zu diskutieren.

Project Inception

Es wird ein erstes Projektteam gebildet, z.B. aus Scrum Master, Product Owner und einem oder zwei Entwickler mit genügend Wissen für eine erste Analyse der Vision.
Die Vision wird näher betrachtet und das Projektteam fertigt ein Project Inception an. Mit dem Auftraggeber werden Rahmenbedingungen wie die Priorität von Umfang/Qualität/Budget/Zeit bestimmt und eine erste Generierung der Backlog Items geschieht. Je nachdem in wie weit der Kunde in den Prozess mit eingebunden werden kann (und möchte), wird entschieden, ob in dieser Phase bereits eine umfangreiche Aufwandsschätzung zu erfolgen hat. In dem Fall wird bereits frühzeitig das Projektteam erweitert, so dass die Aufwandsschätzung von den Team-Mitgliedern durchgeführt wird, die an dem Projekt auch arbeiten werden.
Sobald die Rahmenbedingungen für das Projekt festgelegt worden sind, erfolgt eine schriftliche Genehmigung des Projekts durch den Auftraggeber. Dies stellt den Startschuss für das Projektteam dar.

Backlog füllen

Die erste Aufgabe wird es sein, das Backlog mit weiteren Backlog Items zu füllen. Das Team wird sich dabei zunächst auf der Ebene von Master Stories bewegen und nur nach und nach die User Stories dazu erstellen.
Das Füllen wird in einem oder mehrere Sprints durchgeführt. Dazu werden vor allem SPIKES angewendet, um eine Analyse der Requirements durchzuführen.

Vorbereitung zu Sprint 1

Im Rahmen des Füllens des Backlogs wird auch der erste Sprint vorbereitet. Dazu werden die User Stories identifiziert, die für den Projektstart erforderlich sind und bereits detaillierter beschrieben und geschätzt. Umso mehr User Stories zur Wahl für Sprint 1 stehen, desto besser. Allerdings sollte auch diese Phase zeitlich begrenzt sein, um nicht zu viel Zeit auf die Planung anzuwenden. Die weitere Planung wird im Laufe der Projektumsetzung parallel zur Entwicklung des Produktes erfolgen.

Der Sprint-Zyklus beginnt

Ab jetzt arbeitet das Scrum-Team wie gewohnt an den User Stories aus dem Product Backlog. In den Estimation Meetings werden nach und nach die noch nicht als User Stories heruntergebrochenen Master Stories besprochen und User Stories generiert sowie geschätzt.

Parallel dazu: die Roadmap

Während das Scrum-Team mit Sprint 1 beginnt, wird der Product Owner die bereits zur Verfügung stehenden Master Stories in die Roadmap und einen Releaseplan übertragen. Beide Pläne werden im Sprint-Zyklus kontinuierlich aktualisiert.

Das Produkt entsteht inkrementell

Das Scrum-Team hat weiterhin das Ziel, am Ende jedes Sprints einen releasbaren Stand des Produktes zu haben. Im Projekt werden neue Releases allerdings anhand des Releaseplans abgebildet, weshalb sich das Release am Sprintende vermutlich auf eine neue testbare Version beschränken wird. Vielleicht hat das Team ein Demosystem für den Auftraggeber aufgesetzt, auf das am Sprint-Ende der jeweils aktuelle Stand eingespielt wird.
Sobald das Projekt abgeschlossen ist, bekommt der Auftraggeber das fertige Produkt ausgeliefert.

Dank vieler Releases in der Zwischenzeit und kontinuierliches Feedback durch den Auftraggeber, wird das Produkt am Ende keine Überraschung für den Auftraggeber sein und ein für Scrum-Team und Auftraggeber zufriedenstellendes Ergebnis darstellen.

Backlogs im Scrum-Prozess

Im Scrum-Prozess wird oftmals zwischen Sprint-Backlog, Produkt-Backlog und Release-Backlog unterschieden. Das Sprint-Backlog besteht dabei aus den Aufgaben (im weiteren Verlauf Stories genannt), die das Team für eine Iteration (Sprint) angenommen hat. Das Ziel eines jeden Sprints ist es, dass alle angenommenen Stories bis zum Ende des Sprints erledigt werden. Ist dies nicht der Fall, wandern nicht erledigte Stories entweder zurück ins Produkt-Backlog oder in den nächsten Sprint.

Sprint Backlog zur Verwaltung von Stories, die sich in einem Sprint befinden

Das Produkt-Backlog (kurz: Backlog) ist eine Ansammlung von Stories, die für das Team bereitstehen und in nächster Zeit umgesetzt werden sollen. Der Product Owner pflegt das Backlog, erstellt neue Stories und schreibt die Anforderungen von Stories aus. Das Team kommt mit dem Product Owner und dem Scrum Master in Estimation Meetings zusammen, um Stories aus dem Produkt-Backlog zu schätzen. Dabei wird oftmals als Schätzeinheit auf Story Points zurückgegriffen, welche nicht den Aufwand, sondern die Komplexität einer Story darstellen.

Das Product Backlog beinhaltet alle Stories des Produktes/Teams, die der Product Owner bereits erfasst hat. Stories werden darin priorisiert.

Mit Hilfe von geschätzten Stories und der Velocity, also dem Durchsatz an Story Points, den das Team bisher erzielt hat (bzw. die Anzahl der Story Points, die das Team pro Sprint erledigt), kann eine Vorausschau bzgl. der Fertigstellung von Stories erstellt werden. Dies kann zum Beispiel dazu genutzt werden, einen Release-Plan auf Basis von Stories zu erstellen. Doch werden Stories oftmals erst im Laufe eines Projektes generiert und folglich erst später geschätzt, weshalb diese Methode für größere Projekte nicht unbedingt geeignet ist. Daher besteht das Release-Backlog bisweilen nicht aus Stories, sondern aus sog. Master Stories. Diese werden grob geschätzt und eine ungefähre Komplexität wird angegeben. Im Verlauf des Projektes werden die einzelnen Stories einer Master Story erstellt und geschätzt und die Abweichung zur Master Story berechnet. Dies fließt in das Burn-Up-Chart ein, welches zur Visualisierung von Projekt-Fortschritten eingesetzt wird. Durch das grobe Schätzen am Anfang und dem granularen Schätzen während des Projektes, wird die Menge der zu erledigenden Aufgaben ggf. im Laufe eines Projektes steigen. Ein Beispiel eines solchen Burn-Up-Charts, der im Laufe des Projektes ansteigt, zeigt die folgende Abbildung:

burn-up-chart-270x250@2x

Das Release Backlog kann eine Untermenge des Product Backlogs darstellen und liefert eine Aussage darüber, wann ein Teilprojekt ausgeliefert werden könnnte.

Neben den Backlogs zur Verwaltung von Stories, welche vom Team und dem Product Owner eingesetzt werden, verfügt auch der Scrum Master über ein eigenes Backlog. In diesem Impediment-Backlog werden alle Hindernisse und potentielle Optimierungen festgehalten. Der Scrum Master nimmt – beispielsweise aus der Sprint-Retrospektive oder dem Daily Stand-up (bzw. Daily Sprint) – Aufgaben auf, die durch das Team generiert oder durch den Scrum Master als Verbesserungspotential erkannt wurden. Der Fortschritt zur Abarbeitung der darin enthaltenen Punkte kann somit visualisiert und eine Priorisierung vorgenommen werden. Das Impediment-Backlog sollte dabei zumindest für das gesamte Team einsehbar sein.