Velocity steigt. Fast alle Tickets werden abgeschlossen. Das Burndown sieht sauber aus. Ist das Scrum Team deshalb erfolgreich? Nicht unbedingt. Vielleicht entwickelt es sehr effizient Funktionen, die Kunden kaum nutzen. So misst du den Erfolg deines Scrum Teams wirklich: nicht anhand von Beschäftigung, sondern anhand von Wert, Fortschritt zum Produktziel, Lieferfähigkeit, Qualität und Lernfähigkeit. Genau hier machen viele Unternehmen einen Fehler. Sie messen Scrum statt Produkterfolg. Die Folge sind Kennzahlen, die gut aussehen, aber falsches Verhalten fördern. Ein gutes Messsystem macht dagegen sichtbar, ob das Team das richtige Problem löst, zuverlässig liefert und seine Wirkung verbessert.

Ein Scrum Team ist erfolgreich, wenn es kontinuierlich wertvolle, nutzbare Ergebnisse erzeugt, aus Feedback lernt und sein Produkt dadurch messbar verbessert.

Der Scrum Guide macht die Richtung deutlich. Das gesamte Scrum Team trägt Verantwortung dafür, in jedem Sprint ein wertvolles und nutzbares Increment zu erzeugen. Das Product Goal beschreibt das längerfristige Ziel, auf das das Team hinarbeitet. Scrum basiert dabei auf Transparenz, Inspektion und Anpassung.

Erfolg bedeutet deshalb nicht automatisch:

Diese Größen können Informationen liefern.

Sie beweisen aber keinen Erfolg.

Die wichtigste Frage lautet:

Was verbessert sich durch die Arbeit des Teams für Kunden und Unternehmen?

Das Problem beginnt häufig im Management.

Die Organisation möchte wissen:

„Wie gut funktioniert unser Scrum Team?“

Weil Business Outcomes schwerer messbar sind, greift sie auf leicht verfügbare Daten zurück:

Das Ergebnis sieht präzise aus.

Aber Präzision ist nicht dasselbe wie Aussagekraft.

Der aktuelle Evidence-Based-Management-Guide von Scrum.org unterscheidet deshalb ausdrücklich zwischen Inputs, Aktivitäten, Outputs, Outcomes und Impacts. Mehr Arbeitsstunden oder mehr ausgelieferte Features führen nicht automatisch zu besseren Kundenerlebnissen. Gerade Outcomes zeigen, was sich für Nutzer tatsächlich verbessert.

Das lässt sich auf eine einfache Wirkungskette reduzieren:

Arbeit → Output → Outcome → Business Impact

Beispiel:

Arbeit:
Das Team entwickelt einen neuen digitalen Antragsprozess.

Output:
Der Prozess ist produktiv.

Outcome:
Mehr Kunden schließen den Antrag ohne Hilfe ab.

Business Impact:
Conversion steigt und Servicekosten sinken.

Erst die letzten beiden Ebenen zeigen, ob die Arbeit wirklich erfolgreich war.

Ein belastbares Scrum-Dashboard sollte fünf Perspektiven kombinieren:

Keine einzelne Kennzahl kann alle fünf ersetzen.

Das ist die wichtigste Ebene.

Welche Kennzahl geeignet ist, hängt vom Produkt ab.

Typische Beispiele sind:

Ein Scrum Team entwickelt eine neue Funktion für einen digitalen Kundenservice.

Nach drei Sprints wurden 14 Funktionen ausgeliefert.

Das klingt zunächst gut.

Interessanter sind jedoch folgende Ergebnisse:

Jetzt entsteht ein Zusammenhang zwischen Teamarbeit und Wirkung.

Scrum.org empfiehlt mit Evidence-Based Management genau diese stärkere Orientierung an messbaren Kunden-Outcomes. Die vier Betrachtungsfelder Current Value, Unrealized Value, Time-to-Market und Ability-to-Innovate verbinden heutigen Wert, zukünftiges Potenzial und die Fähigkeit der Organisation, diesen Wert zuverlässig zu erzeugen.

Ein dokumentiertes Softwareunternehmen aus der Immobilienbranche wollte besser verstehen, welchen Wert seine Produktentwicklung tatsächlich erzeugte.

Statt die agile Transformation hauptsächlich über Prozesskennzahlen zu bewerten, führte die Organisation Evidence-Based Management ein. Ziele und messbare Geschäftsergebnisse rückten stärker in den Mittelpunkt.

Nach einem Jahr meldete das Unternehmen laut Fallstudie:

Das beweist nicht, dass die Messmethode allein diese wirtschaftliche Entwicklung verursacht hat.

Der Fall zeigt aber sehr gut den Perspektivwechsel:

Nicht Scrum-Aktivität wurde zum Erfolgskriterium, sondern Geschäftswirkung.

Ein Scrum Team braucht ein gemeinsames langfristiges Ziel.

Genau dafür existiert das Product Goal.

Das Problem:

Viele Teams besitzen zwar ein Product Goal, können aber nicht messen, ob sie ihm näherkommen.

Beispiel:

Schwach:

„Eine moderne Serviceplattform entwickeln.“

Besser:

„Den Anteil vollständig digital gelöster Serviceanfragen innerhalb von neun Monaten von 45 auf 70 Prozent erhöhen.“

Jetzt können passende Kennzahlen definiert werden:

Damit verändert sich auch das Product Backlog.

Es ist nicht mehr einfach eine Liste mit Dingen, die gebaut werden sollen.

Es enthält Ideen darüber, wie das gewünschte Ergebnis erreicht werden könnte.

Auch die Erreichung des Sprint Goals kann wertvolle Informationen liefern.

Aber nicht als Managementquote.

Eine Vorgabe wie:

„Jedes Team muss 95 Prozent seiner Sprint Goals erreichen“

führt leicht dazu, dass Teams weniger ambitionierte Ziele formulieren.

Besser ist:

Die Kennzahl dient dann dem Lernen.

Nicht der Leistungsbewertung.

Business Outcomes zeigen die Wirkung.

Sie sind aber häufig verzögerte Indikatoren.

Deshalb braucht ein Team zusätzlich Kennzahlen für sein Arbeitssystem.

Vier Flow Metrics sind besonders hilfreich:

Wie viel Arbeit ist begonnen, aber noch nicht fertig?

Wie lange dauert es, ein begonnenes Arbeitselement fertigzustellen?

Wie viele Arbeitselemente werden innerhalb eines Zeitraums fertig?

Wie lange befindet sich aktuell offene Arbeit bereits in Bearbeitung?

Scrum.org verbindet diese vier Kennzahlen ausdrücklich mit Scrum und Kanban. Besonders Work Item Age kann früh sichtbar machen, welche Aufgaben festhängen, bevor sie später als schlechte Cycle Time auftauchen.

Angenommen:

Team A schafft 80 Story Points.

Team B schafft 45.

Welches Team arbeitet erfolgreicher?

Das lässt sich daraus nicht ableiten.

Story Points beruhen auf teamspezifischen Schätzungen.

Eine echte Cycle Time von beispielsweise:

85 Prozent vergleichbarer Arbeitselemente werden innerhalb von höchstens acht Tagen abgeschlossen

liefert dagegen eine konkrete Aussage zur Lieferfähigkeit.

Ein reales, international arbeitendes Unternehmen hatte Schwierigkeiten mit hoher Sprint-Übertragung und schlechter Vorhersagbarkeit.

Rund 60 bis 70 Prozent der geplanten Arbeit wurden teilweise in spätere Zeiträume übertragen.

Die Teams begannen stärker mit:

zu arbeiten.

Sie reduzierten angefangene Arbeit, teilten große Items kleiner, beseitigten veraltete Arbeit und nutzten historische Daten für probabilistische Forecasts.

Nach rund einem Jahr sank der Übertrag laut dokumentierter Fallstudie auf etwa 20 bis 30 Prozent. Der Work in Progress wurde ungefähr halbiert. Gleichzeitig verbesserte sich die Zusammenarbeit mit Stakeholdern. Das Unternehmen selbst wurde in der Veröffentlichung ausdrücklich anonymisiert.

Der interessante Punkt ist nicht, dass jedes Unternehmen nun exakt diese vier Kennzahlen braucht.

Entscheidend ist:

Die Teams nutzten die Messwerte, um ihr System zu verändern.

Genau dafür sind Kennzahlen da.

Ein Team kann seinen Throughput steigern und gleichzeitig immer mehr Probleme produzieren.

Deshalb gehört Qualität zwingend in jede Erfolgsbewertung.

Geeignete Kennzahlen sind beispielsweise:

Bei Softwareprodukten können zusätzlich DORA-Metriken helfen.

Das aktuelle DORA-Modell betrachtet fünf Kennzahlen für Software Delivery:

DORA betont dabei ausdrücklich, dass Geschwindigkeit und Stabilität kein grundsätzlicher Zielkonflikt sind. Die Forschung zeigt Zusammenhänge zwischen diesen Delivery-Kennzahlen sowie organisatorischer Performance und dem Wohlbefinden von Teammitgliedern. Gleichzeitig warnt DORA vor Teamvergleichen und davor, einzelne Metriken zu Managementzielen zu machen.

Diese Kennzahlen sind kein allgemeiner Scrum-Standard.

Für Softwareteams können sie aber eine wichtige Ergänzung sein.

Hier wird die Messung schwieriger.

Ein Team kann kurzfristig hervorragende Delivery-Werte erzeugen und gleichzeitig ausbrennen.

Deshalb gehört auch die Fähigkeit zur nachhaltigen Zusammenarbeit in die Betrachtung.

Sinnvolle Themen sind:

Diese Größen sollten vorsichtig behandelt werden.

Sie sind keine Leistungskennzahlen für das Management.

Sie eignen sich vielmehr als Frühindikatoren und Gesprächsanlass für das Team.

Scrum.org empfiehlt deshalb beispielsweise, Team-Moral im Zeitverlauf zu betrachten und Veränderungen gemeinsam in Retrospektiven zu untersuchen. Niedrige Moral kann früh auf Probleme wie technische Schulden, fehlenden Produktwert oder organisatorische Blockaden hinweisen.

Empirie funktioniert nur, wenn Menschen Probleme sichtbar machen.

Wenn niemand sagen darf:

dann hilft auch das beste Dashboard wenig.

Ein scheinbar grünes Team kann in Wirklichkeit bereits tiefrot sein.

Für viele Teams reicht eine überschaubare Scorecard.

Mehr ist nicht automatisch besser.

Die wichtigste Regel:

Jede Kennzahl muss eine Frage beantworten, aus der eine mögliche Entscheidung folgt.

Wenn niemand weiß, was er bei einer Veränderung des Werts tun würde, ist die Metrik vermutlich nicht besonders wichtig.

Velocity kann intern bei einer teamspezifischen Planung helfen.

Sie ist aber keine normierte Maßeinheit.

Deshalb ist diese Aussage wertlos:

„Team A hat eine Velocity von 70 und Team B nur 45.“

Teams schätzen unterschiedlich.

Auch innerhalb desselben Teams kann sich die verwendete Skala verändern.

Velocity eignet sich deshalb nicht für:

100 Punkte können wirtschaftlich wertloser sein als fünf Punkte.

Die Menge geschätzter Arbeit sagt nichts über Produktnutzen.

Teams können Tickets kleiner schneiden.

Dann steigt die Zahl automatisch.

Der Kunde hat davon nichts.

Eine hundertprozentige Personalauslastung klingt effizient.

Bei komplexer Wissensarbeit kann sie jedoch:

Optimiert werden sollte der Arbeitsfluss.

Nicht die Belegung jedes Menschen.

Stunden sind Input.

Nicht Ergebnis.

Mehr Stunden können sogar auf Probleme hinweisen.

Ein Burndown kann dem Team helfen.

Ein perfekter Verlauf zeigt aber nur, dass geplante Arbeit ungefähr entsprechend der Darstellung verschwindet.

Er beweist weder Kundennutzen noch Qualität.

100 Prozent Meetingteilnahme bedeutet nicht, dass Scrum funktioniert.

Die bessere Frage lautet:

Hat das Event eine relevante Inspektion oder Anpassung ermöglicht?

„Welches unserer zehn Scrum Teams ist das produktivste?“

Diese Frage führt schnell in die falsche Richtung.

Teams arbeiten mit:

DORA warnt aus genau diesem Grund vor Vergleichen zwischen stark unterschiedlichen Anwendungen und Teams. Die Kennzahlen sollen vor allem Verbesserung innerhalb des eigenen Kontextes unterstützen.

Besser ist deshalb:

Vergleiche ein Team mit seiner eigenen Vergangenheit.

Nicht mit einem anderen Team.

Ein gutes Messsystem braucht beide.

Sie zeigen eingetretene Ergebnisse:

Sie können früh warnen:

Wer nur Business Outcomes betrachtet, erkennt Probleme möglicherweise zu spät.

Wer nur Frühindikatoren misst, weiß dagegen nicht, ob am Ende wirklich Wert entsteht.

Die Kombination ist entscheidend.

25 Metriken erzeugen selten 25-mal mehr Erkenntnis.

Mehr Arbeit ist nicht automatisch bessere Arbeit.

Sobald Teams für eine Kennzahl belohnt werden, steigt der Anreiz, genau diese Zahl zu optimieren.

Ein schnelleres Team kann schneller am Markt vorbeientwickeln.

Ohne Ausgangswert lässt sich Verbesserung schwer beurteilen.

Eine Zahl erklärt selten die Ursache.

Scrum basiert auf gemeinsamer Verantwortung.

Individuelle Ticket-, Story-Point- oder Commit-Ziele fördern lokale Optimierung.

Produktentwicklung besitzt natürliche Schwankungen.

Trends sind oft relevanter als einzelne Ausreißer.

Messung hilft wenig, wenn die Organisation Transparenz bestraft.

Besonders kritisch ist es, wenn:

Dann entsteht Mess-Theater.

Mehr Dashboards lösen das Problem nicht.

Ein aktueller Scrum.org-Beitrag zu Flow Metrics bringt die praktische Logik gut auf den Punkt: Wenn Kennzahlen nicht verändern, was ein Unternehmen startet, stoppt, beschleunigt, verkleinert oder entscheidet, helfen sie wahrscheinlich noch nicht ausreichend.

Frage:

Was soll für Kunden oder Unternehmen besser werden?

Zum Beispiel:

Self-Service-Nutzung von 50 auf 70 Prozent erhöhen.

Zum Beispiel:

Wo steht das Team heute?

Ohne Baseline bleibt jede Verbesserung abstrakt.

Nicht:

„Cycle Time verbessern.“

Sondern:

„85 Prozent vergleichbarer Arbeit innerhalb von maximal acht Tagen abschließen.“

Nicht nur Management-Reporting.

Nutze die Daten in:

Eine Metrik, die keine neuen Erkenntnisse mehr liefert, darf verschwinden.

Messung ist kein Selbstzweck.

Ein erfolgreiches Scrum Team sollte diese Fragen beantworten können:

Wenn ein Team dagegen vor allem weiß:

fehlt wahrscheinlich ein Teil der relevanten Perspektive.

Über eine Kombination aus Kunden- und Business Outcomes, Fortschritt zum Product Goal, Flow, Qualität, Vorhersagbarkeit sowie Teamfähigkeit. Eine einzelne Kennzahl reicht nicht aus.

Nein. Velocity kann intern zur Planung verwendet werden, misst aber weder Kundennutzen noch Produktivität zuverlässig. Teams sollten auch nicht anhand ihrer Velocity miteinander verglichen werden.

Wenn nur eine Perspektive priorisiert werden müsste, wäre es der messbare Kunden- beziehungsweise Produkt-Outcome. Scrum dient dazu, Wert zu erzeugen. Prozessmetriken helfen lediglich dabei, diese Fähigkeit zu verbessern.

Bei komplexer Produktentwicklung ist eine einzelne Produktivitätskennzahl problematisch. Sinnvoller ist die Kombination aus erzieltem Outcome, Durchfluss, Qualität und nachhaltiger Lieferfähigkeit.

Besonders verbreitet sind Work in Progress, Cycle Time, Throughput und Work Item Age. Sie ergänzen Scrum und helfen, Fokus, Lieferfähigkeit und Engpässe sichtbar zu machen.

Sie kann zur Reflexion hilfreich sein. Als harte Performance-KPI kann sie jedoch Fehlanreize setzen, weil Teams ihre Ziele dann leichter formulieren könnten.

Ein erfolgreiches Scrum Team erkennt man nicht daran, dass es Scrum besonders sichtbar betreibt.

Und auch nicht daran, dass es möglichst viel Arbeit erledigt.

Die entscheidenden Fragen lauten:

Erzeugen wir mehr Wert?

Bewegen wir uns auf unser Product Goal zu?

Fließt Arbeit zuverlässig?

Bleibt die Qualität stabil?

Lernen wir aus den Ergebnissen?

Das verändert die Messung grundlegend.

Velocity und Story Points rücken in den Hintergrund.

Customer Outcomes, Product Goals, Flow, Qualität und Lernfähigkeit rücken nach vorne.

Der wichtigste Perspektivwechsel lautet:

Nicht das Team soll eine Kennzahl optimieren. Die Kennzahl soll dem Team helfen, sein Produkt und sein Arbeitssystem zu verbessern.

Genau darin steckt die Logik von Scrum: Transparenz schaffen, Ergebnisse überprüfen und auf Basis realer Erkenntnisse handeln.

PURE Consultant unterstützt Unternehmen dabei, Scrum Teams und ihre Steuerung von reinen Aktivitätskennzahlen auf messbare Produktwirkung, bessere Flow-Metriken und belastbare Business Outcomes auszurichten.