Fünf agile KPI-Metriken, die dir gefallen werden

Zusammenfassung: Agile Metriken liefern Einblicke zur Produktivität in den unterschiedlichen Phasen des Softwareentwicklungszyklus. Dies erleichtert die Beurteilung der Produktqualität und die Nachverfolgung der Teamleistung.

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.

"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.

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.

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.

Weitere Informationen zur Verwendung von Burndown-Charts in Jira

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 Produktinhaber 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.

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.

Die Velocity jedes Teams ist einzigartig. Eine Velocity 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 etabliert hat, ist auch die Velocity in jedem Team unterschiedlich. Deshalb solltest du keinesfalls die Velocity unterschiedlicher Teams miteinander vergleichen. Aufwand und Ausgabe von Aufgaben sollten auf der Basis der in jedem Team einzigartigen Interpretation von Story Points gemessen werden.

In Kontrollcharts wird die Durchlaufzeit einzelner Vorgänge erfasst – d. h. die Gesamtdauer vom Status "In Bearbeitung" 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 Durchlaufzeit 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.).

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.

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?