Sie wundern sich vielleicht, warum Projektcontrolling bei agilen Projekten kein Thema ist. Auch der bekannte Scrum Guide kennt diesen Begriff nicht. Ich kann Ihnen aber jetzt schon sagen, auch bei agilen Projekten wird ein Projektcontrolling gemacht – nur etwas anders.
Das Projektcontrolling gestaltet sich bei agilen Projekten etwas anders als bei „normalen“ Projekten, weil sich das Entwicklungsteam selber organisiert und es keinen Projektleiter und Projektcontroller gibt. Im ersten Artikel haben Sie bereits eine Übersicht erhalten, wie agile Projekte geplant werden. In diesem Artikel zeige ich Ihnen, wie agile Projekte überwacht und gesteuert werden.
Falls Sie sich mit agilem Projektmanagement und Scrum noch nicht so gut auskennen, dann können Sie sich hier zuerst einen Überblick verschaffen:
Übersicht agiles Projektmanagement
Wie Sie in meinen Büchern über Projektcontrolling detailliert nachlesen können, umfasst das Projektcontrolling folgende drei Hauptaktivitäten: Planen, Überwachen und Steuern. Diese Aktivitäten werden auch in agilen Projekten ausgeführt, nur etwas anders und aus meiner Sicht einiges effizienter. In diesem Artikel zeige ich Ihnen, wie agile Projekte überwacht und gesteuert werden.
Den Fortschritt überwachen
Den Fortschritt der Arbeit jederzeit zu kennen ist nicht nur für das Scrum-Team wichtig, sondern auch für das Management und die Stakeholder. Ein umfassendes Projektcontrolling und monatliche oder wöchentliche Statusberichte, wie bei traditionellen Projekten existieren in Scrum jedoch nicht. Das heißt aber nicht, dass der Fortschritt des Projektes, Releases oder Sprints nicht überwacht und rapportiert wird.
In Scrum werden Arbeit, Fortschritt und Ergebnisse in jedem Daily Scrum und in jedem Sprint Review überprüft. Bei Abweichungen vom Plan kann das Scrum Team schnell Maßnahmen einleiten, umplanen, eventuell das Vorgehen anpassen und daraus lernen (inspect, adapt and learn).
Auf Sprint-Ebene hat das Scrum-Team mit dem Daily Scrum, dem Taskboard und Burndown Charts sehr wirkungsvolle Hilfsmittel den Projektfortschritt zu überwachen. So kann das Team Probleme früh erkennen, Maßnahmen schnell einleiten und Probleme lösen solange es noch einfach ist. Dies ist ein grosser Vorteil gegenüber nicht agilen Projekten.
Die Berichte*, welche die Developer erstellen, zeigen, welche User Stories umgesetzt wurden und ob der Arbeitsfortschritt so ist wie geplant. Sie zeigen jedoch nicht, wie viel gearbeitet wurde. In Scrum ist nicht relevant, wer wie viel und wie lange gearbeitet hat. Relevant ist, welche Funktionalität bereits geliefert wurde und wo man in der Produktentwicklung steht.
* Es sind eigentlich keine Berichte, sondern Scrum-Artefakte, die sich aber sehr gut eignen, wenn das Management oder ein Sponsor periodisch Berichte haben will, die den Fortschritt des Projektes zeigen.
Offenheit und höchstmögliche Transparenz im Scrum-Team und gegenüber den Stakeholdern ist einer der fünf Scrum-Werte. Deshalb sollte das Scrum-Team die Informationen über den Sprint- oder Release-Fortschritt allen Stakeholdern möglichst einfach zugänglich machen. Das schafft Vertrauen, Interesse und Committment. Dafür sind z.B. ein Bild des Taskboards, Burndown oder Parking-Lot-Charts ein gutes Hilfsmittel.
Folgende „Berichte“ werden in Scrum oft genutzt. Hier in der Reihenfolge der Wichtigkeit:
- Taskboard
- Sprint Burndown Chart
- Product Burnup Chart
- Release Burndup-Chart
- Parking-Lot-Chart
- Velocitiy Chart
Das Taskboard
Das Taskboard stellt das Sprint Backlog dar und gibt eine Übersicht über alle User Stories, die im Sprint umgesetzt werden, die dazugehörenden Tasks und zeigt den Arbeitsfortschritt. Das Development-Team ist der Besitzer des Sprint Backlogs und damit auch des Taskboards. Das Taskboard zeigt den aktuellen Plan, um das Sprintziel zu erreichen. Es steht auch im Zentrum des Daily Scrum Meetings, das sich auf Fortschritte und Hindernisse konzentriert. Es ist das Informationszentrum im Sprint!
Die User Stories sind im Sprint Backlog in Aktivitäten heruntergebrochen. Diese sind detailliert beschrieben, in Personenstunden geschätzt und dauern möglichst nicht länger als einen Arbeitstag. Dies hilft den Projektfortschritt täglich zu verfolgen und Probleme frühzeitig zu erkennen.
Das Sprint Backlog verändert sich täglich. Spätestens am Ende des Arbeitstages aktualisieren die Development-Team-Mitglieder ihre Aktivitäten und schätzen den verbleibenden Restaufwand. Es gibt Teams, die machen dies während dem Daily Scrum oder sobald neue Informationen verfügbar sind. Wird das Sprint Backlog auf diese Weise regelmäßig aktualisiert, so arbeitet man immer mit aktuellen Informationen und der Projektfortschritt ist jederzeit transparent für das Scrum-Team und die Stakeholder.
Das Taskboard, als tagesaktueller Bericht über alle Arbeiten im Sprint ist etwas abschätzig gesagt eigentlich nur ein „Brett“ mit vielen Zetteln drauf und stellt für Sie vielleicht kein Bericht dar. Machen Sie aber davon z. B. ein Foto und Sie haben die beste Übersicht für Ihre Stakeholder, was der aktuelle Status des laufenden Sprints ist. Dies ist ein Bericht mit viel Aussagekraft, der mit wenig Aufwand erstellt ist. Deshalb ist es für mich der wichtigste Bericht.
Das Taskboard ist ein ideales Überwachungs- und Controlling-Instrument.
Das Sprint Burndown Chart
Im Sprint Burndown Chart visualisiert die Developer die noch verbleibende Arbeit im Sprint in Relation zu der noch verbleibenden Zeit im Sprint. Es erfüllt die Anforderungen des Berichtswesens vollauf:
- Es ist einfach und mit wenig Aufwand zu erstellen
- Es wird von den Developern selbst gezeichnet
- Es ist täglich aktuell
- Es ist immer sichtbar und sorgt für Dringlichkeit
Das Sprint Burndown Chart zeigt dem Scrum-Team folgende Informationen:
- Die noch verbleibende Arbeit bis zum Sprintende
- Abweichungen vom Plan-Arbeitsfortschritt
- Die Entwicklungsgeschwindigkeit
Beachten Sie: Ein echter Fortschritt im Sprint ist zwar erst erreicht, wenn die Arbeitsergebnisse vom Product Owner am Ende des Sprints abgenommen sind, denn nur abgenommene Resultate sind einsetzbar.
So erstellen Sie das Sprint Burndown Chart
In der Sprint-Planungssitzung summieren die Developer die Aufwände aller Aktivitäten der umzusetzenden User Stories und tragen diese auf der vertikalen Achse des Charts ein. Auf der horizontalen Achse tragen sie die Anzahl der Arbeitstage des Sprints ein und ziehen anschließend eine Linie von vom Punkt auf der vertikalen Achse zum letzten Arbeitstag auf der horizontalen Achse. Dies ist dann die ideale Fortschrittslinie (Ideal Burndown).
Immer am Ende eines Arbeitstages aktualisieren die Developer das Sprint Backlog. Dann werden die Restaufwände aller noch nicht vollendeter Aktivitäten summiert und auf dem Sprint Burndown Chart am entsprechenden Tag eingetragen. Wenn Sie dann diese Punkte verbinden haben Sie den Actual Burndown.
Das Sprint Burndown Chart auswerten
Der Trend des Restaufwandes fällt mit der Sprintdauer und sollte spätestens beim Sprintende auf der horizontalen Achse ankommen, also „0“ sein. Liegt die Actual Burndown Linie unterhalb der Ideal Bundown Linie, so heißt dies, dass Sie schneller vorankommen als geplant. Liegt die Linie darüber sind Sie langsamer. Die Actual Burndown Linie steigt an, wenn z.B. die Anzahl der Aktivitäten zugenommen hat, man sich im Aufwand verschätzt hat oder man mit einer Aktivität nochmals neu anfangen musste.
Mit dem Sprint Burndown Chart erkennt das Scrum-Team schnell, ob die noch verbleibende Arbeit wie erwartet abnimmt und ob es wahrscheinlich alle Funktionalitäten bis zum Sprintende entwickeln kann.
Unregelmäßigkeiten im Burndown Chart zeigen Probleme mit Schätzungen, der Kapazitätsplanung oder Scope-Creep. Diese sollte das Team während der Sprintdurchführung, aber auch während der Sprint Retrospektive besprechen.
Soll die Ideallinie in einem Burndown-Chart geändert werden, wenn sich der Story-Umfang während des Sprints ändert? Tun Sie das nicht. Wenn Sie in der dritten Woche eines Sprints neue Arbeiten hinzufügen, wird der Startwert nicht neu berechnet. Das wäre irreführend. Stattdessen zeigen Sie einen Anstieg des verbleibenden Arbeitsaufwandes für die Iteration.
Das Release Burnup Chart
Oft verwenden Scrum-Teams auch Burnup Charts für Sprints oder Releases. In der folgenden Abbildung zeige ich Ihnen ein Release Burnupchart. Auf der horizontalen Achse des Charts sind die geplanten Sprints für den Release aufgetragen. Auf der vertikalen Achse der Aufwand in Story Points für den gesamten Release. Auf dem Chart sehen Sie auch die Target Line, die den geplanten Gesamtaufwand für den Release zeigt. Die vom Punkt 0 bis zum Ende des Release steigende gestrichelte Line zeigt die geplante durchschnittliche Velocity.
Am Ende jedes Sprints aktualisiert das Development-Team das Release Burnup Chart und zeigt damit die während des Spints erledigte Arbeit. Wenn Sie die Punkte nach mehreren Sprints verbinden können Sie sehr gut die bis zu diesem Zeitpunkt erreichte aktuelle durchschnittliche Velocity erkennen. Nach vier Sprints wäre diese hier 200/4=50 Story Point pro Sprint. Diese ist etwas grösser als geplant.
Der Hauptvorteil eines Burnup Charts gegenüber einem Burndown Charts besteht darin, dass Änderungen des Release-Umfangs durch eine Änderung der Target-Linie sehr gut sichtbar werden. Wie Sie es in diesem Beispiel sehen.
Das Story Burndown Chart
Es gibt Scrum-Teams, die verwenden statt den Restaufwand die noch nicht erledigten Sprint Backlog Items (Stories) für ihr Burndown Chart. Auf der vertikalen Achse stehen dann Story Points statt Stunden. Das Resultat ist dann eine Treppenkurve, weil es viel weniger Stories gibt als Aktivitäten und nicht jeden Tag eine Story fertig wird.
Das Story Burndown Chart zeigt gut, wie viel Funktionalität in einem bestimmten Zeitraum geliefert wurde und was noch offen ist.
Der Themenpark
Der Themenpark (auch Parking Lot Diagram genannt) ist ein Bericht, der ursprünglich aus dem Feature Driven Development (FDD) stammt. Für den Product Owner ist es wichtig den Fertigstellungsgrad von Funktionalitäten-Clustern zu kennen und damit auch deren Freigabefähigkeit. Die Füllstandsanzeigen im Themenpark geben einen schnellen Überblick über den Fortschritt des Projektes und der Applikation.
Der Themenpark wird jeweils am Ende jedes Sprints aktualisiert. Dazu ermitteln Sie pro Thema die Anzahl Story Points der bereits abgenommen User Stories und die Gesamtanzahl Story Points der noch ausstehenden User Stories.
Das Velocity Chart
Wie Sie bereits früher gelesen haben ist die Entwicklungsgeschwindigkeit (Velocity) nicht konstant, sondern variiert. Wenn sich die Entwicklungsgeschwindigkeit nach einiger Zeit eingependelt hat, können Sie am Verlauf gut erkennen, ob das Team gerade eine Hoch- oder Tiefphase hat. Wenn zum Beispiel die Entwicklungsgeschwindigkeit einbricht, kann dies an Hindernissen oder an Fehlzeiten liegen. Aber auch eine Veränderung der Teamkapazität hat natürlich einen relevanten Einfluss auf die Entwicklungsgeschwindigkeit.
Beachten Sie: Das Velocity Chart ist nicht als Hilfsmittel zur Überwachung des Teams gedacht, sondern ist ein wichtiges Hilfsmittel für die Sprint- und Releaseplanung.
Der Verlauf der Entwicklungsgeschwindigkeit hilft dem Product Owner den Releaseplan zu kalibrieren und den Release-Burndown-Bericht zu erstellen. Der Bericht mit dem Velocity Chart wird nach dem ersten Sprint erstellt und dann nach jedem Sprintabschluss nachgeführt.
So wird das agile Projekt gesteuert
In Scrum wird in jedem Daily Scrum und in jedem Review die Arbeit, der Fortschritt und das Ergebnis überwacht. Damit kann das Scrum-Team bei Abweichungen vom Plan schnell Maßnahmen einleiten, umplanen, eventuell das Vorgehen anpassen und daraus lernen (inspect, adapt and learn).
Wenn es um die eigentliche Arbeit im Sprint geht entscheiden die Developer selber über die passenden Maßnahmen, da es sich ja selbstmanagt sind. Es wird selber eine User Story auf den nächsten Sprint verschieben, wenn diese zeitlich nicht mehr machbar ist oder diese, in Absprache mit dem Product Owner, canceln wenn sie wider Erwarten nicht umsetzbar ist.
Auf einer übergeordneten Ebene steuert der Product Owner. Zum Beispiel ist nur der Product Owner berechtigt einen Sprint abzubrechen – auch wenn er dies auf den Rat der Stakeholder, des Development-Teams oder des Scrum Masters tut. Der Product Owner steuert auch das Product Backlog, d.h. er stimmt mit dem Kunden und Stakeholdern die Prioritäten von Funktionalitäten ab. Er entscheidet dann über die Zusammensetzung und Reihenfolge der User Stories und deren Aufteilung auf Releases und Sprints.
Es soll mir niemand sagen Kosten spielen bei agilen Projekten keine Rolle! Mit der Sprint- und Releaseplanung und den gearbeiteten Tagen des Scrum-Teams hat der Product Owner auch eine Übersicht über die aktuell angefallen Projektkosten.
Das Development-Team bestimmt selber über die passenden Maßnahmen, da es sich selber organisiert
Hier gibt es noch mehr Wissen
Wollen Sie mehr erfahren, wie Sie Ihre agilen Projekte mit Scrum noch erfolgreicher machen? Mein Buch „Scrum – Agiles Projektmanagement und Scrum erfolgreich anwenden“ bringt Sie einen wichtigen Schritt weiter!
Kennen Sie jemanden, den dieser Beitrag auch interessieren könnte? Dann leiten Sie ihn einfach weiter oder teilen ihn. Danke!
