Agile Metriken und KPIs

Für agile Teams ist es wichtig, den Fortschritt des Teams zu verfolgen und zu überwachen, um zu sehen, wie die Anforderungen in ein funktionierendes Produkt umgesetzt werden. Key Performance Indicators (KPIs) sind Indikatoren, die zeigen, wie gut ein Projekt läuft. 

Verwandte Methoden und Techniken zu agilen Metriken und KPIs

  • Abbrand- und Ausbrandtabelle

    1. Abbrand- und Ausbrandtabelle

    Burndown- oder Burnup-Diagramme zeigen, wie viel Arbeit bereits erledigt wurde und wie viel Arbeit im Verlauf der Iteration noch übrig ist.

    Burndown- und Burnup-Diagramm stellen die gleichen Daten auf unterschiedliche Weise dar. Die Teams wählen aus, wie sie ihre Daten sehen möchten.

    Manche Teams kombinieren Burndown- und Burnup-Diagramme in einem Diagramm. Das Diagramm zeigt die verbleibenden aktuellen Story Points sowie die abgeschlossenen kumulativen Story Points.

  • Geplante versus tatsächliche Geschwindigkeit

    2. Geplante versus tatsächliche Geschwindigkeit

    Planned versus Actual Velocity ist ein Prognosetool, das auf der beobachteten und tatsächlichen Leistung basiert. Das Team kann dem Kunden mitteilen, ob es das Backlog der User Stories in der geplanten Anzahl von Iterationen fertigstellen wird oder nicht.

    Geplante vs. tatsächliche Velocity ist ein Vorhersageinstrument, das auf Beobachtungen und tatsächlicher Leistung basiert. Es ermöglicht dem Team, dem Kunden mitzuteilen, ob es das Backlog der User Stories vor der geplanten Anzahl von Iterationen abschließen wird.

    Die Plangeschwindigkeit ist die Erwartung des Teams an die Story-Punkte, die in jeder Iteration geliefert werden sollen. Tatsächliche Geschwindigkeit bezieht sich auf die tatsächliche Summe der Story Points, die sie in jeder Iteration geliefert haben.

  • Parkplatzkarte

    3. Parkplatzkarte

    Das Parkplatzdiagramm stellt den Fortschritt eines Teams bei der Fertigstellung von Story Points für eine Veröffentlichung dar.
    Die visuellen Informationen des Parkplatzes sind für die Verfolgung und Diagnose nützlich.

  • Kleines Gesetz

    4. Littlesches Gesetz

    Das Little'sche Gesetz besagt, dass die Größe einer Warteschlange (die Anzahl der Artikel im WIP-Status) proportional zur Dauer der Zeit in der Warteschlange ist. Daher besteht das Ziel von Lean und Agile darin, die Zykluszeiten auf ein Minimum zu reduzieren.

    WIP-Limits verhindern, dass das Team zu viel Arbeit auf sich nimmt und Engpässe aufdeckt. Teams erledigen ihre Arbeit schneller, indem sie die Menge der in Arbeit befindlichen Aufgaben begrenzen.

    Die Beziehung zwischen WIP und Zykluszeit wird durch die folgende Gleichung ausgedrückt

    Unfertige Erzeugnisse (WIP) = Durchlaufzeit * Durchsatz

    Die Vorlaufzeit für einen Prozess ist gleich der Anzahl der auszuführenden Aufträge geteilt durch die durchschnittliche Zeit für die Ausführung jedes Auftrags

  • Kanban-Tafel

    5. Kanban-Tafel

    Kanban-Tafeln sind Schautafeln. Kanban (japanisch - "Karten, die man sehen kann") ist ein Pull-System, bei dem die Ressourcen verhindern, dass sich die Arbeit in einem begrenzten Prozess stapelt, so dass die Vorlaufzeit für die Lieferung von Werten an das Unternehmen nicht beeinträchtigt wird. Die Arbeit auf der Kanban-Tafel bewegt sich von links nach rechts, und in jeder Phase des Projekts kann nur eine begrenzte Anzahl von Elementen bearbeitet werden. Die Teams sind diszipliniert und verpflichten sich, innerhalb ihrer festgelegten Work-in-Progress (WIP)-Grenzen zu arbeiten, um einen optimalen Fluss im System zu gewährleisten.

  • Zykluszeit und Vorlaufzeit

    6. Zykluszeit und Vorlaufzeit

    Die Durchlaufzeit gibt an, wie lange es dauert, bis ein Workitem den gesamten Prozess durchläuft. Die Zykluszeit ist eine Teilmenge der Durchlaufzeit. Die Zykluszeit ist die Zeit, die ein Workitem benötigt, um einen Teil des Prozesses zu durchlaufen (z. B. vom Status "In Bearbeitung" zum Status "Erledigt", von der Codierungsphase zur Testphase, Abschluss einer Aufgabe).

    Es gibt verschiedene Strategien zur Lösung von Durchlaufzeit- und Zykluszeitproblemen, z. B. die Steigerung der Systemeffizienz, die Erhöhung der Kapazität (Absturz) und die Einstellung der Bedarfsdeckung (nicht immer möglich).

  • Kumulatives Flussdiagramm (CFD)

    7. Kumulatives Flussdiagramm (CFD)

    Das kumulative Flussdiagramm (Cumulative Flow Diagram, CFD) ist ein Werkzeug zur Verfolgung der Leistung des Arbeitsablaufs. CFD visualisiert die Beziehung zwischen Work-in-Progress (WIP) und Durchlaufzeit. Teams können CFD nutzen, um Engpässe leicht zu identifizieren.

  • Durchsatz

    8. Durchsatz

    Der Durchsatz ist die Anzahl der Artikel, die ein System in einem bestimmten Zeitrahmen ausliefern kann. Von einem System mit hohem Durchsatz kann erwartet werden, dass es schneller auf Kundenbedürfnisse reagieren kann.

    Der Durchsatz ist gleich dem WIP geteilt durch die Zykluszeit.

  • Taktzeit

    9. Taktzeit

    Die Taktzeit ist definiert als die Geschwindigkeit, mit der ein Team Software in Produktion bringen sollte, um die Kundenanforderungen zu erfüllen.
    Die Taktzeit ermöglicht es, die aktuelle Produktivität des Lieferprozesses im Verhältnis zur Kundennachfrage zu messen.

    Taktzeit = verfügbare Zeit für die Produktion / benötigte Einheiten (Kundenbedarf)

    Die Tackt-Zeit kann mit der Zykluszeit verglichen werden, wodurch das Team in der Lage ist, nicht wertschöpfende Tätigkeiten zu identifizieren und einen kontinuierlichen Wertfluss zum Kunden zu erreichen.

  • Qualität - bestandene Testfälle

    10. Qualität - bestandene Testfälle

    Abnahmetests werden geschrieben, bevor neue Produkte entwickelt werden (auf der Rückseite der Story Cards). Sie stellen sicher, dass der Code die Anforderungen erfüllt. Bei Software werden die ersten Tests fehlschlagen, weil der Code noch nicht vollständig entwickelt ist. Wenn der Code richtig geschrieben ist, wird er die Tests bestehen.
    Je höher die Erfolgsquote bei den Tests ist, desto größer ist die Wahrscheinlichkeit, dass es in der Produktion nicht zu Ausfällen kommt.

  • Rate der entgangenen Defekte

    11. Rate der entwichenen Defekte

    Entgangene Fehler sind die Fehler, die dem Testteam entgangen sind. Die Fehlerrate misst, wie oft Fehler gefunden werden. Entgangene Fehler sind am teuersten zu beheben. Ein Anstieg der entwichenen Fehler zeigt, dass ein Prozess fehlerhaft ist.

  • Team Velocity

    12. Team Velocity

    Velocity ist ein Maß dafür, wie viel Arbeit (Summe der Story Points der erledigten Stories) ein Team pro Iteration erledigen kann.
    Die Geschwindigkeit ist hilfreich, um vorherzusagen, wie viel Arbeit in zukünftigen Iterationen erledigt werden kann. Die Geschwindigkeit ändert sich und sollte am Ende einer jeden Iteration gemessen werden. Es ist anzumerken, dass die Geschwindigkeit von Teams nicht verglichen werden kann, da die Größenordnung und die Schätzung in jedem Team von den anderen abweicht.

    Die Berechnung der Anfangsgeschwindigkeit steht vor dem Problem des "Kaltstarts" und kann wie folgt durchgeführt werden: - auf der Grundlage historischer Daten früherer ähnlicher Projekte, - nach einigen Iterationen und anschließender Berechnung der Geschwindigkeit, - oder auf der Grundlage eines Expertenurteils.