10 Scrum Metriken die du kennen musst

Simone Kohl

7 mins read

Scrum ist ein Framework und eine agile Methode, bei der sich alles um die Zusammenarbeit im Team dreht. Sie wird hauptsächlich in der Softwareentwicklung eingesetzt, kann aber auch auf andere Teams angewendet werden. Bei Scrum geht es um gemeinsame Strukturen, Meetings und Teamarbeit im Allgemeinen. Um dies zu messen und um Optimierungen vornehmen zu können, gibt es die Scrum-Metriken.

Was sind Scrum-Metriken?

Scrum Metrics sind KPIs (Key Performance Indicators), mit denen der Erfolg des Unternehmens bewertet werden kann. Sie können feststellen, ob sie die Geschäftsziele erreicht haben oder ob sie auf dem richtigen Weg sind. Ziel ist es, Verbesserungen vornehmen zu können und Probleme zu erkennen, die dann gelöst werden können. Mit Hilfe von KPIs lassen sich auch Trends verfolgen und die Leistung des Unternehmens mit anderen vergleichen. Scrum-Teams arbeiten in Sprints, d. h. in einem bestimmten Zeitraum, in der Regel 1-4 Wochen, in dem die im Voraus geplanten Aufgaben erledigt werden. Dies erleichtert es dem Team, sich Ziele zu setzen und das richtige Produkt zur richtigen Zeit zu entwickeln.

Metriken sind Messstandards. In agilen Projekten können die Metriken leistungsstarke Werkzeuge für die Planung, Überprüfung, Anpassung und das Verständnis des Fortschritts im Laufe der Zeit sein. Anhand der Erfolgs- und Misserfolgsquoten kann das Scrum-Team erkennen, ob es Optimierungen vornehmen muss oder ob das Team gute Arbeit geleistet hat. Dauer- und Kostenzahlen können die Vorteile agiler Projekte aufzeigen und die finanziellen Aktivitäten einer Organisation untermauern. Sie helfen dem Team zu sehen, wie produktiv es in jeder Phase ist. Sie sind auch ein wichtiger Bestandteil des Entwicklungsprozesses, da sie auch zur Bewertung der Softwarequalität herangezogen werden können. Wenn man misst, wie produktiv ein Team arbeitet, lassen sich Schwachstellen aufdecken und die Probleme können bearbeitet werden.

Warum sind Scrum-Metriken wichtig?

Das bringt uns zum nächsten Punkt: Warum brauchen Sie Scrum Metrics? Metriken sind wichtig, um den Überblick über eine Organisation und ihre Teams zu behalten. Sie helfen dabei, Projekte zu planen, anzupassen und zu verstehen, wie sie voranschreiten. Metriken helfen dem Team, sich selbst zu verbessern, denn Teams, die sich selbst verbessern, sind auf lange Sicht nachhaltiger und erfolgreicher. Dies ist jedoch ein Prozess, der Management erfordert. Indem sie die Leistung des Teams verfolgen, können agile Metriken die kontinuierliche Verbesserung des Teams direkt beeinflussen.

Scrum Events 

In Scrum treten verschiedene Ereignisse innerhalb eines Sprints wiederholt auf. Die Ereignisse helfen dem Team, aussagekräftige Metriken und Erkenntnisse zu gewinnen. Um besser mit Scrum arbeiten zu können, haben wir hier 10 bewährte Tools für einfaches agiles Projektmanagement in 2021.

Sprint Planning  

Den Auftakt eines jeden Sprints bildet das Sprint Planning Meeting. Es dient dazu, das Arbeitspaket des Scrum-Teams für den kommenden Sprint zu schnüren.

Nach einem erfolgreichen Sprint Planning:

  • der Product Owner und das Entwicklungsteam einigen sich auf das Sprint Goal (Ergebnis)
  • und haben gemeinsam das Sprint Backlog gebildet. Das Sprint Backlog enthält alle Product Backlog Items (Output), die im Sprint umgesetzt werden müssen, um das Sprint Goal zu erreichen
  • Damit der Product Owner und das Entwicklungsteam die beiden Ziele des Planungsmeetings erreichen können, müssen einige Voraussetzungen erfüllt sein

Daily Standup  

Daily Standups (auch Daily Scrum) sind eine zentrale Praxis für agiles Arbeiten. In diesem täglichen Meeting organisiert ein agiles Team sich und seine Arbeit ohne die Beteiligung von Managern oder externen Entscheidungsträgern. Die Teilnehmer des Daily Standup stehen für maximal 15 Minuten zusammen und sprechen abwechselnd über die Ergebnisse des Vortages, Hindernisse und ihren Plan für den aktuellen Tag. Auf diese Weise machen die Teammitglieder ihren Status und ihre wichtigsten Probleme transparent und können sich gegenseitig helfen, Hindernisse zu beseitigen, um das gemeinsam gesetzte Ziel zu erreichen.

Scrum Retrospective  

Die Scrum-Retrospektive ist eine Pflichtveranstaltung, die im Scrum Guide für das agile Projektmanagement-Framework Scrum beschrieben ist. Ziel der Retrospektive ist es, die Erfahrungen (aus dem letzten Sprint) zu reflektieren. Darauf aufbauend werden Verbesserungsmaßnahmen gesucht, die im nächsten Sprint direkt umgesetzt werden können.

Scrum-Metriken

1. Sprint Goal Success Rates  

Eine Möglichkeit, die Leistung eines agilen Projekts zu messen, ist die Geschwindigkeit, mit der die Sprint-Ziele erreicht werden. Der Sprint benötigt möglicherweise nicht alle Anforderungen und Aufgaben im Sprint Backlog, um das Ziel zu erreichen. Ein erfolgreicher Sprint sollte jedoch zu einem funktionierenden Produktinkrement führen, das die Sprint-Ziele erfüllt und der Definition des Scrum-Teams von “Done” entspricht. Wenn Sie die Sprint-Ziele definieren und sie danach messen, können Sie ein gutes Verständnis für die Qualität der Arbeit entwickeln.

Sprint-Success Rates sind ein guter Ausgangspunkt für die Überprüfung und Anpassung. Teams sollten die Messlatte immer so hoch ansetzen, dass eine 100-prozentige Fertigstellung des Sprint-Backlogs nicht unbedingt das Ziel ist. Die anfänglichen Anforderungen sollten zu hundert Prozent erfüllt werden, aber die Teams sollten ihre Ziele so hoch ansetzen, dass Erfolgsquoten von weniger als 100 Prozent bei Sprint-Backlog-Einträgen als Chance zum Lernen und Verbessern gesehen werden.

2. Entgangene Fehler

Entgangene Fehler sind ebenfalls eine wichtige Kennzahl. Durch die Aufzeichnung von Kennzahlen zu Fehlern kann das Entwicklungsteam feststellen, wie gut es Probleme verhindert und ob es seine Prozesse verbessern muss. Wenn das Entwicklungsteam automatisierte Tests und kontinuierliche Integration einsetzt, kann es die Anzahl der Fehler auf der Build-Ebene in jedem Sprint verfolgen. Durch die Aufzeichnung der Anzahl der Build-Fehler kann das Entwicklungsteam feststellen, ob es Entwicklungsprozesse oder Umgebungsfaktoren anpassen muss, um die Fehler früher im Entwicklungsprozess zu erkennen. Das Entwicklungsteam kann die Anzahl der Fehler erfassen, die der Product Owner bei der Überprüfung der fertigen Funktionalität in jedem Sprint gefunden hat. Durch die Erfassung der User Acceptance Test-Fehler können das Entwicklungsteam und der Product Owner erkennen, ob die Prozesse verbessert werden müssen.

Die Anzahl der Fehler und die Frage, ob die Fehler zunehmen, abnehmen oder gering bleiben, sind gute Indikatoren, um Diskussionen über Projektprozesse und Entwicklungstechniken in Sprint-Retrospektiven anzustoßen.

3. Team Velocity  

Mit Velocity lässt sich messen, wie viele User Stories das Team im Sprint fertiggestellt hat. So lässt sich leichter bestimmen, wie viele Aufgaben Sie für den nächsten Sprint planen können. Velocity ist ein subjektives Maß, das auf der Definition von Story Points durch das Team basiert und den Fortschritt des Teams erfasst. Daher sollte sie nicht zum Vergleich von Teams verwendet werden.

Team Velocity

4. Sprint Burndown  

Das Burndown-Diagramm ist eine grafische Darstellung der Arbeit, die bereits abgeschlossen ist, und der Arbeit, die noch erledigt werden muss. Es zeigt die Fertigstellung der verschiedenen Aufgaben während eines Sprints. Wichtige Messgrößen sind die Zeit und die noch zu erledigenden Aufgaben. Die Einheit ist Stunden oder auch Story Points. Ziel ist es hier, dass die Aufgaben bis zum Ende des Sprints abgeschlossen sind. Außerdem lässt sich so besser beurteilen, ob die Aufgaben aus dem Sprint abgeschlossen werden können.

Sprint Burndown Report

5. Time-to-market  

Die Markteinführungszeit ist die Zeit, die ein agiles Projekt benötigt, um durch die Freigabe nutzbarer Funktionen für den Kunden Wert zu schaffen.

Unternehmen können dies auf unterschiedliche Weise interpretieren:

  • Wenn ein Produkt direkt Umsatz generiert, ist sein Wert das Geld, das damit verdient wird
  • Wenn ein Produkt intern in der Organisation verwendet wird, ist sein Wert die Fähigkeit der Mitarbeiter, es zu nutzen, und er enthält subjektive Faktoren, die darauf basieren, was das Produkt leisten kann

Beachten Sie bei der Messung der Markteinführungszeit die folgenden Punkte:

  • Messen Sie die Zeit vom Projektstart bis zu dem Zeitpunkt, an dem Sie den Wert zum ersten Mal sehen
  • Einige Scrum-Teams geben am Ende jedes Sprints neue Produktfunktionen zur Nutzung frei. Bei Scrum-Teams, die mit jedem Sprint neue Produkte freigeben, wird die Zeit bis zur Markteinführung einfach in Tagen gemessen
  • Andere Scrum-Teams planen Releases nach mehreren Sprints und stellen Produktfunktionen in Gruppen bereit. Für Scrum-Teams, die längere Release-Zeiten verwenden, ist die Zeit bis zur Marktreife die Anzahl der Tage zwischen den Releases

6. ROI  

Der Return on Investment (ROI) ist der Ertrag, den ein Produkt abzüglich der Projektkosten erwirtschaftet: Bareinnahmen gegenüber Barausgaben.

Der ROI ist bei agilen Projekten grundsätzlich anders als bei traditionellen Projekten. Agile Projekte haben das Potenzial, bereits mit der ersten Version Einnahmen zu generieren, und die Einnahmen können mit jeder neuen Version steigen.

Example: 

Szenario A ist ein Wasserfallprojekt. Die Freigabe erfolgt am 30. Juni desselben Jahres, nachdem alle Anforderungen erfüllt worden sind. Mit diesem Projekt kann ab Juli ein monatlicher Umsatz von 100.000 € erzielt werden. Bis zum Ende des Jahres (6 Monate) beträgt der Umsatz 600.000 €.In Szenario B werden die wertvollsten und risikoreichsten Funktionen nach vier einwöchigen Sprints ab dem 31. Januar schrittweise freigegeben, d. h. fünf Monate früher als in Projekt A. Der monatliche Umsatz ist zu Beginn geringer, steigt aber mit jedem Monat nach der ersten Freigabe an und beträgt 50.000 € im Februar, 60.000 € im März, 70.000 € im April, 80.000 € im Mai, 90.000 € im Juni und 100.000 € im Juli, wenn das gesamte Projekt abgeschlossen ist.
Beispiel für ROI

7. Capital restructuring  

Wenn die Kosten für die weitere Entwicklung in einem agilen Projekt höher sind als die Kosten für diese zukünftigen Entwicklungen, ist es an der Zeit, das Projekt zu beenden.

Der Product Owner priorisiert die Anforderungen unter anderem danach, ob sie in der Lage sind, Umsatz oder Wert zu generieren. Wenn nur noch Anforderungen im Backlog übrig sind, die wenig Umsatz oder Wert generieren, kann ein Projekt beendet werden, bevor das Projektteam sein gesamtes Budget aufgebraucht hat. Die Organisation kann dann die verbleibenden Mittel aus dem alten Projekt verwenden, um ein neues, wertvolleres Projekt zu starten.
Das Übertragen eines Budgets von einem Projekt auf ein anderes wird als Kapitalumschichtung bezeichnet.

Um zu berechnen, ob es sinnvoll ist, das Projekt zu beenden, benötigen Sie diese Kennzahlen:

  • den Geschäftswert (V) der verbleibenden Anforderungen im Product Backlog
  • die Ist-Kosten (ACC) der Arbeit, die für die Fertigstellung der Anforderungen im Product Backlog erforderlich ist
  • die Alternativkosten (AC) oder den Wert, wenn das Scrum-Team an einem neuen Projekt arbeitet

8. Satisfaction Umfragen

Umfragen zur Kundenzufriedenheit messen die Erfahrungen des Kunden mit dem Projekt, dem Prozess und dem Scrum-Team. Das Scrum-Team kann mehrmals während eines Projekts Kundenumfragen durchführen, sogar zu Beginn des Projekts, um einen Benchmark für zukünftige Vergleiche zu erhalten. Das Scrum-Team kann die Umfrageergebnisse nutzen, um die Prozesse zu untersuchen, positive Praktiken fortzuführen und das Verhalten bei Bedarf anzupassen.

9. Fluktuation  

Scrum-Projekte führen in der Regel zu einer besseren Arbeitsmoral. Eine Möglichkeit, die Arbeitsmoral zu quantifizieren, ist die Messung der Personalfluktuation. Obwohl die Fluktuation nicht immer direkt mit der Arbeitszufriedenheit zusammenhängt, kann es hilfreich sein, die folgenden Kennzahlen zu betrachten:

Fluktuation im Scrum-Team: Eine geringe Fluktuation im Scrum Team kann ein Zeichen für ein gesundes Teamumfeld sein. Eine hohe Fluktuation im Scrum Team kann auf Probleme im Projekt, in der Organisation, in der Arbeit, bei einzelnen Mitgliedern des Scrum Teams, mit Burnout, mit einem ineffektiven Product Owner, der das Entwicklungsteam zu bestimmten Verpflichtungen zwingt, mit inkompatiblen Persönlichkeiten, mit einem Scrum Master, der es nicht schafft, Hindernisse zu beseitigen, oder mit der allgemeinen Dynamik im Team hinweisen.

10. verschiedene Qualifikationen im Team

Erfahrene Scrum-Teams sind in der Regel funktionsübergreifender als weniger ausgereifte und entwickelte Scrum-Teams. Durch die Beseitigung einzelner Schwachstellen kommen die Teams schneller voran und produzieren qualitativ hochwertigere Produkte. Die Erfassung der Vielfalt der Fähigkeiten ermöglicht es Scrum-Teams und Managern, das Wachstum der Cross-Funktionalität zu bewerten.

Beginnen Sie damit, die vorhandenen Fähigkeiten und Qualifikationsniveaus zu ermitteln, indem Sie Ihr Team kennen:

  • Fähigkeiten und Qualifikationsniveau der einzelnen Personen
  • Fähigkeiten und Qualifikationsniveau der einzelnen Teams
  • Fähigkeiten und Qualifikationsniveau in der Organisation


Teile diesen Artikel

Article by:

Simone Kohl
Simone Kohl

Teile diesen Artikel