Hinter jedem Projekt stehen Stakeholder. Zumindest ein Auftraggeber, einerlei, ob es sich um einen externen Kunden oder einen internen Stakeholder handelt. Beide stellen Ressourcen zur Verfügung, Budget und/oder Personal/Maschinen. Die Stakeholder haben die Anforderung, dass über die Ressourcenverwendung berichtet werden muss.
Ein Projektbericht hat auch den Zeitaspekt zu berücksichtigen:
- Wie lange werden die Ressourcen noch benötigt?
- Wie lange reicht das Budget noch?
Der Zeitaspekt kommt aus der Langfristplanung. Gerade die Langfristplanung ist in agilen Projekten schwierig, da mit vielen Anforderungsänderungen im Projektverlauf zu rechnen ist. Sonst hätte man gleich die klassische Vorgehensweise gewählt.
In SCRUM ist der aktuelle Sprint im Detail geplant. Für die folgenden Sprints wird die Planung mehr und mehr zu einer Schätzung, je weiter der Sprint in der Zukunft liegt. Die Detailplanung des jeweils aktuellen Sprints bildet den Ausgangswert für das Controlling. Somit findet das Controlling immer von Sprint zu Sprint statt, der realisierte Arbeitsumfang des vorhergegangenen Sprints übt hier einen Einfluss aus (siehe Abb. 2). Das hört sich erstmal sehr aufwendig an, ist aber im Endeffekt ein schlankeres Controlling, als man dieses von klassischen Projekten gewohnt ist. Der Grund für das schlankere Controlling liegt in der Vorauswahl der zu realisierenden User Stories im sogenannten Sprint Planning. Während des Sprint Plannings werden aus dem Pool der User Stories (Product Backlog) die für den nächsten Sprint ausgewählt. Im Sprint Planning können auch die erst kürzlich eingetroffenen Änderungswünsche einfließen. Hier werden die User Stories ausgewählt die:
- den größten Kundennutzen versprechen,
- mit den zur Verfügung stehenden Ressourcen zu schaffen sind,
- sowie deren Realisierungsrisiko (unerwartet hohe Komplexität, unerwartet hoher Aufwand) beherrschbar sind.
Abb. 2: Detailplanung der Sprints inkl. Einfluss des vorangegangenen Sprints
Im klassischen Controlling können die kürzlich eingetroffenen Änderungswünsche nur durch einen relativ hohen Change-Request-Aufwand einfließen. Jedes Mal muss der zeitliche und finanzielle Aufwand, sowie die darin innewohnende Risiken abgeschätzt und genehmigt werden. Nach der Genehmigung muss der gültige Projektzeitplan angepasst und aktualisiert werden.
Die nachfolgende Tabelle erläutert, in welchem Meeting (Sprint Planning, Sprint, Sprint Review & Retrospektive) welche Kennzahlen für das Controlling verwendet werden können:
| Meeting | Kennzahl | Kurzerläuterung | Wird wo/wann gemessen? |
|---|---|---|---|
| Sprint Planning | Story Points | Wird durch das Team bspw. mittels Planungspoker eingeschätzt. | Sprint Backlog |
| Kritikalität des Risikos in jeder User Story | Produkt aus der Einschätzung von Eintrittswahrscheinlichkeit und Auswirkung. Beide werden zur Vereinfachung in Klassen eingeteilt (1-5) | Product Backlog | |
| Velocity | Arithmetisches Mittel der in den vergangenen Sprints abgearbeiteten Story Points. Achtung: Zwingende Voraussetzungen sind hier ein konstantes Team während der gesamten Projektdauer und eine stets gleiche Sprintdauer. | Schätzung im ersten Sprint, sonst Sprint Backlog | |
| Budget at Completion | Summe der Story Points der User Stories im Product Backlog. Dividiert durch die Velocity ergibt die geschätzte Anzahl der notwendigen Sprints. Budget at Completion geteilt durch die Anzahl an Sprints ergibt das gleichverteilte Budget. Achtung: In einem Sprint mit vielen User Stories mit hoher Risikokritikalität ist zu dem gleichverteilten Budgetanteil noch ein Contingency-Zuschlag sinnvoll. | Product Backlog | |
| Sprint | Progress | Wird im Sprint durch den Burn Down oder Burn Up Chart ermittelt. | Sprint Backlog |
| Impediment (Hindernisse) | Aktualisierung und Abarbeitung des Impediment Backlogs durch den Scrum Master. Üblicherweise im Daily Scrum Meeting. | Sprint Backlog | |
| Qualität | Anzahl der Ergebnisse aus den User Stories welche die Testphase nicht erfolgreich bestehen. | Sprint Backlog | |
| Sprint Review & Retrospektive | Story Points | Differenz der geplanten Story Points zu den geleisteten Story Points pro Sprint | Sprint Backlog |
| Velocity | Neuberechnung und Analyse der Velocity nach jedem Sprint. In der Anfangsphase des Projektes soll die Velocity ansteigen und sich dann nur noch wenig verändern. | Sprint Backlog | |
| Budget | Hochrechnung des benötigten Budgets und Vergleich mit dem geplanten Budget. Zur Ermittlung des benötigten Budgets werden die Kennzahlen der EVA herangezogen. | Sprint Backlog | |
| Risiken | Identifikation und ggf. Neubewertung der Risiken in den User Stories für den nächsten Sprint. | Sprint Backlog | |
| EVA | Ermittlung der Kennzahlen der Earned-Value-Analyse. Erweiterung der Earned-Value-Werte durch Story Points. | Sprint Backlog | |
| Qualität | Vergleich und Analyse der Qualitätszahlen des letzten Sprints mit den vorhergegangenen Sprints. | Sprint Backlog | |
| Kundenzufriedenheit | Messung der Kundenzufriedenheit bspw. durch Erfüllung der Akzeptanzkriterien. | Sprint Backlog | |
| Mitarbeiterzufriedenheit | Abfrage in der Retrospektive bzw. anonymisierte Zufriedenheitsabfrage. | Spr... |
Das ist nur ein Ausschnitt aus dem Produkt Haufe Finance Office Premium. Sie wollen mehr?
Jetzt kostenlos 4 Wochen testen
Anmelden und Beitrag in meinem Produkt lesen