17 Wichtige Agile-Metriken, um die sich Ihr Team kümmern sollte

Metriken sind seit langem ein Diskussionspunkt von Agilisten.

Trotz der Tatsache, dass die agile Entwicklung aufgrund der kontinuierlichen Bereitstellung von Qualitätssoftware empirisch ist, fordern PMO-Büros, Projektmanager und Kunden gleichermaßen immer noch detaillierte Statusberichte, wie sie es bei jedem wasserfallbasierten Projekt tun würden. Obwohl die geschäftlichen Anforderungen ein Grund für die Aufsicht sind, trägt die agile Entwicklung selbst zu einem Maß an Unsicherheit bei, das manche Leute immer festnageln wollen.

Um diesem Trend entgegenzuwirken, argumentieren viele Agilisten, dass Messungen überhaupt nicht verwendet werden sollten und dass nur die Produktion von Software selbst als Maßstab für den Erfolg angesehen werden sollte. Die Befürworter dieses Ansatzes behaupten, dass Entwicklungsteams und Projektmanager das System instinktiv manipulieren, indem sie User Stories und Schätzungen manipulieren, um den Anschein hoher Effizienz zu erwecken und die wahren Probleme zu verbergen. Es gibt jedoch ein Sprichwort, das besagt, was gemessen wird, wird getan.

Der Hauptgrund für dieses Spiel ist, dass sich Unternehmen zu sehr auf ein oder zwei Metriken verlassen, anstatt eine umfassende Metriklösung zu haben. In diesem Artikel besprechen wir die Metriken, die nachweislich die besten verfügbaren Informationen zu Teamleistung, Qualität, Wert und sogar Agilität liefern. Wir werden sogar über einige Metriken sprechen, von denen Sie vielleicht noch nie gehört haben, basierend auf den neuesten Forschungsergebnissen und innovativsten Fallstudien.

Wofür werden agile Metriken verwendet?

Agile Metriken werden verwendet, um Status, Qualität, Produktivität, Effizienz, Wert und sogar die Agilität selbst zu verfolgen. Am wichtigsten ist, dass sie verwendet werden, um geschäftliche Entscheidungen zu treffen. Ganz gleich, an welcher Art von Projekt Sie arbeiten, die Berichterstattung wird sowohl für externe als auch für interne Stakeholder immer wichtig sein. Metriken können Entscheidungen auf allen Ebenen beeinflussen, vom Produktmanagement bis zum Personalmanagement, und müssen daher genau, informativ und unvoreingenommen sein. Bevor wir uns mit den Metriken befassen, müssen wir zunächst eine Grundlage schaffen, auf der alle diese Messungen basieren.

Das eiserne Dreieck vs. das agile Dreieck

Bei planbasierten Ansätzen basierte die Messung auf dem alten „eisernen Dreieck“ aus Umfang, Zeitplan und Kosten. Fast jede Metrik fiel in eine dieser drei Kategorien. In der agilen Welt wurde dieses Dreieck auf den Kopf gestellt. Projekte werden durch die Bereitstellung von Wert und Qualität innerhalb bestimmter Einschränkungen definiert. Budget oder Kosten sind unter anderem nur eine dieser Einschränkungen und stehen nicht im Mittelpunkt der Bereitstellung.

Hier ist es wichtig, die Beziehung zwischen Wert und Qualität zu verstehen. Vielen Menschen fällt es schwer, Werte zu definieren. Erstens gibt es zwei Arten von Qualität: intrinsisch und extrinsisch.

• Intrinsische Qualität bezieht sich auf die interne Wahrnehmung des Produkts durch die Entwicklungs-, Test- und Managementteams. Es wird normalerweise mit Fehlermetriken veranschaulicht, die wir später beschreiben.
• Äußere Qualität ist die Qualität des Produkts, wie sie vom Endverbraucher wahrgenommen wird. Wie gut das Produkt ihren Bedürfnissen entspricht und die Erwartungen erfüllt. Ein anderer Begriff für diese äußere Qualität ist Wert.

Daher ist es wichtig zu verstehen, dass Qualität, wie sie im agilen Dreieck dargestellt wird, aus Sicht der Entwicklung intrinsische oder interne Qualität ist, während Wert im Dreieck wirklich eine Form von extrinsischer Qualität ist. Das Verständnis dieser Beziehung ist wichtig, um gute agile Maßnahmen zu entwickeln.

17 wichtige Agile-Metriken zum Nachverfolgen

Die folgende Liste mit siebzehn Metriken kombiniert die am häufigsten verwendeten und bewährten agilen Metriken mit neueren Maßnahmen, die auf aktuellen Forschungsergebnissen basieren. Die wichtigste Erkenntnis hier ist, dass jede Lösung für agile Metriken umfassend sein sollte.

Sich nur auf ein oder zwei zu verlassen, wird kein vollständiges Bild davon liefern, was vor sich geht. Der größte Fehler, den viele Manager machen, besteht darin, sich zu sehr auf zwei oder drei oder nur eine Metrik für ihr gesamtes Projekt zu konzentrieren. Einige Organisationen verwenden ausschließlich Velocity- oder Burndown-Charts.

Ob Sie es glauben oder nicht, es passiert. Eine gute Metriklösung sollte alle drei Punkte des agilen Dreiecks abdecken. Diese 17 geben Ihnen die Werkzeuge, um genau das und noch viel mehr zu tun.

Gesperrte Zeit

Blockierte Zeit ist definiert als die Zeit, die eine bestimmte User Story – oder manchmal eine Aufgabe – blockiert ist. Das Auflösen von Blockaden ist entscheidend, um den Arbeitsfluss in einer agilen Umgebung zu erleichtern, und diese Metrik kann dabei helfen, die Zeit zu messen, die sie benötigen, um sie zu lösen. Blocker sollten zielführend aufgelöst werden.

Ein Anstieg der blockierten Zeit kann bedeuten, dass eine User Story nicht richtig zerlegt wurde oder dass eine ungeplante Abhängigkeit von einer externen Ressource besteht. Blockierte Zeit kann durch eine sorgfältigere Zerlegung der User Story, Priorisierung und Sprint-Planung reduziert werden.

Geschäftsdynamik

Viele der hier diskutierten Metriken gibt es schon seit geraumer Zeit. Die meisten konzentrieren sich auf die Projekt-, Team- oder WIP-Ebene (work in progress). Da die Technologie jedoch immer stärker in unser tägliches Leben integriert wird und die Märkte für diese Produkte hyperbeschleunigt werden, suchen Unternehmen nach ausgefeilteren Metriken, die Markttrends identifizieren, Prozessverbesserungen messen, Wettbewerb vorhersagen und im Wesentlichen die Agilität messen können. Die Geschäftsdynamik ist eine davon. Momentum kann in diesem Zusammenhang als die Gesamtzahl der Story Points für eine Veröffentlichung multipliziert mit ihrer Zeitleiste ausgedrückt werden.

Wenn eine Organisation agiler wird, gewinnt sie mit jeder Version an Dynamik. Durchlaufzeiten werden tendenziell kürzer und die Erwartungen an die Lieferung steigen. Die Geschäftsdynamik kann für das Markttiming oder als Indikator für die Gesundheit einer bestimmten Produktlinie oder eines bestimmten Programms verwendet werden. Wenn die Dynamik nachlässt, ist dies ein Indikator für das Management, dass sich ein bestimmter Markt zu entwickeln beginnt und eine neue Produktlinie entwickelt werden muss. Agile Organisationen müssen ständig nach neuen Märkten suchen, um wettbewerbsfähig zu bleiben.

Codeabdeckung

Die Codeabdeckung ist ein Maß dafür, wie viel Code während des Testens tatsächlich ausgeführt wird. Dies wird typischerweise als Teil einer automatisierten Teststrategie instrumentiert und berechnet. Die Metrik sollte den Gesamtprozentsatz des während jeder Testphase (Unit, System usw.) ausgeführten Codes sowie die Summe aller Phasen angeben.

Code Coverage sollte nicht als Indikator dafür missbraucht werden, wie gut ein Produkt getestet wurde. Das Ziel dieser Metrik besteht vielmehr darin, die Testautomatisierung zu erleichtern und die kontinuierliche Bereitstellung zu überwachen. Qualitätssicherungsmessungen sollten eine Vielzahl von Metriken umfassen, von denen nicht zuletzt das später besprochene Auftreten von Fehlern ist.

Kontrollkarte

Manchmal auch als Prozessverhaltens- oder Shewhart-Diagramm bezeichnet, überwacht ein Kontrolldiagramm die Leistung eines Prozesses, um festzustellen, ob er unter Kontrolle oder außer Kontrolle ist – abhängig von den eingestellten oberen, unteren und mittleren Eingriffsgrenzen.

Diese Grenzwerte werden berechnet, indem die Standardabweichung der Stichprobendaten geschätzt, diese Abweichung mit drei multipliziert und dann zum Durchschnitt addiert wird, um die obere Grenze zu erstellen, und vom Durchschnitt subtrahiert wird, um die untere Grenze zu erstellen. Die Y-Achse des Diagramms ist die Anzahl der Vorkommen oder Probleme in einer bestimmten Stichprobe, während die X-Achse jede Stichprobe aufzählt. Regelkarten haben ihren Ursprung in der Fertigung als Form der Qualitätskontrolle und gibt es seit fast 100 Jahren.

Regelkarten sind bei Six-Sigma-Jüngern beliebt und können das Scheitern oder den Erfolg der Qualitätskontrolle oder anderer Herstellungsprozesse messen. Obwohl sie in der agilen Welt nicht populär sind, könnten Kontrolldiagramme verwendet werden, um Fehler zu messen, die pro Iteration oder Release gefunden wurden, um Probleme mit QA-Tests zu identifizieren, oder um Zykluszeiten über eine Reihe von Releases hinweg zu messen, um sicherzustellen, dass sie innerhalb akzeptabler Werte liegen.

Kumulatives Flussdiagramm

Ein kumulatives Flussdiagramm veranschaulicht, wie viel Arbeit, segmentiert nach Typ, einem Team im Laufe der Zeit zugewiesen wird. Sein Zweck besteht darin, zu überwachen, wie gut die Arbeit im gesamten System fließt. In diesem Diagramm ist die Arbeit in verschiedene Typen unterteilt, zum Beispiel: zu erledigen, in Bearbeitung und erledigt. Es könnte auch in Anforderungen, Entwicklung, Tests usw. unterteilt werden. Wie auch immer es segmentiert ist, das kumulative Flussdiagramm zeigt eine Linie für jeden Arbeitstyp, wobei die Anzahl der Arbeitselemente auf der Y-Achse und der X-Achse eine Funktion der Zeit ist.

Eine gute Strömung wird durch alle diese parallel verlaufenden Linien veranschaulicht. Wenn eine der Linien einen starken Anstieg erfährt oder eine andere kreuzt, könnte dies auf einen Engpass hindeuten. Das Erreichen eines guten Flusses ist das zentrale Konzept hinter Kanban. Das kumulative Flussdiagramm hilft dabei, Engpässe zu identifizieren, um einen kontinuierlichen Fluss zu erleichtern und sicherzustellen, dass WIP an keiner Stelle im System außer Kontrolle gerät.

Zykluszeit

Die Zykluszeit kann definiert werden als wie lange es dauert, ein Software-Release zu erstellen, vom Konzept bis zur Fertigstellung. Zusammen mit Lead Time und Velocity ist die Zykluszeit ein sehr guter Indikator auf hoher Ebene für die agile Gesundheit und den Erfolg der agilen Transformation. Wenn eine Organisation auf ihrem Weg zur Agilität voranschreitet, sollten die Zykluszeiten allmählich kürzer werden, typischerweise auf sechs Monate oder viel weniger. Verlängerungen der Zykluszeit, insbesondere wenn sie über ein oder zwei Releases konsistent beobachtet werden, sollten Anlass zur Sorge und Überprüfung geben.

Epic und Release-Burndown

Epic- und Release-Burndown-Charts ähneln dem allseits beliebten Sprint-Burndown, der weiter unten besprochen wird. Ein Burndown-Diagramm veranschaulicht, wie viel Arbeit für einen bestimmten Zeitraum oder in diesem Beispiel für ein bestimmtes Epic verbleibt. In der agilen Entwicklung ist ein Epic eine größere User Story, die aus kleineren User Stories oder Arbeitsblöcken besteht.

Wenn die Arbeit abgeschlossen ist, wird die Anzahl der User Stories im Epic schrittweise reduziert, bis sie Null erreicht. Dies kann in Fällen nützlich sein, in denen Meilensteine ​​erreicht werden müssen, um vertragliche Anforderungen zu erfüllen und dem Kunden Rechnung zu stellen. In ähnlicher Weise kann ein Release-Burndown den Fortschritt der Arbeit verfolgen, die für ein bestimmtes Release vorgesehen ist. Dies kann verwendet werden, um eine pünktliche Lieferung sicherzustellen oder frühzeitig zu erkennen, dass eine Frist geändert werden muss.

Fehlgeschlagene Bereitstellungen

Eine fehlgeschlagene Bereitstellung ist eine, die zu einem der folgenden Ergebnisse führt:

• Dienst, der den Ausfall beeinflusst
• Erfüllt die Kundenerwartungen nicht, was häufig zur Ablehnung der Freigabe führt.
• Beeinträchtigt die Benutzerfreundlichkeit, den Betrieb oder die Benutzererfahrung des Produkts ernsthaft.
• Führt zu einem Rollback auf die vorherige Version.

Offensichtlich sollte die Rate fehlgeschlagener Bereitstellungen, angezeigt als Prozentsatz der gesamten Bereitstellungen, auf einem Minimum gehalten werden. Jeder Anstieg dieser Kennzahl sollte Anlass zur Sorge geben. Änderungsraten und Auftreten von Fehlern sollten überprüft werden, um die Ursachen zu isolieren.

Vorlaufzeit

Die Durchlaufzeit misst die Zeit, die benötigt wird, um eine Aufgabe abzuschließen, von dem Moment an, an dem sie erstellt wird, bis zu dem Punkt, an dem sie abgeschlossen ist. Kurz gesagt, es gibt an, wie lange es dauert, Dinge zu erledigen. Diese bei Kanban-Praktikern beliebte Metrik kann dabei helfen, Effizienzen zu identifizieren, um Aufgaben schneller durch das System zu verschieben. Es kann auch als allgemeine Metrik verwendet werden, um zu bestimmen, wie gut Continuous Delivery funktioniert. Die Vorlaufzeit kann zusammen mit der Zykluszeit und der Geschwindigkeit zusammen verwendet werden, um eine ganzheitliche Sicht auf die Lieferleistung zu bieten.

Net Promoter Score (NPS)

Ein Net Promoter Score soll dabei helfen, die Kundenzufriedenheit zu bewerten. Sie wird in der Regel auf der Grundlage von Daten berechnet, die über eine Umfrage gewonnen wurden. Ziel ist es herauszufinden, wie viele Kunden Ihr Produkt weiterempfehlen würden. Der Prozentsatz der Befragten, die mit „Nein“ stimmen, wird von den „Ja“-Wählern abgezogen, um die Punktzahl zu erstellen.

Neben der Messung der Kundenzufriedenheit kann der Net Promoter Score dazu beitragen, Kunden zu identifizieren, die eher bereit sind, an innovativen Produkten oder Technologien für zukünftige Versionen zusammenzuarbeiten. Solche Kunden können zu einem Wettbewerbsvorteil werden, da ihr Feedback und ihre Unterstützung Unternehmen dabei helfen können, neue Produkte auf den Markt zu bringen, bevor es die Konkurrenz tut.

Hochwertige Intelligenz

Am Anfang des Artikels haben wir das agile Dreieck und die Rolle, die Qualität darin spielt, besprochen. Qualitätsintelligenz kann viele Formen annehmen, besteht jedoch typischerweise aus einer Vielzahl von Fehlerverfolgungsmetriken. Fehler können basierend auf Ort und Zeitpunkt ihres Auftretens, ihrer Häufigkeit und Schwere überwacht werden.

Eine der beliebtesten ist die Defect Escape Rate, die das Verhältnis der vom Kunden gefundenen Fehler zur Gesamtzahl der in einem Release entdeckten Fehler darstellt. Obwohl eine große Anzahl von Mängeln unabhängig davon, wie sie gefunden werden, besorgniserregend sein sollte, ist es immer am besten, sie zu erkennen, bevor der Kunde dies tut.

Sprint-Burndown

Sprint-Burndown-Diagramme bieten ein tägliches Maß für die Arbeit, die in einem bestimmten Sprint abgeschlossen ist, und die Arbeit, die noch zu erledigen ist. Es vergleicht den Umfang der abgeschlossenen Arbeiten mit den ursprünglichen Schätzungen. Aufgrund der empirischen Natur der agilen Entwicklung ist der Wert des Burndown-Diagramms ziemlich begrenzt.

Trotz seiner Popularität wenden sich viele agile Coaches davon ab, es so oft wie früher zu verwenden. Es kann als guter Leitfaden oder Statuspunkt dafür dienen, wo Entwicklungsteams gegen ihre Verpflichtungen stehen, aber es sollte zusammen mit anderen Metriken verwendet werden, um ein vollständiges Bild davon zu erhalten, was vor sich geht.

Durchsatz

Als Durchsatz wird die pro Zeiteinheit an den Kunden gelieferte Produktmenge (Anzahl der Workitems) bezeichnet. Dies kann monatlich, vierteljährlich, pro Release, Iteration usw. gemessen werden. Der Wert dieser Metrik besteht darin, dass sie verwendet werden kann, um zu bestimmen, wie viel Software für einen bestimmten Zeitraum geliefert werden kann. Es kann auch verwendet werden, um die Konsistenz der Lieferung aus einer Team- und Organisationsperspektive zu verfolgen.

Die empirische Analyse historischer Daten kann verwendet werden, um die Lieferleistung zu prognostizieren. Je mehr historische Daten verfügbar sind, desto genauer sind die Prognosen wahrscheinlich. Am wichtigsten ist, dass diese Metrik auch zur Umsatzprognose verwendet werden kann, da der Wert der bereitgestellten Feature-Funktionalität in finanzieller Hinsicht gut verstanden wird. Damit diese Metrik funktioniert, muss die Definition von „erledigt“ klar definiert sein. Nur an den Kunden gelieferte Software erfüllt diese Anforderung.

Wert geliefert

Am Anfang des Artikels haben wir diskutiert, wie Wert aus äußerer Qualität oder der Wahrnehmung des Produkts durch den Endverbraucher besteht. Wie wirkt sich das Produkt auf das Geschäft des Kunden aus? Gute Agile-Metriken basieren auf Ergebnissen, und in der Geschäftswelt bedeutet dies normalerweise Dollar und Cent. So wie wir jeder User Story Story Points zuweisen, um den Arbeitsaufwand abzuschätzen, können wir auch Value Points als relatives Maß hinzufügen, um anzugeben, was der Endbenutzer nach getaner Arbeit erhält.

Eine Möglichkeit, dies zu tun, ist ein Burn-up-Diagramm, das die Anzahl der Wertpunkte darstellt, die sich beim Abschluss jeder Geschichte angesammelt haben. Bei der Erstellung der Akzeptanzkriterien können jeder Story oder jedem Feature basierend auf der Kundenwahrnehmung Wertpunkte zugewiesen werden. Die erwarteten Einnahmen (oder eingesparten Gelder) für den Kunden im Rahmen des Projekts können durch die Gesamtzahl der Wertpunkte im Release geteilt werden.

Wenn es beispielsweise 200 Wertpunkte in einem Projekt gibt und der Kunde voraussichtlich 1 Million US-Dollar Umsatz erzielen wird, ist jeder Wertpunkt 5.000 US-Dollar wert. Die Gesamtsumme jeder Geschichte und ihr kumulierter Wert können im Abbranddiagramm dargestellt werden. Obwohl die tatsächlichen Auswirkungen des Produkts möglicherweise erst bei seiner Markteinführung erkennbar sind, kann diese Methode überzeugende Finanzinformationen für das Management und die Kunden gleichermaßen liefern.

Geschwindigkeit

Geschwindigkeit ist wahrscheinlich die erste Metrik, von der die meisten von uns hören, nachdem sie in die agile Entwicklung eingeführt wurden. Obwohl es wohl die beliebteste agile Metrik ist, wird es auch am häufigsten missbraucht. Sprint-Teams sind berüchtigt für ihre Spielgeschwindigkeit, weil sie sich bei der Berichterstattung über ihre Leistung so stark auf sie verlässt. Geschwindigkeit ist definiert als die Menge an Software, die in jeder Iteration oder jedem Sprint produziert wird. Diese Menge wird normalerweise in Story Points ausgedrückt, und die produzierte Software muss ein funktionsfähiges, produktionsreifes Codestück sein.

Teams spielen oft mit der Geschwindigkeit, indem sie die Größe und Schätzung von User Storys manipulieren oder die Arbeit horizontal statt vertikal zerlegen, indem sie Storys für Datenbankänderungen, Front-End-Arbeit, Middleware und mehr erstellen. um Abhängigkeiten von anderen zu beseitigen und Anerkennung für die Erledigung von Arbeiten zu erhalten. Das Problem bei diesem Ansatz ist, dass diese Art von User Stories eigentlich Aufgaben sind, und obwohl die Teams Anerkennung erhalten, wurde der Geschäftswert für den Kunden nicht geliefert.

Die Spielgeschwindigkeit kann verhindert werden, indem eine Vielzahl anderer Metriken als Check-and-Balance gegeneinander verwendet werden. Allzu oft verlassen sich Unternehmen nur auf die Geschwindigkeit oder einen sehr kleinen Satz von Metriken anstelle einer größeren Reihe von Messungen, um eine PPM-, Programm- und Projektmanagementlösung zu erstellen.

Vorticity (agil)

Eine Frage, mit der sich viele Agilisten und Projektmanager herumschlagen, lautet: „Wie agil sind wir?“ Tatsächlich war die Suche nach der Antwort auf die Messung der Agilität selbst der heilige Gral der Agilisten auf der ganzen Welt. Agile Vorticity ist eine neue Maßnahme, die genau das tut. Basierend auf über 10 Jahren Fallstudienforschung wurde agile Vorticity durch eine ausgeklügelte qualitative Methode namens Grounded Theory entwickelt.

Unter Verwendung einer umfassenden Reihe von Maßnahmen kann die Agilität sowohl des Marktes als auch des Organisationsprozesses gegeneinander gemessen werden, um ihre Verwirbelung oder den Punkt, an dem sie zusammenlaufen, zu bestimmen. Zero Vorticity bedeutet, dass die Agilität der Organisation mit dem Markt übereinstimmt. Hohe Vorticity bedeutet, dass sich der Markt viel schneller bewegt als Ihre Organisation oder Teams, und daher gibt es viel zu tun. Die folgende Infografik demonstriert diese Beziehung anhand eines Strudel-Gedankenexperiments, um die heutigen hyperbeschleunigten Märkte zu veranschaulichen.

Arbeitselementalter

Ein Arbeitselement kann als Arbeitspaket, nutzbares Feature oder, wie es in den meisten agilen Kontexten der Fall wäre, als User Story definiert werden. Die Uhr beginnt mit dem Alter eines Workitems zu ticken, sobald es zum ersten Mal konzipiert wird. Das Verfolgen des Alters von Arbeitselementen, ob sie in Bearbeitung sind oder sich im Backlog befinden, kann dabei helfen, Probleme mit Anforderungen zu identifizieren.

Wenn ein Arbeitselement älter zu werden scheint als seine Verwandten, weil es von einem Sprint zum nächsten verschoben wird, könnte es ein Problem mit der Zerlegung geben. Vielleicht muss es neu definiert oder besser verstanden werden? Arbeitselemente, die längere Zeit im Rückstand verbleiben, müssen möglicherweise ausgesondert oder neu definiert werden.

Kontinuierliches Backlog-Grooming ist entscheidend für die Sprint-Planung und -Priorisierung. Eine wachsende Zahl alternder Anforderungen im Backlog könnte zu Problemen bei der Entwicklung und Zerlegung der Anforderungen führen. Schlechtes Anforderungsmanagement ist eine der Hauptursachen für das Scheitern agiler Transformationen.

Schlecht geschriebene Anforderungen können die Priorisierung und Schätzung extrem erschweren, was zu außer Kontrolle geratenen technischen Schulden, geringer Funktionsauslastung und finanziellen Verlusten führt. Die Entwicklung gut verstandener, priorisierter, hochwertiger Anforderungen ist eine Kunstform und wird selbst von den besten Agilisten nur unzureichend verstanden. Tatsächlich ist es wohl einer der größten Blocker für den Erfolg der agilen Transformation.

Fazit

In diesem Artikel haben wir die Grundlage für agile Metriken, die Notwendigkeit einer umfassenden Lösung und 17 Empfehlungen zum Aufbau einer solchen geschaffen. Unabhängig davon, ob Sie alle besprochenen Messungen oder nur eine Teilmenge verwenden, ist es wichtig, dass jede Lösung die Zielgruppe für die Daten berücksichtigt. Einige Metriken, wie z. B. Geschwindigkeit, werden am besten innerhalb der Scrum-Teams aufbewahrt. Andere Metriken wie Agile Vorticity und Business Momentum sind für Führungskräfte bzw. das Produktmanagement konzipiert.

Stellen Sie immer sicher, dass Sie genau verstehen und kommunizieren, was die Metriken aussagen, und verfolgen Sie, wohin die Daten führen. Eine Möglichkeit, gute Metriken voranzutreiben und zu unterstützen, ist ein robustes agiles Framework.