Scrum Teams messen oft erstaunlich viel und lernen trotzdem erstaunlich wenig. Velocity steigt. Story Points werden sauber dokumentiert. Burndown Charts sehen gut aus. Gleichzeitig wächst die Zahl ungenutzter Features, Arbeit bleibt länger liegen und Kunden merken kaum einen Unterschied. Die wichtigsten Scrum KPIs (und welche du ignorieren solltest) sind deshalb nicht die Kennzahlen, die dein Jira-Dashboard automatisch ausspuckt. Gute Scrum KPIs zeigen, ob ein Team Wert erzeugt, schnell lernt, zuverlässig liefert und seine Arbeitsweise verbessert. Einige der bekanntesten „agilen Kennzahlen“ leisten genau das nicht. Manche richten sogar Schaden an, wenn Unternehmen daraus Leistungsziele machen.

Nein.

Der aktuelle Scrum Guide schreibt keine bestimmten KPIs vor.

Er definiert Scrum als leichtgewichtiges Framework, mit dem Teams bei komplexen Problemen durch adaptive Lösungen Wert erzeugen. Grundlage sind Transparenz, Inspektion und Anpassung. Das Scrum Team soll Fortschritt zu seinen Zielen regelmäßig überprüfen und seine Arbeitsweise auf Basis neuer Erkenntnisse verändern.

Damit gibt Scrum eine klare Richtung vor.

Es sagt aber nicht:

Diese Praktiken können ergänzend verwendet werden.

Sie sind nicht Scrum.

Das ist wichtig, weil viele Unternehmen genau diese Hilfsgrößen zu ihren wichtigsten Scrum Kennzahlen gemacht haben.

Eine gute Kennzahl sollte mindestens eine dieser Fragen beantworten:

Scrum.org formuliert 2026 einen wichtigen Grundsatz besonders deutlich: Teams sollten nicht Scrum selbst messen, sondern den Wert und die Ergebnisse, die sie damit erzeugen. Kennzahlen wie Velocity, Prozent fertig oder reiner Throughput beweisen für sich genommen noch keinen Kundennutzen.

Genau daraus ergibt sich eine sinnvolle KPI-Hierarchie.

Für die meisten Scrum Teams sind diese Kennzahlengruppen besonders wertvoll:

Nicht jedes Team braucht alle zehn.

Ein gutes Messsystem ist klein.

Und es beginnt beim Zweck des Produkts.

Die wichtigste Frage eines Produktteams lautet nicht:

Wie viel haben wir gebaut?

Sondern:

Was hat sich für unsere Nutzer verbessert?

Mögliche Outcome-Kennzahlen sind:

Beispiel:

Ein Team entwickelt eine neue Self-Service-Funktion.

Schwache Messung:

12 User Stories abgeschlossen.

Bessere Messung:

Der Anteil vollständig digital erledigter Anfragen steigt von 48 auf 67 Prozent.

Das zweite Ergebnis sagt etwas über den Wert des Produkts.

Das erste nur über Arbeit.

Scrum.org fasst Produktmetriken entsprechend in Bereichen wie Kundennutzen, wirtschaftlicher Wirkung, Produktqualität sowie Geschwindigkeit und Kapazität zusammen. Beispiele sind Kundenzufriedenheit, Nutzung, Umsatz, Kosten, Marktanteil, Fehler, technische Schulden oder Cycle Time.

Der Product Goal gibt dem Scrum Team eine langfristige Richtung.

Deshalb braucht ein Team messbare Hinweise, ob es diesem Ziel näherkommt.

Beispiel:

Product Goal:

Den digitalen Vertragsabschluss so verbessern, dass mehr Kunden den Prozess ohne Unterstützung erfolgreich beenden.

Mögliche KPIs:

Wichtig:

Der Fortschritt zum Product Goal darf nicht mit dem Anteil erledigter Backlog Items verwechselt werden.

50 Prozent des Backlogs erledigt bedeutet nicht:

50 Prozent des Ziels erreicht.

Vielleicht liefern fünf kleine Änderungen 80 Prozent des Kundennutzens.

Oder 30 Features erzeugen kaum Wirkung.

Das ist einer der größten Unterschiede zwischen output- und outcome-orientierter Produktsteuerung.

Viele Teams feiern Releases.

Weniger Teams überprüfen anschließend konsequent, ob Kunden die neuen Funktionen tatsächlich nutzen.

Genau diese Information ist entscheidend.

Sinnvolle Kennzahlen sind:

Eine Funktion, die technisch perfekt entwickelt wurde und kaum jemand nutzt, erzeugt fragwürdigen Wert.

Scrum.org zählt Customer Usage ausdrücklich zu möglichen Produktmetriken und ordnet sie dem tatsächlichen Kunden- und Geschäftswert zu.

Ein Product Owner sollte deshalb nicht nur fragen:

„Ist das Feature fertig?“

Sondern einige Wochen später:

„Hat sich das erwartete Nutzerverhalten tatsächlich verändert?“

Die Cycle Time misst, wie viel Zeit zwischen dem Beginn und der Fertigstellung eines Arbeitselements vergeht.

Beispiel:

Ein Product Backlog Item wird am Montag begonnen.

Am folgenden Donnerstag erfüllt es die Definition of Done.

Cycle Time:

8 Arbeitstage.

Warum ist diese Kennzahl so wertvoll?

Weil sie zeigt, wie schnell Arbeit tatsächlich durch das System fließt.

Sinkende Cycle Time kann bedeuten:

Scrum.org führt Cycle Time zusammen mit Throughput, Work in Progress und Work Item Age als eine der vier zentralen Flow Metrics für Scrum Teams auf, die Kanban-Praktiken ergänzend nutzen.

Wichtig ist der Trend.

Nicht:

„Unsere Cycle Time beträgt 6,3 Tage.“

Sondern:

„Warum ist unsere Cycle Time in drei Monaten von fünf auf neun Tage gestiegen?“

Damit wird die Kennzahl steuerungsrelevant.

Work in Progress – WIP – bezeichnet die Zahl begonnener, aber noch nicht fertiggestellter Arbeitselemente.

Viele Teams optimieren unbewusst auf Auslastung.

Jeder soll beschäftigt sein.

Also beginnt jeder neue Arbeit.

Die Folge:

WIP macht dieses Problem sichtbar.

Beispiel:

Ein Team mit sieben Personen arbeitet gleichzeitig an 14 Backlog Items.

Das muss nicht falsch sein.

Es sollte aber eine Frage auslösen:

Warum brauchen wir doppelt so viel begonnene Arbeit wie Menschen im Team?

Die Verbindung zwischen WIP und Durchlaufzeit ist zentral: Je mehr Arbeit gleichzeitig im System liegt, desto länger dauert es im Durchschnitt, bis einzelne Elemente fertig werden. Genau deshalb setzt Scrum mit Kanban stark auf die Begrenzung paralleler Arbeit.

Cycle Time kann erst gemessen werden, wenn ein Arbeitselement fertig ist.

Was aber ist mit Arbeit, die gerade jetzt festhängt?

Dafür gibt es Work Item Age.

Die Kennzahl zeigt:

Wie lange befindet sich ein noch nicht abgeschlossenes Element bereits in Bearbeitung?

Beispiel:

Typische Cycle Time des Teams:

5 bis 8 Tage.

Ein Backlog Item ist bereits seit 17 Tagen offen.

Das ist ein Signal.

Vielleicht:

Scrum.org bezeichnet Work Item Age deshalb als wichtigen Frühindikator für potenziell stockende Arbeit.

Gerade im Daily Scrum ist diese Kennzahl oft hilfreicher als die Frage:

„Was hast du gestern gemacht?“

Besser:

„Welche Arbeit altert gerade und was hindert uns daran, sie abzuschließen?“

Throughput misst, wie viele Arbeitselemente innerhalb eines bestimmten Zeitraums abgeschlossen werden.

Zum Beispiel:

Im Gegensatz zur Velocity zählt Throughput reale Arbeitselemente.

Keine abstrakten Punkte.

Das macht historische Daten gut für probabilistische Forecasts nutzbar.

Angenommen:

Ein Team schließt über längere Zeit typischerweise zwischen 8 und 12 vergleichbar geschnittene Items pro Sprint ab.

Dann kann diese Information dabei helfen, zukünftige Liefermengen probabilistisch abzuschätzen.

Scrum.org beschreibt Throughput ausdrücklich als Anzahl abgeschlossener Elemente pro Zeiteinheit.

Aber:

Auch Throughput ist kein Business Outcome.

Ein Team kann seinen Throughput verdoppeln und trotzdem doppelt so viel unwichtige Arbeit erledigen.

Deshalb immer kombinieren mit einer Value-Kennzahl.

Ein reales internationales Handelsunternehmen arbeitete mit mehr als 40 Teams in mehreren Ländern.

Die Teams nutzten Scrum, kämpften aber mit:

Story Points und Velocity lieferten laut Fallbeschreibung kaum verwertbare Erkenntnisse.

Die Organisation führte deshalb stärker Flow Metrics ein.

Teams betrachteten insbesondere:

Sie reduzierten begonnene Arbeit, bereinigten alte Tickets und verwendeten historische Daten für probabilistische Forecasts.

Nach ungefähr einem Jahr sank die Quote nicht abgeschlossener geplanter Arbeit laut Fallstudie von rund 60 bis 70 Prozent auf 20 bis 30 Prozent. Der Work in Progress wurde etwa halbiert. Gleichzeitig verbesserte sich die Kommunikation mit Stakeholdern.

Die Zahlen stammen aus einer dokumentierten Fallstudie und beweisen keine allgemeingültige Wirkung.

Das Beispiel zeigt aber gut, warum konkrete Flussdaten für Teams häufig hilfreicher sind als Story-Point-Diskussionen.

Ein Scrum Team produziert nicht nur Software oder andere Ergebnisse.

Es produziert Erkenntnisse.

Dafür müssen Ergebnisse irgendwann bei Nutzern ankommen.

Sinnvolle Kennzahlen sind deshalb:

Scrum.org ordnet solche Kennzahlen im Evidence-Based Management dem Bereich Time-to-Market zu.

Dabei geht es ausdrücklich darum, wie schnell eine Organisation:

Ein Team, das alle zwei Wochen ein Increment erstellt, aber nur zweimal jährlich reales Kundenfeedback bekommt, besitzt eine langsame Lernschleife.

Die Sprintlänge allein macht noch keine schnelle Organisation.

Ein Team kann seine Cycle Time senken und seinen Throughput erhöhen.

Wenn gleichzeitig Fehler und technische Schulden wachsen, wurde wenig gewonnen.

Deshalb gehören Qualitätskennzahlen zwingend dazu.

Zum Beispiel:

Für Softwareteams können ergänzend die DORA-Kennzahlen interessant sein.

DORA betrachtet unter anderem:

Die aktuelle DORA-Systematik trennt dabei ausdrücklich Durchsatz und Instabilität. Das verhindert, dass reine Geschwindigkeit zum alleinigen Ziel wird.

Das ist auch für Scrum entscheidend:

Schneller falsch liefern ist keine Verbesserung.

Der Sprint Goal ist das gemeinsame Ziel des Sprints.

Der Scrum Guide beschreibt ihn als Commitment des Sprint Backlogs und als Orientierung für die tägliche Anpassung der Arbeit.

Es kann deshalb sinnvoll sein zu betrachten:

Problematisch wird daraus eine Management-KPI wie:

„Teams müssen mindestens 95 Prozent ihrer Sprint Goals erreichen.“

Dann entsteht schnell Fehlverhalten.

Teams formulieren leichtere Ziele.

Oder Ziele so unpräzise, dass sie kaum verfehlt werden können.

Sprint-Goal-Erreichung eignet sich deshalb besser für Lernen als für Leistungsbewertung.

Eine hilfreiche Struktur liefert Evidence-Based Management von Scrum.org.

Das Framework betrachtet vier sogenannte Key Value Areas:

Welchen Wert erzeugt das Produkt heute?

Beispiele:

Welcher zusätzliche potenzielle Wert ist noch nicht erschlossen?

Beispiele:

Wie schnell kann die Organisation Ergebnisse liefern und daraus lernen?

Beispiele:

Wie gut kann die Organisation neue wertvolle Fähigkeiten entwickeln?

Beispiele:

Scrum.org schreibt bewusst keine festen Kennzahlen innerhalb dieser Bereiche vor. Organisationen sollen geeignete Messgrößen passend zum Produkt und zum jeweiligen Ziel auswählen.

Genau das ist der richtige Ansatz.

Nicht jedes Scrum Team braucht dasselbe Dashboard.

Ein Softwareanbieter aus der Immobilienbranche nutzte Scrum bereits, hatte aber Schwierigkeiten zu bestimmen, welchen Wert die eigene Produktarbeit tatsächlich erzeugte.

Nach einer Evidence-Based-Management-Initiative verlagerte das Unternehmen seine Aufmerksamkeit stärker auf Value und messbare Geschäftsergebnisse.

Scrum.org berichtet anschließend vom stärksten Umsatzwachstum des Unternehmens innerhalb von zehn Jahren.

Auch hier gilt:

Die Fallstudie belegt keine einfache Kausalität.

Sie zeigt aber eine wichtige Richtung.

Agile Messung sollte nicht beim Teamprozess enden.

Sie muss irgendwann beim Kunden und beim Geschäftsergebnis ankommen.

Nicht jede verbreitete Kennzahl ist nutzlos.

Problematisch wird sie, wenn Unternehmen ihr eine Bedeutung geben, die sie nicht besitzt.

Velocity gehört zu den am häufigsten missbrauchten Scrum-Metriken.

Beispiel:

Team A:

70 Story Points.

Team B:

45 Story Points.

Ist Team A produktiver?

Diese Frage lässt sich daraus nicht beantworten.

Story Points entstehen aus teamspezifischen Schätzungen.

Die Skalen sind nicht normiert.

Teams können außerdem ihre Velocity erhöhen, indem sie schlicht anders schätzen.

Scrum.org warnt 2026 ausdrücklich davor, Velocity als Produktivitäts- oder Performance-Maß zu verwenden. Sie kann höchstens intern als grobe Planungshilfe dienen.

Eigene historische Planung unterstützen.

Teamvergleiche, Managementziele und Bonuskennzahlen.

Das Problem ähnelt Velocity.

Mehr Story Points bedeuten nicht automatisch:

Story Points messen eine Schätzung.

Kein wirtschaftliches Ergebnis.

„Alle Entwickler sind zu 100 Prozent ausgelastet.“

Das klingt effizient.

In komplexer Produktentwicklung ist es oft problematisch.

Maximale Auslastung führt leicht zu:

Ein Scrum Team ist kein Fließband, dessen Ziel maximale Personalauslastung lautet.

100 Tickets sind nicht automatisch besser als 50.

Vielleicht wurden die Items nur kleiner geschnitten.

Oder die zusätzlichen Tickets erzeugen keinen Wert.

Ticketanzahl kann für Flow-Analysen nützlich sein.

Als Erfolgskennzahl taugt sie kaum.

Ein Burndown kann Transparenz über Arbeit schaffen.

Ein perfektes Burndown beweist aber nicht, dass das Team:

Deshalb:

Werkzeug ja.

Business-KPI nein.

Arbeitsstunden messen Input.

Nicht Wert.

Mehr Stunden können sogar ein Warnsignal sein.

Zum Beispiel für:

Besonders gefährlich sind Kennzahlen wie:

Scrum arbeitet bewusst mit gemeinsamer Verantwortung des Scrum Teams für ein wertvolles, nutzbares Increment.

Individuelle Output-Kennzahlen fördern dagegen lokale Optimierung.

Menschen maximieren dann ihre persönliche Zahl statt das gemeinsame Ergebnis.

Ein Dashboard mit 30 Metriken schafft keine Klarheit.

„20 Features geliefert“ sagt nicht, ob Kunden davon profitieren.

Sobald Velocity zum Ziel wird, optimiert das Team Velocity.

Unterschiedliche Produkte und Systeme besitzen unterschiedliche Bedingungen.

Gerade bei Cycle Time können Verteilungen und Ausreißer wichtiger sein.

Ohne Ausgangswert lässt sich Verbesserung kaum beurteilen.

Kunden- und Business Value fehlen.

Wenn niemand auf eine Kennzahl reagiert, sollte man prüfen, warum sie überhaupt erhoben wird.

Kennzahlen helfen nicht, wenn eine Organisation Transparenz bestraft.

Zum Beispiel wenn:

Dann entsteht Goodhart’s Law in Reinform:

Wird eine Kennzahl selbst zum Ziel, verliert sie häufig ihren Wert als Kennzahl.

Die Lösung lautet deshalb nicht mehr Messung.

Sondern bessere Nutzung von Messung.

Ein praxistaugliches Dashboard benötigt häufig nicht mehr als fünf bis acht Kennzahlen.

Zum Beispiel:

Damit betrachtet das Team nicht nur:

Wie viel arbeiten wir?

Sondern:

Wie schnell lernen wir und welchen Wert erzeugen wir dabei?

Bevor eine neue Kennzahl eingeführt wird, sollte das Team fragen:

Gibt es auf die letzte Frage keine Antwort, ist die Kennzahl wahrscheinlich nicht besonders wichtig.

Besonders hilfreich sind Customer Outcomes, Produktnutzung, Fortschritt zum Product Goal, Cycle Time, Work in Progress, Work Item Age, Throughput, Qualitätskennzahlen und Time-to-Market.

Nicht als Leistungskennzahl. Velocity kann einem einzelnen Team intern bei der Planung helfen. Sie sollte aber nicht verwendet werden, um Produktivität zu messen oder Teams miteinander zu vergleichen.

Historischer Throughput und Cycle Time können zusammen mit probabilistischen Forecasting-Verfahren gute Hinweise liefern. Scrum.org nennt probabilistische Forecasts ausdrücklich als Möglichkeit für unsichere Arbeit.

Es gibt keine einzelne Kennzahl, die zuverlässig „Agilität“ misst. Sinnvoller ist eine Kombination aus Wert, Time-to-Market, Innovationsfähigkeit und Flow.

Nein. Der Scrum Guide schreibt weder Story Points noch Velocity vor. Scrum Teams können andere Methoden für Planung und Forecasting verwenden.

Die vier Flow Metrics sind keine verpflichtenden Bestandteile des Scrum Guides. Sie können Scrum jedoch sinnvoll ergänzen. Scrum.org verbindet Scrum und Kanban ausdrücklich und nennt WIP, Cycle Time, Work Item Age und Throughput als Kernmetriken dieser Kombination.

Die wichtigsten Scrum KPIs messen nicht, wie beschäftigt ein Team ist.

Sie zeigen:

Entsteht Wert?

Lernen wir schnell?

Fließt Arbeit zuverlässig?

Verbessert sich unser Produkt?

Bleibt die Qualität stabil?

Deshalb sind Customer Outcomes, Product-Goal-Fortschritt, Cycle Time, Work in Progress, Work Item Age, Throughput, Produktqualität und Time-to-Market deutlich aussagekräftiger als viele klassische Agile-Dashboards.

Velocity, Story Points oder Burndown Charts müssen deshalb nicht komplett verschwinden.

Man muss nur aufhören, ihnen eine Bedeutung zuzuschreiben, die sie nicht besitzen.

Das größte Risiko liegt nicht darin, die falsche Zahl zu erfassen.

Es liegt darin, aufgrund dieser Zahl die falsche Entscheidung zu treffen.

Ein gutes Scrum Team misst deshalb nicht möglichst viel.

Es misst genau das, was ihm hilft, die nächste bessere Entscheidung zu treffen.

PURE Consultant unterstützt Unternehmen dabei, Scrum Teams, Product Owner und Führungskräfte auf sinnvolle Kennzahlen auszurichten – weg von Aktivitäts- und Auslastungsmetriken und hin zu Flow, Produktwirkung und messbarem Business Value.