4.1 Meilenstein-Trendanalyse
Ein einfaches Werkzeug im Projektcontrolling ist die Ampel-Steuerung. Jedoch gibt es manchmal Wassermelonen-Projekte. Diese sind außen grün und innen rot. Eine solche Abweichung zwischen der internen Meinung und dem Statusbericht sollte vermieden werden. Also geht es darum, Abweichungen genau zu messen und abhängig von dem Delta eine Ampelfarbe zuzuweisen. Als Beispiel dient dazu die Meilenstein-Trendanalyse (MTA). Auf der Y-Achse (vertikale Achse) werden die Meilensteine zum Zieltermin eingetragen. Auf der X-Achse (horizontale Achse) werden zu den Stichtagen, in der Regel die Termine der Berichtszeitpunkte die aktuellen Prognosen eingetragen. Wenn eine Linie nach unten geht, dann wird der Meilenstein voraussichtlich früher erreicht, bei einem horizontalen Verlauf verläuft die Zielerreichung planmäßig und bei einem Anstieg verzögert sich der Meilenstein.
Abb. 5: Meilenstein Trend-Analyse
Abhängig von der Verzögerung kann die Ampelfarbe festgelegt werden. Die Konvention der Ampelfarben ist:
Grün = Alles im Plan,
Gelb = Wir haben ein Problem, können es jedoch selbst lösen und
Rot = Wir brauchen Hilfe. Wobei der Projektleiter die genauen Maßnahmen zur Entscheidung vorschlägt.
Wie sieht es im agilen Projektcontrolling aus? Nach DIN 69901 versteht man unter Projektcontrolling die Sicherung des Erreichens von Projektzielen durch
Soll-Ist-Vergleich (P–D–C-A), Feststellung der Abweichungen (Kosten und Zeit), Bewertung der Auswirkungen und Vorschlagen von Korrekturmaßnahmen. Die Messung der Aufgabenerledigung und deren zeitliche Vorhersage wird durch den Product Owner (PO) vorgenommen. Hierzu bedient sich der PO einiger Werkzeuge (Tools). Dies sind insbesondere das:
- Burn Down Chart
- Burn Up Chart
- Cumulative Flow Diagramm
- Earned Value Analyse
- Mitwirkung bei der Maßnahmenplanung und Kontrolle ihrer Durchführung. In agilen Teams wird dies durch die Teammitglieder selber ausgeführt.
Für die Projektsteuerung stellen diese Tools in periodischen Soll-Ist-Vergleichen den erreichten Iststand dem Plan- bzw. Sollstand gegenüber.
4.2 Das Burn Down Chart
Die folgenden Fragen werden häufig in agilen Scrum-Projekten teamintern gestellt:
- Wie viel der Arbeit in einem Sprint ist bereits erledigt?
- Liegen wir im Plan oder haben wir schon Abweichungen?
- Wie viel Arbeit steht im aktuellen Sprint noch an?
Abb. 6: Burn Down Chart
Zur Beantwortung dieser Fragen hat sich das sog. Burn Down Chart bewährt: Dieses zeigt auf, wie viel Arbeit zum aktuellen Zeitpunkt im aktuellen Sprint noch erledigt werden muss. Es zeigt auch auf, wie schnell das Team arbeitet.
Damit kann man feststellen, ob die Teammitglieder über- oder unterlastet sind, diese Erkenntnis muss für die Planung des nächsten Sprints einbezogen werden. Das Burn Down Chart ist ein Werkzeug, um den Arbeitsfortschritt und die noch zu erledigende Arbeitsmenge innerhalb des aktuellen Sprints aufzuzeigen. Der Burn Down Chart ist nur dann sinnvoll, wenn es eine fixierte Anzahl von Tasks in einem Sprint gibt.
4.2.1 Vorteile des Burn Down Chart:
- Einfach und verständliches Werkzeug für das Controlling im aktuellen Sprint
- Schnelle Übersicht über noch zu leistende Arbeit im aktuellen Sprint
- Realistische Darstellung, da die Teammitglieder das Burn Down Chart beim Daily Sprint pflegen.
- Information, ob sich das Team im Zeitplan befindet
- Information über die Arbeitsgeschwindigkeit und Schätzgenauigkeit des Teams
- Als Teil des Projektstatusberichtes nutzbar
4.2.2 Wichtig bei der Erstellung des Burn Down Charts
Die Größe der Tasks muss zur Sprintlänge passen. Erfahrungswert ist, dass die Taskgröße 1/10 der Sprintlänge nicht überschreiten sollte (aufgerundet auf ganze Tage). Dies kann in größeren Projekten zu einer hohen Anzahl von Tasks führen und damit zu einer hohen Anzahl von Anforderungen. Die Tasks müssen detailliert genug beschrieben sein, damit der Schätzwert so realistisch wie möglich ist. Weiterhin muss teamintern klar geregelt sein, wann ist eine Task wirklich fertig (Definition of Done).
Während des Daily Scrum Meetings wird der Restaufwand einer Task arbeitstäglich neu geschätzt. Ein gegenüber der Ursprungsschätzung geänderter Restaufwand wird im Burn Down Chart eingetragen. Dieses ist notwendig, damit das Burn Down Chart den tatsächlichen Restaufwand im Sprint wiedergibt.
Dies kann dazu führen, dass am Ende des Sprints nicht alle geplanten Tasks umgesetzt werden konnten. Dann muss entschieden werden, ob die übriggebliebenen Tasks in den nächsten Sprint mit übernommen werden oder in den Produkt-Backlog zurückgehen.
Bei der Erstellung des Burn Down Charts wird auf der horizontalen Achse das Datum der Arbeitstage bis zum Sprintende eingetragen. Auf der vertikalen Achse werden die Personenstunden oder Story Points aufgetragen, die im aktuellen Sprint erbracht werden sollen, in einer passenden Skalierung.
Nun werden im Daily Scrum Meeting vom Team arbeitstäglich die erledigten Tasks bekanntgegeben, der verbleibende Restaufwand wird dann im Burn Down Chart markiert.
4.3 Das Burn Up Chart
Es ist in agilen Projekten üblich, dass sich die Menge an Tasks im Verlauf immer ändert. Das Burn Down Diagramm kann diesen Umstand nicht berücksichtigen, daher ...