Metriken sind ein sensibles Thema.

Einerseits haben wir alle schon an einem Projekt gearbeitet, bei dem keinerlei Daten nachverfolgt wurden und es schwer zu sagen war, ob wir Kurs auf das Release halten oder im weiteren Verlauf effizienter werden. Andererseits hatten viele von uns das Pech, an Projekten mitzuarbeiten, bei denen Statistiken als Waffe missbraucht wurden, um ein Team gegen das andere auszuspielen oder obligatorisches Arbeiten am Wochenende zu rechtfertigen. Deshalb überrascht es nicht weiter, dass die meisten Teams eine Art Hassliebe zu Metriken hegen.

Aber das muss nicht so sein. Das Nachverfolgen und Teilen robuster agiler Metriken kann Unklarheiten ausräumen und den Fortschritt (und Rückschläge) des Teams während des Entwicklungszyklus verdeutlichen. Sehen wir uns das genauer an.

Das Geschäft kennen

"Erledigt" ist nur die halbe Wahrheit. Es geht darum, das richtige Produkt zum richtigen Zeitpunkt für den richtigen Markt zu entwickeln. Wenn ein Team während eines gesamten Programms auf Kurs bleiben will, muss es auf dem Weg einige Daten erfassen und analysieren. In einem agilen Programm müssen sowohl geschäftliche als auch agile Metriken nachverfolgt werden. Bei geschäftlichen Metriken liegt der Schwerpunkt darauf, ob die Lösung Marktanforderungen erfüllt, und agile Metriken messen Aspekte des Entwicklungsprozesses. 

Die geschäftlichen Metriken eines Programms sollten in der Roadmap verankert sein.

Jede Initiative in der Roadmap sollte über mehrere Key Performance Indicators (KPIs) verfügen, die den Zielen des Programms zugeordnet sind. Darüber hinaus müssen Erfolgskriterien für jede Produktanforderung wie die Akzeptanzrate bei Endbenutzern und der Prozentsatz des durch automatisierte Tests abgedeckten Codes vorhanden sein. Diese Erfolgskriterien werden in die agilen Metriken des Programms aufgenommen. Je mehr Teams lernen, umso besser können sie sich anpassen und weiterentwickeln. 

So nutzt du agile Metriken für die Optimierung deiner Bereitstellung

Bei den unten dargestellten agilen Metriken liegt der Schwerpunkt auf der Bereitstellung von Software. Ganz gleich ob dein Team mit Scrum- oder Kanban-Verfahren arbeitet, wird jede dieser agilen Metriken dazu beitragen, dass das Team den Entwicklungsprozess besser versteht, was wiederum das Releasen von Software vereinfacht.

Sprint Burndown

Scrum-Teams organisieren die Entwicklung in Timebox Sprints. Zu Beginn des Sprints prognostiziert das Team, wie viel Arbeit es während eines Sprints abschließen kann. Der Abschluss der Arbeit während des Sprints wird dann in einem Sprint-Burndown-Bericht nachverfolgt. Auf der x-Achse ist die Zeit dargestellt und auf der y-Achse die Menge der Aufgaben, die noch abgeschlossen werden müssen, gemessen in Story Points oder Stunden. Ziel ist, alle prognostizierten Aufgaben bis zum Ende des Sprints zu erledigen.

Ein Team, das seine Prognosen konsistent erfüllt, ist eine wirkungsvolle Werbung für den Einsatz agiler Methoden im Unternehmen. Das sollte dich aber nicht in die Versuchung bringen, bei den Zahlen zu schummeln, indem ein Element als erledigt erklärt wird, bevor das tatsächlich der Fall ist. Das mag kurzfristig gesehen gut aussehen, verhindert langfristig aber einen Lern- und Verbesserungsprozess.  

>> Möchtest du das Ganze mal ausprobieren? Übe mit diesem interaktiven Tutorial.

Anti-Pattern, die vermieden werden sollten

  • Das Team erledigt nahezu alle Sprints vorzeitig, da es nicht genug Aufgaben übernommen hat. 
  • Das Team hält die Prognose über mehrere Sprints nicht ein, da es zu viele Aufgaben auf sich genommen hat. 
  • Die Burndown-Linie sinkt an einigen Stellen stark ab statt graduell, weil die Aufgaben nicht granular aufgeteilt wurden.
  • Der Product Owner erweitert oder ändert den Umfang mitten im Sprint.

Epic und Release Burndown

In Epic- und Release- (oder Version-) Burndown-Charts wird der Fortschritt der Entwicklung über einen größeren Aufgabenbereich als beim Sprint Burndown nachverfolgt. Sie können sowohl in Scrum- als auch Kanban-Teams als Hinweis auf den Ablauf der Entwicklung verwendet werden. Da ein Sprint (für Scrum-Teams) möglicherweise Aufgaben aus mehreren Epics und Versionen enthält, muss sowohl der Fortschritt einzelner Sprints als auch der Fortschritt von Epics und Versionen nachverfolgt werden.

Als "Scope Creep" wird die Einschleusung weiterer Anforderungen in ein zuvor definiertes Projekt bezeichnet. Wenn das Team beispielsweise eine neue Website für das Unternehmen bereitstellt, bedeutet Scope Creep, dass nach Festlegung der anfänglichen Anforderungen neue Features verlangt werden. Scope Creep während eines Sprints sollte nicht toleriert werden, während eine Änderung des Umfangs in Epics und Versionen eine natürliche Konsequenz der agilen Entwicklung ist. Wenn das Team das Projekt weiter durchläuft, entscheidet der Product Owner möglicherweise, Aufgaben auf Basis der bisherigen Erfahrungen hinzuzufügen oder zu entfernen. Mithilfe der Epic- und Release-Burndown-Charts werden Ebbe und Flut der Aufgaben in Epics und Versionen verdeutlicht. 

Anti-Pattern, die vermieden werden sollten

  • Epic- oder Release-Prognosen werden nicht aktualisiert, während das Team die Aufgaben abarbeitet.
  • Über einen Zeitraum mehrerer Iterationen wird kein Fortschritt erzielt. 
  • Es kommt zu einem chronischen Scope Creep, was möglicherweise darauf hinweist, dass der Product Owner das Problem, das mit dieser Kernaufgabe gelöst werden soll, nicht vollständig versteht.
  • Der Umfang wächst schneller, als das Team ihn arbeiten kann.
  • Das Team liefert während der Entwicklung eines Epic keine inkrementellen Releases aus.

Velocity

Die Velocity wird durch die durchschnittliche Menge der Aufgaben definiert, die ein Scrum-Team während eines Sprints erledigt, gemessen in Story Points oder Stunden. Diese Metrik ist sehr nützlich für die Prognose. Der Product Owner kann mit der Velocity prognostizieren, wie schnell ein Team das Backlog abarbeiten kann, da in dem Bericht die prognostizierten und erledigten Arbeiten über mehrere Iterationen hinweg nachverfolgt werden – je mehr Iterationen, desto präziser wird die Prognose.

Sagen wir, der Product Owner möchte 500 Story Points im Backlog abschließen. Wir wissen, dass das Entwicklerteam in der Regel 50 Story Points pro Iteration bearbeitet. Der Product Owner kann also ziemlich sicher davon ausgehen, dass das Team 10 Iterationen (ungefähr) benötigt, um die erforderliche Arbeit abzuschließen.

Es sollte unbedingt überwacht werden, wie sich die Velocity über die Zeit entwickelt. In neuen Teams kann eine Steigerung der Velocity erwartet werden, solange das Team Beziehungen und den Arbeitsprozess optimiert. Vorhandene Teams können ihre Velocity nachverfolgen, um eine konsistente Performance über die Zeit zu sichern. Anhand der Velocity können sie zudem erkennen, ob eine bestimmte Prozessänderung Verbesserungen gebracht hat oder nicht. Ein Rückgang der durchschnittlichen Velocity ist normalerweise ein Zeichen, dass ein Teil des Entwicklungsprozesses des Teams ineffizient geworden ist und bei der nächsten Retrospektive besprochen werden sollte.

Anti-Pattern, die vermieden werden sollten

Wenn die Geschwindigkeit über einen langen Zeitraum schwankt, sollten die Schätzungsverfahren des Teams überprüft werden. Stelle während der Retrospektive des Teams die folgenden Fragen:

  • Sind unvorhergesehene Entwicklungsherausforderungen aufgetreten, die wir bei der Schätzung dieser Aufgaben nicht berücksichtigt haben? Wie können wir Aufgaben besser unterteilen, um diese Herausforderungen zu erkennen?
  • Gibt es Druck von außen, der das Team an seine Grenzen bringt? Können deshalb Best Practices für die Entwicklung nicht eingehalten werden?
  • Sind wir als Team übereifrig, wenn wir den Sprint prognostizieren? 

Die Geschwindigkeit jedes Teams ist einzigartig. Eine Geschwindigkeit von 50 in Team A und von 75 in Team B bedeutet nicht, dass der Durchsatz in Team B höher ist. Da jedes Team eine einzigartige Schätzungskultur einsetzt, ist auch die Geschwindigkeit in jedem Team unterschiedlich. Deshalb solltest du keinesfalls die Geschwindigkeit unterschiedlicher Teams vergleichen. Aufwand und Ausgabe von Aufgaben sollten auf der Basis der in jedem Team einzigartigen Interpretation von Story Points gemessen werden. 

Kontrollchart

In Kontrollcharts wird die Durchlaufzeit einzelner Vorgänge erfasst – d. h. die Gesamtdauer vom Status "Laufend" bis zum Status "Erledigt". Teams mit kürzeren Durchlaufzeiten haben wahrscheinlich einen höheren Durchsatz, während Teams mit konsistenten Durchlaufzeiten über viele Vorgänge hinweg ihre Arbeit auf eine vorhersehbarere Weise bereitstellen. Die Durchlaufzeit ist eine primäre Metrik für Kanban-Teams, aber auch Scrum-Teams können von einer optimierten Durchlaufzeit profitieren.

Das Messen der Zykluszeit ist ein effizientes und flexibles Mittel für die Optimierung eines Teamprozesses, weil die Ergebnisse von Änderungen nahezu unmittelbar erkennbar sind. So können sofort weitere Anpassungen vorgenommen werden. Das Endziel besteht darin, eine konsistente und kurze Durchlaufzeit zu erreichen, unabhängig von der Art der Arbeit (neues Feature, technische Schulden usw.).

Anti-Pattern, die vermieden werden sollten

Kontrollcharts können anfangs unbeständig erscheinen. Beschäftige dich nicht so sehr mit jedem Ausreißer, sondern achte auf Trends. Hier sind zwei Bereiche, auf die du achten solltest:

  • steigende Durchlaufzeit: Eine steigende Durchlaufzeit untergräbt die hart verdiente Agilität des Teams. Nehmt euch in der Retrospektive des Teams Zeit, um eine Steigerung zu verstehen. Eine Ausnahme: Wenn die Definition von "Erledigt" des Teams erweitert wurde, verlängert sich wahrscheinlich auch die Durchlaufzeit.
  • schwankende Durchlaufzeit: Das Ziel ist, eine konsistente Durchlaufzeit für Aufgabenelemente mit ähnlichen Story-Point-Werten zu erreichen. Filtere das Kontrollchart nach einzelnen Story-Point-Werten, um die Konsistenz zu überprüfen. Wenn die Durchlaufzeit bei kleinen und großen Story-Point-Werten schwankt, solltet ihr in der Retrospektive die Abweichungen untersuchen und die zukünftige Schätzung verbessern. 

Kumulatives Flussdiagramm

Das kumulative Flussdiagramm ist eine wichtige Ressource für Kanban-Teams, mit der sichergestellt werden kann, dass der Arbeitsfluss im gesamten Team konsistent ist. Mit der Anzahl der Vorgänge auf der x-Achse, der Zeit auf der y-Achse und Farben, die die verschiedenen Workflow-Status anzeigen, bietet es einen visuellen Hinweis auf Mängel, Engpässe und Arbeiten im Zusammenhang mit WIP-Grenzen.

Das kumulative Flussdiagramm sollte von links nach rechts (relativ) ausgeglichen aussehen. Blasen oder Lücken in einer Farbe weisen auf Mängel und Engpässe hin. Wenn du solche siehst, suche nach Möglichkeiten, die Farbstreifen über das Diagramm auszugleichen.

Anti-Pattern, die vermieden werden sollten

  • Blockierende Vorgänge führen zu großen Stauungen in einigen Teilen des Prozesses und zu Mängeln in anderen.
  • Unkontrolliertes Backlog-Wachstum über die Zeit. Dieses wird dadurch verursacht, dass Product Owner Vorgänge nicht schließen, die veraltet sind oder eine so geringe Priorität haben, dass sie gar nicht erst bearbeitet werden. 

Noch mehr Metriken!

Gute Metriken sind nicht auf die oben erwähnten Berichte begrenzt. Qualität ist beispielsweise eine wichtige Metrik für agile Teams, und es gibt eine Reihe herkömmlicher Metriken, die für die agile Entwicklung angewendet werden können:

  • Wie viele Fehler werden gefunden ...
    • während der Entwicklung?
    • nach dem Release an Kunden?
    • von Personen außerhalb des Teams?
  • Wie viele Fehler werden auf ein zukünftiges Release verschoben?
  • Wie viele Kundensupportanfragen gehen ein?
  • Wie hoch ist der Prozentsatz der automatisierten Testabdeckung?

Agile Teams sollten sich außerdem die Release-Häufigkeit und die Bereitstellungsgeschwindigkeit ansehen. Am Ende jedes Sprints sollte das Team ein Software-Release zur Produktion bereitstellen. Wie oft geschieht das tatsächlich? Werden die meisten Release-Builds ausgeliefert? Wie lange dauert es, bis das Team eine Notfallkorrektur zur Produktion bereitstellt? Ist ein Release für das Team einfach oder sind Heldentaten erforderlich?

Metriken sind nur ein Teil des Aufbaus einer Teamkultur. Sie ermöglichen einen quantitativen Einblick in die Performance des Teams und stellen messbare Ziele für das Team bereit. Sie sind zwar wichtig, aber du solltest es nicht übertreiben. Um das Vertrauen im Team, die Produktqualität und die Entwicklungsgeschwindigkeit während des Release-Prozesses zu steigern, ist es ebenso wichtig, auf das Feedback des Teams in Retrospektiven zu hören. Nutze sowohl das quantitative als auch das qualitative Feedback, um Änderungen voranzubringen. 

Dargestelltes Produkt
Jira Software-Logo
Projekt- und Vorgangsnachverfolgung