Orchestrator/bahn/Analyse-O2C-C2S/sources/c2s/C2S-Kommunikation/teams/Team-Metrics.md

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. |