(Scr-)Earned Value – Scrum is already reliable!

Die Arbeit in einem Scrum-Kontext befreit einen in der Regel nicht von der klassischen Kunden-Dienstleister-Situation. Hier entsteht fast immer die Situation, die jeder Projektverantwortliche kennt. Bei einem regelmäßigen Treffen mit dem Kunden, will dieser wissen: „Können Sie mir sagen, wie weit das Projekt gediehen ist und kann der Kostenrahmen, den wir vereinbart haben, noch eingehalten werden?“
Eine Frage, die fast jedem Projektleiter den Schweiß auf die Stirn treibt.

Hier bietet einem im klassischen Projektmanagement die Earned Value Analyse die passenden Antworten. Dazu berechnet man aus den bereits umgesetzten Tasks im Verhältnis zur Gesamtanzahl der Aufgaben den Fertigstellungsgrad. Mit diesem kann dann der Fortschritt gemessen werden und in Kombination mit den geplanten Gesamtkosten die zu erwartenden Projektkosten.

„SCRUM ist doch ein unplanbares Werkzeug!“

Dies bringt uns aber auch gleich zum Problem: Scrum kennt auf Planungsebene – also im Product Backlog – keine Tasks, sondern lediglich Features, häufig in User-Stories festgehalten. Damit kann man über die Time-Box des Sprints hinaus vermeintlich keine weiteren Aussagen machen, wenden viele Scrum Kritiker ein. Manche gehen dabei soweit, Scrum als völlig unplanbares Werkzeug anzusehen, bei dem keine Prognosen über Fertigstellung des Projekts und Umfang getätigt werden können. Aber tun sie das zu Recht? Oder müssen dazu gar neue Elemente erdacht werden, um ein „Reliable SCRUM“ erst realisieren zu können?

 

Viel hilft viel... oder etwa doch nicht?
Viel hilft viel… oder etwa doch nicht?

Um es kurz zu sagen: Man benötigt keine Hilfsmittel, die erst ersonnen werden müssen. Scrum kommt mit genügend Bordmitteln ausgestattet daher, die einem helfen, Kunden die gewünschten Informationen zu liefern.

Wie kann ich den Fortschritt im Projekt messen?

Ausgangspunkt ist wie so oft das Meeting zur Sammlung und zur Bewertung von Backlog Items – das Product Backlog Refinement Meeting. Hier werden die Elemente des Release Backlogs erfasst, mit Risiken bewertet und geschätzt. Mit dieser ersten Schätzung kann dann bereits wunderbar gearbeitet werden.

Beim Lesen wird dem ein oder anderen sicher sogleich der Einwand auf der Zunge liegen: „Das ändert sich im Laufe des Releases doch laufend.“ Das stimmt durchaus und zum gegenwärtigen Zeitpunkt kann man auch nur eine Aussage auf Basis des aktuellen Wissensstands machen. Das ist aber kein Alleinstellungsmerkmal von Scrum sondern betrifft auch alle klassisch organisierten Projekten. Denn Projekte unterliegen nun mal dem festen Gesetz des kontinuierlichen Wandels – egal ob klassisch oder agil.

Nehmen wir ein Beispiel:

In unserem Backlog Refinement Meeting haben wir für das Release 31 Backlog Items in Form von User Stories als Features gesammelt, die aus Sicht des Product Owners für das Release relevant sind. Dabei haben wir zehn Einträge mit 5 Story Points (SP) ermittelt, ebenfalls zehn Stories mit 3SP, fünf mit 8SP und sechs mit 13SP.

In welcher Form der Umfang des Product Backlogs gesammelt wird, bleibt letztlich jedem Team selbst überlassen. Ob in Arbeitstagen oder in Story Points, die lediglich die Komplexität von Features abbilden ist für das Vorgehen hier eher zweitrangig. Allerdings zeigt die Erfahrung, dass relative Werte wie Story Points auf Basis der Methode von Barry W. Boehm mithilfe der Fibonacci-Folge besser funktionieren, da sich die meisten Menschen damit leichter tun, sich an einem Vergleichswert zu orientieren und relativ dazu zu schätzen als absolute Aufwandswerte in Tagen anzugeben. (Literaturtipp: Software Engineering Economics, Barry W Boehm)

Nun haben wir unsere Backlog Items (vermutlich in den meisten Fällen User Stories) gesammelt und geschätzt. Diese Summe verwenden wir als 100% unserer umzusetzenden Features, die wir am Ende des Releases fertig stellen wollen. Am Ende eines jeden Sprints kann man mit den Ergebnissen aus dem Sprint Review Meeting die geschätzten Story Points der bereits umgesetzten User Stories addieren und hat den aktuellen Fertigstellungswert. Diesen setzten wir zum Gesamtwert ins Verhältnis und haben unseren Fertigstellungsgrad in Prozent. Damit kannen man auf die erste der beiden Kundenfragen bereits eine Antwort liefern.

Kehren wir zu unserem Beispiel zurück:

Angenommen wir befinden uns am Ende des fünften Sprints und haben bisher zusammen drei Stories mit 13SP, sechs mit 5SP fertig gestellt. Dazu noch vier mit 3SP und fünf mit 8SP.

    \[ Summe = 3*13SP+6*5SP+4*3SP+5*8SP = 121SP \]

Ergibt also einen

    \[ Fertigstellungsgrad = \frac{121SP}{198SP}*100= 61,11% \]

von rund 60% Fertigstellungsgrad – eine exaktere Angabe ist meines Erachtens mit Vorsicht genießen und für den Kunden reicht es in der Regel allemal.

Nun obliegt es unserem persönlichem Geschmack, wie häufig wir den Fertigstellungsgrad messen wollen. Am einfachsten geht dies natürlich am Ende eines Sprints. Bei regelmäßiger Aktualisierung kann man die Daten dann in ein Excel-Diagramm fließen lassen wie dieses Beispielhafte auf Wochenbasis:

Verlauf Fertigstellungsgrad mit steigender IST-Kurve
Verlauf Fertigstellungsgrad

Und wie teuer wird nun das Projekt?

Um eine Antwort auf die zweite Kundenfrage liefern zu können, nähern wir uns über die ersten Sprints hinweg einem  in der Regel immer verlässlicheren Wert an:

Am Ende eines jeden Sprints erhalten wir die Information, wie viel Story Points das Team dabei erreichen konnte. Nach zwei bis drei Sprints kann man hier einen durchaus verlässliches Ergebnis erwarten, mit dem man jonglieren kann. Davor sind Schwankungen in den Forecasts an der Tagesordnung und wenig aussagekräftig. Ab diesem Zeitpunkt hat man damit in Kombination mit dem im Sprint verbrauchten Aufwandstagen ein Verhältnis von Aufwand und Story Points.

Mit diesem Verhältnis zwischen Story Point und Aufwand in Personentagen ist es ein Leichtes, die Gesamtkosten zu berechnen. Dazu nehmen wir die in den Sprints verbrauchten Aufwände, teilen diese durch die Anzahl der bereits umgesetzten Storypoints und multiplizieren dies mit der Gesamtanzahl der zu erwartenden Storypoints des Releases.

In unserem Beispiel sähe das dann so aus:

In den fünf vergangenen Sprints haben die 5 Personen im Team insgesamt 241PT (AC = Actual Cost) gebucht, die auf das Projekt anfielen. Dabei haben sie von der Gesamtsumme 198SP (PV = Planned Value) wie bereits ermittelt 121SP (EV = Earned Value) an Features umgesetzt. Vorausgesetzt, dass die Geschwindigkeit genauso voranschreitet, ergibt sich der zu erwartende Release-Aufwand (EAC = Estimation at Completion) folgendermaßen:

    \[ EAC = \frac{AC}{EV}*PV = \frac{241PT}{121SP}*198SP = 396PT \]

Auch dieses Ergebnis kann man sich schön als Diagramm in regelmäßigen Abständen abtragen und gegen ein eventuelles Initialbudget vergleichen, wie im folgenden Fall:

Verlauf der Gesamtkosten über die Zeit
Verlauf – Zu erwartende Gesamtkosten (EAC) im Verlauf des Projekts

Wie man im Beispiel gut erkennen kann, schwankten die zu erwartenden Kosten in der Anfangsphase des Projekts erheblich, bis sich das Team das Themenfeld erschlossen hatte und anfängliche Infrastrukturhemmnisse überwunden waren.

Scrum ist ein verlässliches Mittel in der Projektsteuerung

Man kann deutlich erkennen, dass man auch mit bereits bekannten Mitteln innerhalb von Scrum-basierten Projekten Aussagen über Projektfortschritt und Kostenerwartung treffen kann, die fundiert und reliable sind.

Es steht natürlich mit einem Kunden und/oder respektive einem Product Owner, der eine klare Vorstellung von seinem Produkt hat und Team-Mitarbeitern, die umfangreiche Erfahrung in ihrem Job haben und den Aufwand für Features möglichst treffsicher schätzen können.

Letztlich sind die beteiligten Personen für den Erfolg eines Projekts der Schlüssel und weniger die Arbeitsmethode – aber auch das ist den meisten IT-Projektleitern ein nicht unbekanntes Thema, spätestens seit Barry W. Boehms Standardwerk COCOMO II.

Template

Ein Template, um die hier erwähnte Methode direkt im eigenen Projekt auszutesten und einzusetzen haben wir natürlich auch bereit gestellt. Einfach downloaden und loslegen!

Template für Earned Value Analys in agilen Projekten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.