Fortschrittskontrolle, Metrics und Performancemessung in Scrum Projekten

Wo steht die Produktentwicklung genau?; Warum gibt es Verzögerungen?; Welche Kosten sind angefallen?; Ist die Wirtschaftlichkeit noch gegeben? Wann ist der Release-Zeitpunkt?
Fragen, die auch im Rahmen von Produktentwicklungen nach Scrum berechtigt sind und für die Stakeholder eine Antwort einfordern.

Scrum ist ein empirischer, inkrementeller und iterativer Ansatz zur agilen Entwicklungen von Produkten und Dienstleistungen. Der Scrum Guide¹ führt aus, dass dieser Ansatz auf Transparenz, Überprüfung und Anpassung basiert.

Transparenz ist nicht nur für das Team zur Selbststeuerung wichtig sondern auch zur Kommunikation des Fortschritts gegenüber dem Management und anderen relevanten Stakeholdern. Transparenz bildet die Voraussetzung für Vertrauen und Akzeptanz. Und Vertrauen ist im Rahmen von Scrum ein wesentlicher Faktor.

Transparenz ist nicht nur für das Team zur Selbststeuerung wichtig sondern auch zur Kommunikation des Fortschritts gegenüber dem Management und anderen relevanten Stakeholdern. Transparenz bildet die Voraussetzung für Vertrauen und Akzeptanz. Und Vertrauen ist im Rahmen von Scrum ein wesentlicher Faktor.

Der Informationsbedarf und die Sicht auf den Fortschritt einer Produktentwicklung variiert von Stakeholder zu Stakeholder. Während das Entwicklungsteam zur Selbststeuerung feiner aufgelöste Informationen benötigt, interessiert das Management unter anderem eher die Frage nach dem Releasetermin und den Kosten, um rechtzeitig und erfolgreich mit dem Produkt oder der Dienstleistung am Markt zu sein. 

Die Informationen darüber müssen über ein geeignetes Kommunikationsinstrument, mit zielgruppenorientierten Inhalten und der richtigen Frequenz an die jeweiligen Stakeholder gelangen.

Ein Berichtswesen, das den Fortschritt regelmäßig dokumentiert und kommuniziert ist erforderlich.

Dafür stehen unterschiedliche Instrumente, Metriken und Vorgehensweisen zur Verfügung.

Instrumente

Agile Roadmaps

Eine agile Roadmap ist ein agiler lebender Plan mit Aktivitäten, der aufzeigt wie sich ein Produkt oder eine Lösung über die Zeit entwickelt. Das ist kein klassischer Projektplan im herkömmlichen Sinne. Vielmehr ist es ein strategischer Blick, ein big picture, auf das worauf die Produktentwicklung mittelfristig bis langfristig hinausläuft. Damit gibt eine Road Map Orientierung, oftmals über die nächsten 12 Monate. Eine Road Map ist mit der Vision und der strategischen Zielsetzung des Unternehmens abgestimmt.

Road Maps werden von Product Ownern erstellt und visualisieren wann größere Bereiche von Produktfunktionalitäten und  Produktmerkmale verfügbar sein werden (als Epics, Themes). Dabei werden sowohl Marktentwicklungen, Wertangebote und technische Einschränkungen bei der Gestaltung der Roadmap einbezogen. Road Maps eignen sich daher auch gut für die Kommunikation und Abstimmung des Vorhabens mit den Stakeholdern auf Top-Level-Ebene. Die Road Map ist aufgrund der agilen Vorgehensweise ein lebendes Dokument, das regelmäßig aber nicht zu oft aktualisiert werden muss.

Beispiel für eine agile Roadmap (Quelle: In Anlehnung an Atlassian⁴)

Burndown Chart - Epics

Epics umfassen Arbeitsumfänge die viele User Stories enthalten können und durchaus eine komplette Teilfunktionalität des Produkts oder Service abbilden. Die Bereitstellung eines Epics erfolgt in der Regel über mehrere Sprints. Die agile Natur der Produktentwicklung über Scrum führt dazu, dass User Stories hinzukommen oder aber auch gestrichen werden können.

Burndown Charts können hier genutzt werden, um die Abarbeitung von Epics zu visualisieren. Man erkennt wie sich der Fortschritt entwickelt, aber auch an welcher Stelle neue User Stories vom Product Owner hinzugefügt oder gestrichen wurden.

Auch dieses Chart eignet sich für die Kommunikation mit den Stakeholdern zur Fortschrittsdarstellung.

Beispiel für ein Epic Burndown Chart (Quelle: In Anlehnung an Atlassian⁴)

Burndown Chart - Innerhalb eines Sprints

Ein Burndown Chart stellt den verbleibenden Aufwand in der Entwicklung des Produkts oder Service in Abhängigkeit der Zeit dar. Damit lassen sich Aussagen treffen, wann die Arbeit vollständig erledigt sein wird bzw. zu welchem Zeitpunkt dies eintreten wird.

Beispiel für ein Burndown Chart für eine abgeschlossene Iteration (Quelle: Wikipedia²)

Taskboard

Um den Sprint Backlog zu visualisieren kann das Taskboard eingesetzt werden. Auf dem Taskboard werden die für den Sprint ausgewählten Product Backlog Einträge (Anforderungen), die zugehörigen Aufgaben (ToDo’s) und der Bearbeitungszustand dargestellt.

Beispiel für ein Taskboard

Team Performance – Velocity

Die Geschwindigkeit (oder Velocity) in Scrum  kennzeichnet wie viele Aufgaben innerhalb eines Sprints von einem Team abgearbeitet werden kann. Über die Zeit werden Teams i.d.R. immer produktiver und die Team Performance steigt. Daher ist die Beobachtung wie viele Aufgaben innerhalb eines Sprints abgearbeitet werden können gerade auch für die Teams selbst von Bedeutung, um ein Gespür/Vorhersagegenauigkeit dafür entwickeln zu können wann bestimmte Funktionen zur Auslieferung fertig sind.

Die Anzahl der Story Points für eine User Story kennzeichnet deren Größe und Komplexität. Betrachtet man nun die Anzahl der erledigten User Stories (Done) je Sprint über mehrere Sprints hinweg, so lässt sich eine durchschnittliche Geschwindigkeit bestimmen. Damit lassen sich geplante Fertigstellungen von User Stories prognostizieren, die ggf. auch für Releaseplanungen genutzt werden können.

Beispiel für ein Chart zur Darstellung der Velocity des Teams in der Abarbeitung von User Stories (Story Points) über die Zeit (Sprints).

Vorgehensweisen und Metrics

Berichtswesen – Organisation und Rollen

Auch bei einer agilen Produktentwicklung nach Scrum sind bestimmte organisatorische Rahmenbedingungen, hier das Berichtswesen betreffend, wichtig.

Ein zentrales Steuerungsgremium, hier z.B. ein Lenkungsausschuss als Entscheidungs- und Eskalationsinstanz der in wöchentlicher Frequenz tagt, hilft eskalierte Impediments rasch zu beseitigen, welche das Scrum Team nicht selbst auflösen kann.

Besetzt ist ein solches Gremium mit entscheidungskompetenten Stakeholdern, z.B. Leiter der Entwicklung, Produktmanagement, Vertrieb, Geschäftsführer und ggf. weiteren relevanten Stakeholdern.

Wer berichtet im Lenkungsausschuss? Der Product Owner trägt die wirtschaftliche Verantwortung für das zu entwickelnde Produkt oder Dienstleistung. Konsequenter Weise ist er auch für das Reporting des Projektfortschritts und der wirtschaftlichen Kennzahlen zuständig. In der Praxis ist ist der Product Owner nicht immer nahe genug am Geschehen, d.h. nahe am Scrum Entwicklungsgeschehen, um Fehlentwicklungen rasch genug zu erkennen.  Entgegen der reinen Lehre von Scrum wird deshalb schon mal der Scrum Master als Reporting-Verantwortlicher vorgeschlagen (siehe hierzu auch Dr. Sefan Barth, Agile Controlling – aussagekräftiges Berichtswesen für agile Organisationen³ )

Berichtswesen – Metrics

Welche Berichtsinhalte sollten im Lenkungsausschuss vorgestellt werden? Die auszuwählenden Metrics hängen immer von der jeweiligen Situation ab.

Kennzahlen können unterschiedlich interpretiert werden. Wichtig ist ausreichend Begleit- und Hintergrundinformation zur jeweiligen Kennzahl zu Verfügung zu stellen, um falsche Interpretationsrichtungen zu vermeiden. Gegebenenfalls auch weitere Kennzahlen und Daten heranziehen, um die richtigen Schlüsse zu ziehen. Aus Kennzahlen, die sich aus gemessenen Daten herleiten, sollten sich Maßnahmen ableiten lassen, um Prozesse weiter zu optimieren.

Hier ist jedoch Augenmaß gefordert. So eignet sich z.B. die Velocity nicht unbedingt als KPI (Key Performance Indikator) der zur Steigerung der Teamgeschwindigkeit eingesetzt werden sollte. Schätzt das Team künftig vorsichtiger, kann die Velocity steigen.

Hilfreiche Metrics (Auswahl)

Burn-Down Chart

• Der Total Burndown: zeigt auf, wie viel Aufwand aus dem initial geplanten Aufwand pro Sprint abgearbeitet werden kann
• Zugefügt - Added Work: zeigt auf, wie viele Änderungen (Zugefügte User Stories - Scope creeping),  sich durchschnittlich pro Sprint ergeben haben.
• Team Burndown: zeigt auf, wie viel Aufwand das Team tatsächlich abgearbeitet hat, inkl. der zugefügten User Stories.

Bisher angefallener Aufwand

• Anzahl Stunden für Scrum Master, Entwickler, Architekt etc. Erfordert von allen Beteiligten eine Zeitaufschreibung für die betreffende Produktentwicklung

Restaufwand - Schätzung des verbleibenden Aufwands

Prognose des nächsten Releasezeitpunkts (Zieldatum)

Erledigte Story Points pro Sprint

Geplante Story Points pro Sprint

Entwicklung der Prognosegenauigkeit des Teams

• Geschätzter Aufwand dividiert durch angefallenen Aufwand in Prozent

Aktuelle Velocity vs. prognostizierter/geplanter Velocity

Anzahl entdeckter Fehler

• Während der Entwicklung
• Nach dem Release
• Zurückgestellt für nächstes Release
• Fehlerschwere (z.B. nach Kritisch, Erheblich, Gering)

Aktuelle Kosten (interne Mitarbeiterverrechnungskosten zzgl. direkte Kosten)

Budget (Ursprüngliche Schätzung durch Experten)

Plankosten (Aktuelle Kosten + Restaufwand)

Aktueller Status (z.B. auch als Ampel), Impediments, Risiken, Maßnahmen, nächste Schritte

Fazit

Transparenz schafft Vertrauen. Vertrauen ist Voraussetzung für Akzeptanz. Die regelmäßige zielgruppenorientierte Kommunikation und Darstellung des Entwicklungsfortschritts an die relevanten Stakeholder kann diese Transparenz herstellen.

Quellen,  interessante, weiterführende und vertiefende Artikel

• ¹ Der Scrum Guide, Ken Schwaber, Jeff Sutherland, November 2020
• ² Scrum, Wikipedia, https://de.wikipedia.org/wiki/Scrum
• ³ Agile Controlling – aussagekräftiges Berichtswesen für agile Organisationen, Projektmagazin, 05/2015, Dr. Stefan Barth
    https://www.projektmagazin.de/artikel/agile-controlling-aussagekraeftiges-berichtswesen-fuer-agile-organisationen_1097683
• ⁴ Five agile metrics you won't hate, Atlassian, https://www.atlassian.com/agile/metrics