Agile Metriken richtig nutzen: was messen, was nicht, und wie interpretieren

Wozu dienen agile Metriken?

Agile Teams arbeiten empirisch: Sie treffen Entscheidungen auf Basis dessen, was sie beobachten. Metriken machen diese Beobachtungen messbar und vergleichbar über die Zeit. Sie beantworten Fragen wie: Wie lange dauert es typischerweise, bis ein Eintrag fertig ist? Wie viel schaffen wir pro Woche? Wo bleibt Arbeit hängen? Liefern wir tatsächlich Wert? Der Scrum Guide nennt Burn-downs, Burn-ups und kumulative Flussdiagramme als bewährte Praktiken zur Prognose, betont aber, dass sie die Bedeutung von Empirie nicht ersetzen: In komplexen Umfeldern ist unbekannt, was geschehen wird, und nur Vergangenes kann für vorausschauende Entscheidungen genutzt werden ^[1].

Entscheidend ist der Zweck. Metriken, die dem Team helfen, seine Arbeitsweise zu verbessern, wirken. Metriken, die von aussen zur Bewertung genutzt werden, werden schnell verzerrt: Teams optimieren dann die Kennzahl statt das Ergebnis. Dieses Muster ist so verbreitet, dass es als Goodharts Gesetz bekannt ist: Wird eine Kennzahl zum Ziel, verliert sie ihre Aussagekraft.

Welche Arten von agilen Metriken gibt es?

Ein ausgewogenes Bild entsteht erst aus mehreren Kategorien. Ein Team mit hohem Durchsatz, aber vielen Fehlern nach der Auslieferung arbeitet nicht gut. Ein Team mit perfektem Burn-up, dessen Ergebnisse niemand nutzt, liefert keinen Wert. Bewährt hat sich, aus jeder Kategorie eine oder zwei Metriken auszuwählen und diese regelmässig gemeinsam zu betrachten.

Was zeigen Flussmetriken?

Der Kanban Guide definiert vier minimale Flussmetriken: Work in Progress, Durchsatz, Work Item Age und Cycle Time ^[2]. Sie eignen sich nicht nur für Kanban-Teams, sondern auch für Scrum Teams, weil sie den tatsächlichen Arbeitsfluss beschreiben, unabhängig von Schätzungen. Die Durchlaufzeit wird sinnvollerweise als Verteilung betrachtet, etwa mit der Aussage, dass der Grossteil der Einträge innerhalb einer bestimmten Zahl von Tagen fertig wird. Einzelne Ausreisser zeigen, wo Arbeit ungewöhnlich lange hängen blieb.

Das kumulative Flussdiagramm stellt für jeden Tag dar, wie viele Einträge sich in welchem Schritt befinden. Der vertikale Abstand zwischen den Linien zeigt die laufende Arbeit, der horizontale Abstand die ungefähre Durchlaufzeit und die Steigung den Durchsatz. Wird ein Band breiter, staut sich Arbeit in diesem Schritt. Wie Flussmetriken erhoben werden, beschreibt der Beitrag Kanban einführen.

Wie wird Velocity richtig genutzt?

Velocity ist die Summe der Story Points oder Einträge, die ein Scrum Team in einem Sprint fertigstellt. Sie dient dem Team als Planungsgrundlage: Wie viel können wir im nächsten Sprint realistisch übernehmen, und wie lange dauert der Backlog bis zu einem Release? Für diesen Zweck ist sie nützlich, besonders als Durchschnitt über mehrere Sprints mit Bandbreite. Ein Beispiel zur Releaseprognose zeigt der Beitrag Agile Schätzverfahren.

• Velocity nicht zwischen Teams vergleichen: Story Points sind teamspezifisch.
• Velocity nicht als Ziel vorgeben: Teams schätzen dann grösser, ohne mehr zu liefern.
• Nur fertige Einträge zählen: halbfertige Arbeit nach Definition of Done zählt nicht.
• Schwankungen nicht überbewerten: Ferien, Krankheit und Unterbrechungen beeinflussen jeden Sprint.
• Trend statt Einzelwert betrachten: Ein stabiler Durchschnitt über sechs Sprints ist aussagekräftiger als der letzte Wert.

Burn-up oder Burn-down?

Das Burn-down-Chart zeigt die verbleibende Arbeit über die Zeit und eignet sich für einen Sprint mit festem Umfang. Das Burn-up-Chart zeigt zwei Linien: die erledigte Arbeit und den gesamten geplanten Umfang. Es ist für Releases und Projekte meist aussagekräftiger, weil es Änderungen am Umfang sichtbar macht. Steigt die Linie des Gesamtumfangs schneller als die der erledigten Arbeit, rückt das Ende in die Ferne, und der Auftraggeber muss über Umfang oder Termin entscheiden. Mehr dazu im Glossar unter Burn-up-Chart.

Wie misst man, ob Arbeit Wert stiftet?

Fluss- und Fortschrittsmetriken zeigen, wie gut ein Team liefert, aber nicht, ob das Gelieferte etwas bewirkt. Dafür braucht es Ergebnismetriken, die vom Produkt abhängen: Nutzung neuer Funktionen, Zeitersparnis bei den Nutzenden, weniger Supportanfragen, höhere Zufriedenheit oder Fortschritt auf ein Product Goal. Sie sind schwieriger zu erheben, aber entscheidend, um die Frage zu beantworten, ob sich die Arbeit lohnt. Im Sprint Review sollten sie regelmässig besprochen werden, damit die Priorisierung auf tatsächlicher Wirkung beruht.

Beispiel: Ein schlankes Team-Dashboard

Ein solches Dashboard ist klein genug, um regelmässig betrachtet zu werden, und deckt die wichtigsten Kategorien ab. Jede Kennzahl hat einen festen Platz in einem Event, sodass sie nicht nur angezeigt, sondern tatsächlich genutzt wird. Für die Teamebene kommt eine kurze Zufriedenheitsabfrage in der Retrospektive hinzu.

Welche Fallstricke gibt es bei agilen Metriken?

Metriken aus dem Werkzeug statt aus Tabellen

Metriken sind nur so gut wie ihre Daten. Werden Start- und Enddaten von Einträgen automatisch im Projekttool erfasst, lassen sich Durchlaufzeiten, Durchsatz und Alter ohne Zusatzaufwand auswerten. In Flenio werden Statuswechsel von Aufgaben und erfasste Zeiten im Projekt gespeichert, sodass Auswertungen direkt aus der täglichen Arbeit entstehen. Für die klassische Steuerung ergänzen Budgetverbrauch und Earned Value das Bild, siehe Projektstatus objektiv bewerten. Den Gesamtzusammenhang zeigt der Leitfaden Agiles Projektmanagement in der Praxis.

Was sagen Standards zur Leistungsmessung?

Auch klassische Standards betonen, dass Messung der Steuerung und dem Lernen dient. Die achte Auflage des PMBOK Guide ordnet Messung und Steuerung dem Fokusbereich Monitoring and Controlling zu und betont die Ausrichtung auf Wert statt auf reine Aktivität ^[3]. Für agile Teams bedeutet das: Metriken sollen helfen, früh zu erkennen, ob ein Vorhaben auf Kurs ist und Wert liefert, nicht dokumentieren, wie beschäftigt ein Team ist.

Wie führen Sie Metriken im Team ein?

1. 1Mit einer Frage beginnen, nicht mit einer Kennzahl: Was wollen wir besser verstehen, etwa warum Arbeit so lange dauert?
2. 2Eine oder zwei Metriken auswählen, die diese Frage beantworten, etwa Durchlaufzeit und Alter laufender Arbeit.
3. 3Daten automatisch erheben, damit kein Zusatzaufwand entsteht.
4. 4Einen festen Ort festlegen, an dem die Metrik betrachtet wird, etwa die Retrospektive.
5. 5Nach einigen Wochen prüfen, ob die Metrik zu besseren Entscheidungen geführt hat, und sie sonst ersetzen.

Dieses Vorgehen verhindert, dass ein Team mit einem überladenen Dashboard startet, das niemand liest. Es stellt sicher, dass jede Metrik einen Zweck hat und tatsächlich genutzt wird. Wenn das Team selbst entscheidet, welche Metriken es nutzt, steigt zudem die Bereitschaft, sie ehrlich zu interpretieren, statt sie zu schönen.

Für Führungskräfte gilt: Fragen Sie Teams nicht nach ihrer Velocity, sondern danach, was sie aus ihren Metriken gelernt haben und welche Hindernisse sie bremsen. Diese Fragen fördern Lernen und Transparenz; die Frage nach Zahlen fördert deren Optimierung.

Beispiel: Eine Metrik richtig interpretieren

Ein Team stellt fest, dass seine durchschnittliche Durchlaufzeit in zwei Monaten von sechs auf zehn Arbeitstage gestiegen ist. Statt das Team zu mehr Tempo aufzufordern, schaut es genauer hin: Das kumulative Flussdiagramm zeigt, dass sich Einträge in der Spalte «Wartet auf Freigabe» stauen, und das Alter der laufenden Einträge ist dort am höchsten. Die Ursache liegt nicht im Team, sondern in einer neuen Freigaberegel, die zusätzliche Prüfungen verlangt. Das Team bespricht das mit dem Product Owner, und gemeinsam wird ein festes Freigabefenster vereinbart. Nach vier Wochen sinkt die Durchlaufzeit wieder.

Das Beispiel zeigt, warum Metriken Fragen auslösen sollen statt Urteile. Die steigende Durchlaufzeit war kein Zeichen schlechter Arbeit, sondern ein Hinweis auf eine Veränderung im Umfeld, die ohne Messung lange unbemerkt geblieben wäre.