Warum Metriken?
In einem wirklich agilen Umfeld misst man idealerweise den Outcome der Arbeit eines Teams wie z.B. eine Verbesserung der Conversion oder neu gewonnen Marktanteile (vgl. "Alle machen heute Scrum - oder doch nicht?"). Die meisten Organisationen sind aber noch nicht so weit und messen Entwicklungs-Teams eher an ihrem Output, d.h. der geleisteten Arbeit (z.B. Velocity). Nimmt man eine optimale Priorisierung nach Value als gegeben an ist das sogar ein sehr guter Indikator für den Erfolg eines Teams. Ist man in einem solchen Umfeld unterwegs ist es immer noch besser, die "falschen" Metriken richtig zu erheben als sie gar nicht zu berücksichtigen und komplett im Blindflug unterwegs zu sein. Viele Daten helfen darüber hinaus, Zusammenhänge im Prozess zu verstehen und experimentelle Prozess-Anpassungen objektiv zu bewerten.
Essentiell ist dabei vor allem: Die Werte von Metriken zu verbessern sollte nie das Ziel sein, sondern Metriken können dabei helfen den Weg zum eigentlichen Ziel - wie auch immer es aussieht - besser zu verstehen (vgl. "An Appropriate Use of Metrics" von Martin Fowler). Sie aus Transparenz-Gründen zu erheben und gemeinsam daraus Erkenntnisse zu gewinnen ist der Schlüssel zum Erfolg, sei es als Früh-Indikator oder um subjektive Einschätzungen zu untermauern bzw. zu widerlegen.
Dinge, die wir gerne messen
Es gibt kein definiertes Set an "wichtigen" Kennzahlen die jedes Team erheben sollte. Die richtigen Metriken und Darstellungen zu finden ist schon Teil des Prozesses, der im Team entstehen muss. Dennoch sind hier - vor allem zur Inspiration - einige praxiserprobte Beispiele aufgeführt. Wichtig ist zu verstehen, dass jede Metrik ihre spezifischen Stärken und möglichen Erkenntnisse, aber auch Schwächen und Grauzonen hat. Fast überall sind vor allem Langzeit-Trends interessant - einzelne Ausreißer kann und sollte man sich beispielsweise im Rahmen der Retro ansehen, allerdings eher um die Ursachen zu verstehen und nicht um einen Einzelfall zum Problem zu machen. Ein Gesamtbild ergibt sich dabei nur, wenn man verschiedene Perspektiven miteinander verbindet und ganzheitlich analysiert. Es ist unmöglich, alles was in einem Team passiert auf ein paar automatisch berechenbare Kennzahlen zu reduzieren.
Hinweis: Alle hier dargestellten Daten sind fiktiv, nicht in sich konsistent und häufig unrealistisch plakativ um die Struktur der Diagramme einfach zu erklären. Allen Charts liegen exemplarisch die Prozessphasen Plan (detaillierte technische Konzeption), Implement (Code + Tests schreiben), Review (funktional + Code Review) und Test (fachliche Verifikation) zugrunde.
Burnup
Der Scrum-Klassiker ist das Burndown-Diagramm, wir verwenden allerdings eher ein Burnup wenn diverse Kanban-Elemente (Spillover und Nachrücker bzw. Scope-Trades in einem vernünftigen Umfang sind vom Kunden in manchen Projekten explizit gewünscht) mit in den Prozess einfließen. Diese lassen sich unserer Erfahrung nach in einem Burnup leichter visualisieren, da z.B. eine zusätzlich in den Scope aufgenommene Story nicht alle anderen Phasen im Flowchart verschiebt. Liegt der Fokus dagegen - enger angelehnt an Scrum - auf der restlosen Abarbeitung des fixen Sprint Backlogs ist ein Burndown meist die bessere Wahl.
- Ein Gesamtvolumen von rund 80 SP ist für den Sprint veranschlagt. Allerdings sind die Spillovers schon zu weiten Teilen abgearbeitet (nur noch Review und Test).
- Spillovers befinden sich bereits zu Beginn des Sprints in Bearbeitung bzw. sind am Ende noch nicht "Done".
- Es ist gut ersichtlich, wie die großen Stories im Laufe des Sprints durch alle Phasen des Prozesses (anfangs viel Planung, am Ende viel Review und Test) wandern.
- ungeplanter Aufwand am 03.01., hier wurde viel Zeit in einen schwerwiegenden Prio-1-Bug investiert.
- Nachrücker im Scope am 11.01.
- Beide zum Zeitpunkt des Plannings nicht bekannten Erweiterungen des Backlogs führen zu deutlich sichtbaren Anstiegen des Gesamt-Scopes.
Mögliche Erkenntnisse
- Fortschritts-Indikator im laufenden Sprint
- Bottlenecks im Prozess identifizieren
Fallstricke
- Umgang mit Spillover
- Visualisierung von ungeplanten Aufwänden
Durchlaufzeit Histrogramm
Ebenfalls ein Standard-Chart, dieses Mal aus der Kanban-Welt. Zu sehen ist, wie viele Tickets in welcher Zeit alle Phasen des Prozesses durchlaufen.
- Viele sehr kleine Tickets, das sind häufig Bugs.
- Weiterer Peak bei 4 Tagen, das scheint die Wunschgröße für leicht zu schneidende Arbeitspakete zu sein.
- Der Rest ist innerhalb der Sprint-Dauer von 2 Wochen weitgehend normalverteilt.
- Zahlreiche Ausreißer mit weit über 10 Tagen müssen einzeln analysiert werden.
Mögliche Erkenntnisse
- Prognose für zukünftige noch ungeschätzte Tickets
- Identifikation von Ausreißern um aus deren Ursachen zu lernen
Fallstricke
- Ticket-Typen sind in der einfachsten Variante nicht ersichtlich
- Schätzung für die Größe der Tickets (falls vorhanden) nicht erkennbar
Durchlaufzeit / Estimate Scatter Plot
Sofern mit Schätzungen gearbeitet wird ist es wichtig zu wissen, inwieweit diese zutreffend sind. Die klassische Visualisierung dafür ist ein Scatter Plot. Sofern Daten über die Ist-Aufwände erhoben werden (z.B. wie viel Arbeitszeit tatsächlich in den einzelnen Prozess-Phasen anfällt) kann die Durchlaufzeit durch diese tatsächlich angefallene Arbeit ersetzt werden. Das eliminiert die aufgeführten Fallstricke weitestgehend.
- Mittelmäßige Schätzgenauigkeit (Korrelation >0,5 ist für derartige Daten sehr gut).
- Die Regressions-Gerade ist deutlich flacher als eine Linie durch den Nullpunkt - offenbar gibt es strukturelle Schätzfehler, die kleine Stories überschätzen.
- Es gibt in beide Richtungen extreme Ausreißer, die im Einzelnen analysiert werden müssen. Bei unterschätzten Tickets ist dabei stets der Unterschied zwischen Warte- und Arbeitszeit zu berücksichtigen.
Mögliche Erkenntnisse
- Bewertung der allgemeinen Schätzgenauigkeit
- Identifikation von Ausreißern um aus den Fehleinschätzungen zu lernen
- Erkennen von strukturellen Schätzfehlern
Fallstricke
- Liegezeiten haben nichts mit dem geschätzten Aufwand zu tun
- Bei Pair Programming oder anderen Formen der Parallelisierung steigt der Aufwand, aber nicht die Durchlaufzeit
Ticket-Durchsatz
Eine der einfachsten denkbaren Metriken: Wie viele Tickets von welchem Typ werden pro Sprint fertig?
- Die Zahl der Stories schwankt recht stark, vermutlich aufgrund der jeweiligen Größe (das ist in anderen Metriken ersichtlich).
- Die Anteile der anderen Ticket-Typen sind ebenfalls nicht konstant, aber eine übliche Größenordnung ist erkennbar.
Mögliche Erkenntnisse
- Verteilung der Ticket-Typen
- Identifikation von Trends und Ausreißern zur genaueren Analyse
Fallstricke
- Anzahl der Tickets sagt nichts über die zugehörigen Aufwände
- Umgang mit Spillover
Aufwandsverteilung
Um beurteilen zu können, wo das Team seine Arbeitszeit investiert, ist die Aufwandsverteilung wesentlich interessanter als die Anzahl der Tickets. Dafür muss jedes Ticket quantifiziert werden, je nach Verfügbarkeit der Daten entweder mit Hilfe von Schätzungen (ex-ante) oder tatsächlich angefallen Aufwänden (ex-post).
- Die idealisiert dargestellte Wunschverteilung liegt bei 70% Stories, 10% Bugs, 10% Improvements, 5% Analysen, 5% Infrastruktur.
- In den ersten beiden Sprints gab es erhöhten Analyse-Aufwand zulasten der Stories.
- In Sprint 6 gab es auffällig viele Bugs zulasten der Stories.
Mögliche Erkenntnisse
- Abgleich der investierten Arbeitszeit mit Budgets und Zielen des Kunden
- Identifikation von Trends und Ausreißern zur genaueren Analyse
Fallstricke
- Umgang mit Spillover
Wo Tickets ihre Zeit verbringen
Eine weitere Dimension neben den Ticket-Typen sind die einzelnen Prozess-Schritte. Sofern Ist-Aufwände für die einzelnen Prozess-Phasen gemessen werden ist es sehr interessant zu sehen, wie sich der Gesamt-Aufwand pro Sprint auf diese verteilt. Wir machen das mit Punkten auf die Task-Zettel im Daily und verwenden diese "Dots" als tatsächlich angefallenen Aufwand.
- Die typische Aufteilung zwischen Planning, Implementierung und Review scheint 1:2:1 zu sein.
- Impediments tauchen immer wieder auf, in den letzten beiden Sprints sehr stark. Das muss untersucht werden.
- In Sprint 5 ist der Anteil von "Waiting for Review" auffällig hoch. Was ist hier passiert?
- In Sprint 6 war der Aufwand für Reviews fast genauso hoch wie für die Implementierung. Was ist hier passiert?
Mögliche Erkenntnisse
- Abgleich der investierten Arbeitszeit mit Überlegungen bei der Prozess-Definition
- Identifikation von Trends und Ausreißern zur genaueren Analyse
Fallstricke
- Umgang mit Spillover
Velocity
Eine der Standard-Scrum-Metriken ist die Velocity, also wie viele Story Points das Team pro Sprint fertigstellen kann.
- Die typische Lieferleistung liegt zwischen 30 und 45 Story Points.
- In Sprint 6 gab es einen auffälligen Ausreißer bei den ungeschätzten Tickets, vermutlich eine Häufung von Bugs.
- In der ersten Hälfte des betrachteten Zeitraums scheint die Performance stetig abzunehmen.
Mögliche Erkenntnisse
- Prognose des Durchsatzes
- Identifikation von Trends und Ausreißern zur genaueren Analyse
Fallstricke
- Anteil der durch unterschiedliche Team-Anwesenheit erklärbaren Schwankungen unklar
- Umgang mit Spillover
Relative Velocity / Anwesenheit
Die größte Schwäche einer bloßen Velocity-Betrachtung ist das Ignorieren von Anwesenheits-Schwankungen. Die Relative Velocity normalisiert die Daten diesbezüglich, indem sie die fertig gestellten Story Points durch die Gesamt-Anwesenheit in PT teilt. Wir kombinieren diese Kennzahl gerne mit der absoluten Anwesenheit um gegenseitige Einflüsse leichter zu erkennen.
- Die relative Velocity schwankt relativ konstant um den Wert 0,5.
- Die typische Anwesenheit liegt zwischen 70 und 80 PT.
- In Sprint 4 und 5 war offenbar Urlaubszeit. Die Velocity sinkt in dieser Zeit obwohl die relative Velocity sehr gleichmäßig ist.
Mögliche Erkenntnisse
- Genauere Prognose des Durchsatzes sofern die Anwesenheit vor Sprint-Beginn bekannt ist
- Identifikation von Trends uns Ausreißern zur genaueren Analyse
Fallstricke
- Ursache von Trends (Änderung der Performance, Änderung der Schätz-Skala, ...) nicht trivial zu finden
- Relative Velocity als "Umrechnungsfaktor" für den Aufwand einzelner Stories in PT zu ermitteln macht keinen Sinn; nur langfristig heben sich Unsicherheiten bei der Schätzung auf
Anwesenheit / Velocity Scatter Plot
Eine weitere Möglichkeit um den Zusammenhang zwischen Anwesenheit und Velocity besser zu verstehen ist ein Scatter Plot.
- Die Korrelation zwischen Anwesenheit und Velocity ist sehr deutlich. Eine recht genaue Prognose des zukünftigen Durchsatzes ist also möglich.
- Die Regressions-Gerade geht fast durch den Nullpunkt. Es scheint also sehr wenig Overhead bzw. versteckte Arbeit zu geben - oder diese skaliert nahezu perfekt mit Anwesenheit und Velocity.
Mögliche Erkenntnisse
- Genauere Prognose des Durchsatzes sofern die Anwesenheit vor Sprint-Beginn bekannt ist
Fallstricke
- Trends sind hier nicht erkennbar, da eine Zeitachse fehlt
Anwesenheit / Relative Velocity Scatter Plot
Auf Basis der gleichen Daten kann auch die Relative Velocity verwendet werden. Dieses Diagramm macht vor allem Sinn, wenn die Skalierbarkeit im Rahmen eines Ramp-Ups untersucht werden soll. Wird das Team zu groß steigt der Overhead und die relative Velocity sinkt. Das sollte im Fall von Problemen am rechten Rand des Charts und durch die negative Steigung der Regressions-Geraden ersichtlich sein.
- Die relative Velocity ist sehr gleichmäßig bei etwa 0,5.
- Es ist keine Korrelation mit der Anwesenheit erkennbar. Das Team skaliert also im aktuellen Rahmen problemlos.
Mögliche Erkenntnisse
- Bewertung der Skalierbarkeit eines Teams
- Analyse der optimalen Team-Größe
Fallstricke
- Trends sind hier nicht erkennbar, da eine Zeitachse fehlt
Warum noch ein individuelles Tool und nicht z.B. JIRA Plug-Ins?
Unser Ziel ist es gerade nicht ein weiteres Standard-Tool, das einige vordefinierte Kennzahlen liefert, einzusetzen oder vorzuschlagen. Entscheidend ist, gemeinsam mit dem Team im jeweiligen Kontext wertvolle Metriken zu entwickeln und auszuprobieren. Und genau das ist der ideale Use Case für die von uns eingesetzten Google Spreadsheets: sie sind leichtgewichtig, einfach anpassbar, und wo nötig dennoch extrem mächtig (z.B. durch Skripte). Wenn eine Metrik doch nicht den gewünschten Mehrwert bringt hat man eben ein paar Minuten verschwendet - aber nicht mit viel Aufwand ein Feature in eine komplexe Software eingebaut oder ein teures Plugin für Standard-Software gekauft.
Bleibt die Frage nach dem Datenschutz. Natürlich muss die Compliance im konkreten Fall geprüft werden - grundsätzlich sind die für Kennzahlen benötigten Daten ohne Kontext aber kaum interpretierbar. Beispielsweise sind kryptische Ticket-Nummern und deren Durchlaufzeit in der Regel keine Geschäftsgeheimnisse und viel mehr ist nicht nötig um quasi beliebige Metriken zu berechnen.
Wie funktioniert das Setup im Detail?
In der konkreten Umsetzung sind der Kreativität kaum Grenzen gesetzt. Mit den folgenden Grundbausteinen haben wir gute Erfahrungen gemacht.
Ein Sheet pro Sprint
Da viele Daten pro Sprint aggregiert werden macht es Sinn, die Rohdaten in je einem Sheet pro Sprint abzulegen. Aus Effizienz-Gründen gibt es für dieses Sheet natürlich ein Template, das man nur duplizieren und mit den eigentlichen Daten füllen muss. Hinterlegt sind dabei die gewünschten Eckdaten wie z.B. die Anwesenheit oder Spillover aus dem letzten Sprint. Die wichtigste Informationen sind aber die in der Iteration bearbeiteten Tasks, typischerweise mit einer Zeile pro Backlog Item. Relevante Spalten sind der Ticket-Typ (Story, Bug, ...), Start- und Enddatum und idealerweise noch Informationen über die Verweildauer in den einzelnen Prozessschritten und geschätzte sowie tatsächliche Aufwände. Zumindest im ersten Schritt sollten nur die ohnehin vorhandenen Informationen gesammelt werden ohne neue Bürokratie einzuführen. Wenn wichtige Daten fehlen wird sich das im weiteren Verlauf zeigen.
Ein "Current Sprint" Sheet
Hier werden alle Charts abgelegt die sich nur auf den laufenden Sprint beziehen. Typischerweise ist hier das Burndown-/Burnup-Diagramm zu finden.
Ein "Moving Metrics" Sheet
Gerade bei Diagrammen ohne Zeitachse ist es wichtig, die Daten frei von zu alten Informationen zu halten. Dennoch ist ein Sprint als Betrachtungshorizont häufig zu kurz - stattdessen bietet sich ein an den Moving average angelehntes Verfahren an, das immer die letzten n Sprints berücksichtigt. Typische Kandidaten für dieses Sheet sind das Durchlaufzeit Histogramm und der Scatter Plot für die Schätzgenauigkeit. Idealerweise aggregiert man die hier verwendeten Diagrammen noch einmal auf einzelne Kennzahlen, die dann im nächsten Sheet langfristig getrackt werden können um Trends zu erkennen. Für die Schätzgenauigkeit ist beispielsweise der zugehörige Korrelationskoeffizient ein gutes Maß.
Ein Sheet für langfristig aggregierte Daten
Hier findet man alle Diagramme mit Zeitachse bzw. einzelnen Datenpunkten pro Sprint, um langfristige Trends und Entwicklungen erkennen zu können. Spätestens hier empfiehlt sich der Einsatz von INDIRECT um beim Hinzufügen eines weiteren Sprints nur eine neue Zeile mit dem Namen des zugehörigen Sheets in Spalte A einfügen zu müssen. Betrachten wir Zeile 50 und beinhaltet Spalte B die Anwesenheit, welche in Zelle X42 des Sprint-Sheets zu finden ist, so kann darauf mit =INDIRECT("'"A50&"'!X42") zugegriffen werden. Analog natürlich für alle anderen Kennzahlen. Aus der resultierenden und in der Regel sehr großen Tabelle können dann alle Einzel-Charts erzeugt werden ohne auf andere Sheets zugreifen zu müssen.
Google Script zur Automatisierung
Das klingt alles wahnsinnig kompliziert - wir brauchen aber höchstens ein paar Minuten pro Tag, um alle nötigen Daten im Spreadsheet zu pflegen! Einmal aufgesetzt geht dank Google Script fast alles von selbst. Ein besonders praktisches und in unseren Reports immer wieder auftauchendes Pattern ist die automatische Erzeugung von Flowcharts aus Daten die stets den aktuellen Wert zeigen - hier erklärt am Beispiel des oben beschrieben Burnups:
- Ausgangslage: Das Sprint-Sheet enthält zu jedem Zeitpunkt die Zahl der Story Points, die sich gerade in den einzelnen Prozessphasen (Open, Plan, Implement, ...) befinden. Für das Burnup braucht man diese Daten historisiert pro Tag des Sprints.
- Im "Current Sprint" Sheet wird zu Beginn das Startdatum des Sprints eingetragen - alle anderen Tage (exklusive Wochenende) können automatisch mit einfachen Formeln berechnet werden. Damit sind alle Zeilen bekannt.
- Pro Prozessschritt gibt es nun eine Spalte - der jeweils aktuelle Wert dafür wird (erneut mit INDIRECT) aus dem Sprint-Sheet in die "Aktuelle Werte" Zeile übertragen.
- Die zum heutigen Datum zugehörige Zeile lässt sich leicht automatisiert finden. Eine Funktion im Google Script liest die Daten aus "Aktuelle Werte" ein und kopiert sie in diese Zeile.
- Diese Funktion hat zwei Trigger: Erstens bei jeder Änderung am Spreadsheet. Und zweitens einmal pro Tag zu einer festen Zeit falls es keine Anpassungen gibt und das Flowchart einfach nur "fortgeschrieben" werden soll. Dadurch wird jeden Tag die zugehörige Zeile auf den gerade aktuellen Stand gebracht und im weiteren Verlauf des Sprints nicht mehr angefasst.
- Auf Basis dieser sich selbst erweiternden Tabelle das Flowchart zu erstellen ist mit einem "Gestapelten Flächendiagramm" trivial.
Natürlich gibt es unzählige weitere Use Cases für Google Script, z.B. automatische Reports via E-Mail oder was auch immer sonst gewünscht ist.
Anbindung von fremden APIs als Datenquelle
Besonders spannend ist die automatische Integration von APIs um auch die Rohdaten automatisiert zu erheben. In der Atlassian-Welt kann beispielsweise die JIRA REST API angezapft werden um den aktuellen Status aller Tickets im laufenden Sprint zu extrahieren. Selbstverständlich muss man sich hier mit Authentication Tokens etc. beschäftigen, allerdings lohnt sich die Mühe um die manuelle Synchronisation der in der Regel schon digital vorhandenen Daten zu vermeiden. Eine detaillierte Beschreibung unserer technischen Umsetzung würde den Rahmen dieses Artikels sprengen - die genaue Implementierung mit ein paar Zeilen JavaScript ist in der Praxis ohnehin für jedes Projekt völlig anders.
Fazit
Es gibt viele Möglichkeiten, um Transparenz in agilen Teams zu schaffen. Richtig eingesetzt können Metriken dabei sehr wertvoll sein, auch wenn es kein Patent-Rezept gibt welche Zahlen erhoben werden sollten. Im Vordergrund sollte stets der Erkenntnisgewinn und die Verbesserung der bestehenden Prozesse stehen: Wo keine Bewertung einer Änderung möglich ist fehlen möglicherweise die nötigen Kennzahlen.
Eine Möglichkeit um sehr leicht unzählige Arten von Diagrammen zu erstellen bieten Google Spreadsheets, die sich auch auf einem fortgeschrittenen Level stets an die aktuellen Anforderungen anpassen lassen - inklusive maximaler Automatisierung. Eine von vielen Möglichkeiten ein solches Spreadsheet zu strukturieren ist in diesem Artikel beschrieben, wir sind aber sehr neugierig alternative Ansätze zu diskutieren. Ob für Anregungen, Diskussionen, Fragen oder Unterstützung in laufenden oder zukünftigen Projekten: Erfahren Sie mehr über Lean & Agile bei comSysto und kontaktieren Sie uns!