﻿# Team Metrics

Version: 3 | Last modified: 2026-02-24T15:38:26.440+01:00
Source: confluence page ID 553943905

---

Die folgenden Kennzahlen dienen der Transparenz Ã¼ber unseren Arbeitsfluss und unsere Zusammenarbeit auf Teamebene.
Sie unterstÃ¼tzen uns dabei, Muster zu erkennen, EngpÃ¤sse sichtbar zu machen und fundierte Entscheidungen zur kontinuierlichen Verbesserung zu treffen.
Dabei gilt:
Kennzahlen sind Systemindikatoren, keine Leistungsbewertung einzelner Personen oder Teams.

Sie zeigen Trends und Muster â keine isolierten Wahrheiten.

Ihre Aussagekraft entsteht erst durch regelmÃ¤Ãige gemeinsame Reflexion.

Einzelne Werte sind weniger relevant als Entwicklungen Ã¼ber mehrere Iterationen hinweg.

Unser Ziel ist nicht maximale Geschwindigkeit, sondern ein stabiler, nachhaltiger und vorhersagbarer Arbeitsfluss.
Kennzahlen helfen uns insbesondere dabei:
Fokus und Priorisierung zu reflektieren

EngpÃ¤sse frÃ¼hzeitig zu erkennen

QualitÃ¤t und StabilitÃ¤t im Blick zu behalten

Entscheidungsprozesse zu verbessern

Transparenz gegenÃ¼ber Stakeholdern herzustellen

Wir nutzen diese Kennzahlen bewusst als GesprÃ¤chsgrundlage in Reviews, Retrospektiven und strategischen Abstimmungen.
Sie sind ein Instrument zur Verbesserung unseres ARTs â nicht zur Kontrolle von Teams.

Kennzahl | Beschreibung der Kennzahl | Anwendungsbeispiele | Typische Muster und Interpretation | 
Flow Distribution | Flow Distribution zeigt die prozentuale Verteilung der erledigten Arbeit nach Arbeitstypen (z. B. Feature, Bug, Enabler/Technical Debt, Support, Spike) innerhalb eines definierten Zeitraums (Sprint, Monat, Quartal).
Sie macht sichtbar, wofÃ¼r das Team seine KapazitÃ¤t tatsÃ¤chlich verwendet und welche impliziten PrioritÃ¤ten im Arbeitsalltag entstehen.
Die Kennzahl dient der Reflexion des Arbeitsfokus und ist keine Leistungskennzahl.
 | Strategischen Fokus Ã¼berprÃ¼fen: Entspricht die tatsÃ¤chliche Verteilung unserer geplanten Ausrichtung?
 QualitÃ¤tsentwicklung beobachten: Steigt der Bug-Anteil Ã¼ber mehrere Sprints hinweg?Â 
Balance diskutieren: Wie viel KapazitÃ¤t investieren wir in neue Features vs. Wartung oder technische Verbesserungen?
Transparenz gegenÃ¼ber Stakeholdern schaffen: Warum liefern wir weniger Features, wenn Support oder Stabilisierung dominieren?- Nachhaltigkeit prÃ¼fen: Investieren wir ausreichend in Enabler und technische Schulden?
 | Hoher Bug-Anteil: mÃ¶gliches QualitÃ¤tsproblem, instabile Architektur oder fehlende Testautomatisierung.Â 
Kaum Enabler/Tech Debt: kurzfristiger Lieferdruck, Risiko fÃ¼r langfristige Wartbarkeit.
Hoher Support-/Maintenance-Anteil: hohe Betriebslast oder unklare Produktverantwortung.
Stark schwankende Verteilung: fehlender Fokus oder hÃ¤ufige PrioritÃ¤tswechsel.
Sehr hoher Feature-Anteil bei gleichzeitig steigender Bug-Quote: QualitÃ¤tsrisiko durch Lieferdruck.
 | 
Lead Time | Lead Time misst die Zeit vom Start der Bearbeitung eines Vorgangs bis zu dessen Fertigstellung (z. B. von âIn Progressâ bis âDoneâ).Sie zeigt, wie schnell Arbeit durch das System flieÃt und wie stabil der Lieferprozess ist.
Lead Time ist eine Systemkennzahl zur Prozessverbesserung und keine Bewertung einzelner Personen.
 | LieferfÃ¤higkeit verbessern und realistische Forecasts ableiten.
Vorhersagbarkeit erhÃ¶hen: Wie stabil ist unsere durchschnittliche Durchlaufzeit?
EngpÃ¤sse und Wartezeiten identifizieren (in Kombination mit Status-Verweildauer).
Wirkung von ProzessÃ¤nderungen messen (z. B. WIP-Limits, Pair Programming, Automatisierung).
Ticket-Zuschnitt prÃ¼fen: Sind Stories zu groÃ oder unklar geschnitten?
 | Kontinuierlicher Anstieg: SystemÃ¼berlastung oder zu viel parallele Arbeit (WIP).
Hohe Streuung: stark unterschiedliche TicketgrÃ¶Ãen oder wechselnde PrioritÃ¤ten.
Viele AusreiÃer mit sehr langer Dauer: Blockaden, AbhÃ¤ngigkeiten oder externe Freigaben.
Sinkender und stabiler Trend: verbesserter Flow und klarere Ãbergaben.
Sehr kurze Lead Time bei hoher Fehlerquote: mÃ¶glicher QualitÃ¤tskompromiss.
 | 
Umgesetzte vs. verworfene Ideen | Diese Kennzahl zeigt das VerhÃ¤ltnis zwischen realisierten und bewusst gestoppten bzw. nicht weiterverfolgten Produktideen im gewÃ¤hlten Zeitraum.
Als âIdeeâ gelten z. B. Initiativen, Epics oder grÃ¶Ãere Features â nicht einzelne User Stories.Die Kennzahl macht sichtbar, wie konsequent priorisiert wird und ob bewusste Entscheidungsprozesse stattfinden.
 | Fokus prÃ¼fen: Setzen wir alles um oder priorisieren wir konsequent?
EntscheidungsqualitÃ¤t reflektieren: Werden Ideen frÃ¼h validiert oder erst spÃ¤t verworfen?-
Stakeholder-Transparenz schaffen: Produktentwicklung bedeutet auch bewusstes Nicht-Umsetzen.
Discovery-Prozess verbessern: Hypothesen, Erfolgskriterien und Experimente klarer definieren.
Â Ressourcensteuerung prÃ¼fen: Wie viel Aufwand investieren wir in Ideen, die spÃ¤ter gestoppt werden?
 | Fast alle Ideen werden umgesetzt: fehlende Priorisierung oder StrategieunschÃ¤rfe.
Viele spÃ¤te AbbrÃ¼che: zu geringe frÃ¼he Validierung oder unklare Zieldefinition.
Viele frÃ¼he Stopps mit klarer BegrÃ¼ndung: gesunder Filtermechanismus.
Sehr hoher Verwerfungsanteil: mÃ¶glicherweise zu strenge Kriterien oder fehlende KapazitÃ¤t.- Kaum verworfene Ideen trotz hoher Auslastung: Risiko von Ãberfrachtung.
 | 
Average Days in Status | Average Days in Status zeigt die durchschnittliche Verweildauer von VorgÃ¤ngen in einzelnen Workflow-Status (z. B. âIn Progressâ, âCode Reviewâ, âTestingâ, âWaiting for Approvalâ).
Die Kennzahl macht sichtbar, in welchen Prozessschritten Arbeit besonders lange verbleibt und wo Wartezeiten entstehen.
Sie dient der Identifikation von EngpÃ¤ssen und Prozessineffizienzen.
 | Engpassanalyse: Welcher Status hat die lÃ¤ngste Verweildauer?
Wartezeiten sichtbar machen (z. B. Review, Abnahme, Deployment).
WIP-Management reflektieren: Lange âIn Progressâ-Zeiten als Hinweis auf zu viel ParallelitÃ¤t.
KapazitÃ¤tsungleichgewichte erkennen (z. B. Test- oder Review-EngpÃ¤sse).- Wirkung von Prozessverbesserungen messbar machen.
 | Ein Status sticht deutlich heraus: lokaler Engpass im System.Â 
Lange Review- oder Testing-Phasen: fehlende KapazitÃ¤t, zu groÃe Tickets oder unklare Ãbergabekriterien.
Lange âIn Progressâ-Zeit: zu viel parallele Arbeit und Kontextwechsel.
Mehrere lange Warte-Status: viele Ãbergaben oder externe AbhÃ¤ngigkeiten.-
Sehr geringe Verweildauer in allen Status: kleine, gut geschnittene Arbeitspakete und stabiler Flow.
 |
