DevOps, Agile und Scrum Metriken Interview-Fragen: DORA, Velocity und EVM (2026)

Projektmanagement-Metriken sind essenziell, um die Teamleistung zu messen, Engpaesse zu identifizieren und kontinuierliche Verbesserung voranzutreiben. Dieser Leitfaden behandelt wichtige Metriken aus den Bereichen DevOps, Agile, Scrum und traditionellem Projektmanagement sowie haeufige Interviewfragen, die Ihnen bei Bewerbungen fuer Senior-Engineering- und Management-Positionen begegnen werden.

DevOps Metriken (DORA Metrics)

Die DORA (DevOps Research and Assessment) Metriken sind der Goldstandard fuer die Messung der DevOps-Leistung:

1. Deployment Frequency

Was wird gemessen: Wie oft Ihr Team Code in die Produktion deployt.

Leistungsstufe	Haeufigkeit
Elite	Auf Abruf (mehrmals taeglich)
Hoch	Woechentlich bis monatlich
Mittel	Monatlich bis alle 6 Monate
Niedrig	Weniger als einmal pro 6 Monate

Interviewfrage: "Ihr Team deployt einmal im Monat. Welche Schritte wuerden Sie unternehmen, um die Deployment-Haeufigkeit zu erhoehen?"

Gute Antwort: "Ich wuerde damit beginnen zu analysieren, was haeufigere Deployments blockiert. Haeufige Probleme sind: manuelle Test-Engpaesse (automatisierte Tests implementieren), grosse Batch-Groessen (Arbeit in kleinere Inkremente aufteilen), fehlende CI/CD-Automatisierung (in Pipeline-Infrastruktur investieren) und Angst vor Deployments (Feature Flags und automatische Rollbacks implementieren). Ich wuerde die aktuelle Cycle Time messen, den groessten Engpass identifizieren und die Verbesserungsbemuehungen darauf konzentrieren."

2. Lead Time for Changes

Was wird gemessen: Zeit vom Code-Commit bis zum Produktions-Deployment.

Leistungsstufe	Lead Time
Elite	Weniger als 1 Stunde
Hoch	1 Tag bis 1 Woche
Mittel	1 Woche bis 1 Monat
Niedrig	Mehr als 1 Monat

Interviewfrage: "Wie wuerden Sie die Lead Time von 2 Wochen auf 2 Tage reduzieren?"

Gute Antwort: "Ich wuerde den Wertstrom abbilden, um Wartezeiten vs. Arbeitszeiten zu identifizieren. Typischerweise besteht die meiste Lead Time aus Warten - auf Code Review, QA-Freigabe, Deployment-Fenster. Loesungen umfassen: Trunk-based Development implementieren, Code-Review-Gates automatisieren, paralleles Testen und Self-Service-Deployments ermoeglichen. Ich wuerde Metriken-Dashboards einrichten, um jede Phase zu verfolgen, und mich darauf konzentrieren, die laengsten Wartezeiten zuerst zu eliminieren."

3. Mean Time to Recovery (MTTR)

Was wird gemessen: Durchschnittliche Zeit zur Wiederherstellung des Dienstes nach einem Vorfall.

Leistungsstufe	MTTR
Elite	Weniger als 1 Stunde
Hoch	Weniger als 1 Tag
Mittel	1 Tag bis 1 Woche
Niedrig	Mehr als 1 Woche

Interviewfrage: "Die MTTR Ihres Teams betraegt 8 Stunden. Wie wuerden Sie diese auf unter 1 Stunde bringen?"

Gute Antwort: "Schnelle Wiederherstellung erfordert: schnelle Erkennung (umfassendes Monitoring und Alerting), schnelle Diagnose (zentralisiertes Logging, verteiltes Tracing, Runbooks) und schnelle Behebung (automatisierte Rollbacks, Feature Flags, Infrastructure as Code). Ich wuerde Bereitschaftsrotationen mit klaren Eskalationspfaden implementieren, regelmaessige Incident-Response-Uebungen durchfuehren und sicherstellen, dass jeder Vorfall ein schuldzuweisungsfreies Post-Mortem hat, um Wiederholungen zu verhindern."

4. Change Failure Rate

Was wird gemessen: Prozentsatz der Deployments, die Produktionsfehler verursachen.

Leistungsstufe	Fehlerrate
Elite	0-15%
Hoch	16-30%
Mittel	31-45%
Niedrig	46-60%

Interviewfrage: "30% Ihrer Deployments schlagen fehl. Was ist Ihr Verbesserungsplan?"

Gute Antwort: "Hohe Fehlerraten deuten auf Qualitaetsprobleme frueher in der Pipeline hin. Ich wuerde implementieren: umfassende automatisierte Tests (Unit, Integration, e2e), Staging-Umgebungen, die die Produktion widerspiegeln, Canary Deployments, um Probleme frueh zu erkennen, und verbesserte Code-Review-Praktiken. Ich wuerde auch fehlgeschlagene Deployments analysieren, um Muster zu identifizieren - stammen die Fehler von bestimmten Services, Teams oder Aenderungsarten? Dann die Ursachen gezielt angehen."

Agile Metriken

Velocity

Was wird gemessen: Story Points, die pro Sprint abgeschlossen werden.

Velocity = Summe der abgeschlossenen Story Points im Sprint

Beispiel:
Sprint 1: 21 Punkte
Sprint 2: 24 Punkte
Sprint 3: 18 Punkte
Durchschnittliche Velocity: 21 Punkte

Interviewfrage: "Ein Stakeholder bittet Sie, sich auf 40 Story Points im naechsten Sprint zu verpflichten, obwohl Ihre durchschnittliche Velocity 25 betraegt. Wie antworten Sie?"

Gute Antwort: "Ich wuerde erklaeren, dass Velocity ein Planungswerkzeug ist, kein Leistungsziel. Eine Verpflichtung auf 40 Punkte wuerde wahrscheinlich zu unvollstaendiger Arbeit oder Qualitaetsabstrichen fuehren. Stattdessen wuerde ich besprechen: die wertvollsten 25 Punkte Arbeit priorisieren, identifizieren, ob es Blocker gibt, die wir entfernen koennten, um die Velocity nachhaltig zu steigern, oder ob wir mehr Teamkapazitaet benoetigen. Aufgeblaehte Verpflichtungen zerstoeren Vertrauen und Vorhersagbarkeit."

Sprint Burndown

Was wird gemessen: Verbleibende Arbeit waehrend des Sprints.

Interviewfrage: "Ihr Burndown-Chart zeigt, dass die Arbeit Mitte des Sprints zunimmt. Was bedeutet das und wie gehen Sie damit um?"

Gute Antwort: "Zunehmende Arbeit Mitte des Sprints signalisiert Scope Creep oder schlechte Schaetzung. Ich wuerde untersuchen: Werden nach der Sprint-Planung Anforderungen hinzugefuegt? Sind Stories schlecht definiert und erfordern mehr Arbeit als geschaetzt? Wird technische Schuld entdeckt? Loesungen umfassen: strengere Sprint-Commitment-Praktiken, besseres Story Refinement und das Aufteilen grosser Stories. Ich wuerde auch eine Team-Diskussion moderieren, um das Muster zu verstehen."

Cumulative Flow Diagram

Was wird gemessen: Arbeitsaufgaben in jeder Phase im Zeitverlauf.

Interviewfrage: "Ihr Cumulative Flow Diagram zeigt ein sich verbreiterndes 'In Progress'-Band. Was passiert?"

Gute Antwort: "Ein sich verbreiterndes Band zeigt einen Engpass an - Arbeit tritt schneller in diese Phase ein, als sie sie verlaesst. Bei 'In Progress' bedeutet das typischerweise zu viel WIP (Work in Progress). Ich wuerde WIP-Limits implementieren, um den Abschluss zu erzwingen, bevor neue Arbeit begonnen wird, identifizieren, warum Aufgaben feststecken (warten auf Review, blockierte Abhaengigkeiten), und moeglicherweise auf Aufgaben schwaermen, um den Rueckstand abzubauen. Das Ziel ist ein gleichmaessiger Fluss, nicht die Maximierung von Starts."

Cycle Time

Was wird gemessen: Zeit vom Arbeitsbeginn bis zur Fertigstellung.

Cycle Time = Abschlussdatum - Startdatum

Beispiel:
Story gestartet: Montag 9 Uhr
Story abgeschlossen: Mittwoch 15 Uhr
Cycle Time: 2,25 Tage

Interviewfrage: "Die durchschnittliche Cycle Time Ihres Teams betraegt 8 Tage fuer Stories. Wie wuerden Sie diese reduzieren?"

Gute Antwort: "Ich wuerde analysieren, wo die Zeit verbracht wird. Oft ist es: Warten auf Code Review (asynchrone Reviews implementieren, Pair Programming), Warten auf QA (Shift-left Testing, entwicklerverantwortete Qualitaet), Kontextwechsel (WIP begrenzen) und grosse Story-Groesse (Stories kleiner aufteilen). Ich wuerde den Workflow visualisieren, die Zeit in jeder Phase messen und systematisch die groessten Verzoegerungen angehen. Kleinere Stories reduzieren fast immer die Cycle Time."

Scrum-spezifische Metriken

Sprint Goal Success Rate

Was wird gemessen: Prozentsatz der Sprints, in denen das Sprint-Ziel erreicht wird.

Interviewfrage: "Ihr Team erreicht Sprint-Ziele nur in 40% der Faelle. Wie verbessern Sie das?"

Gute Antwort: "Niedrige Zielerreichung deutet auf Probleme mit Planung, Umfang oder Ausfuehrung hin. Ich wuerde untersuchen: Sind die Ziele zu ehrgeizig? Schleicht sich Scope Mitte des Sprints ein? Verursachen externe Abhaengigkeiten Verzoegerungen? Loesungen umfassen: fokussierte, erreichbare Sprint-Ziele erstellen; den Sprint vor Umfangsaenderungen schuetzen; die Schaetzung mit Planning Poker verbessern; und sicherstellen, dass Stories wirklich 'ready' sind vor der Sprint-Planung. Das Team sollte dies auch in Retrospektiven reflektieren."

Sprint Predictability

Predictability = (Abgeschlossene Punkte / Zugesagte Punkte) x 100%

Ziel: 80-100%

Beispiel:
Zugesagt: 30 Punkte
Abgeschlossen: 24 Punkte
Predictability: 80%

Interviewfrage: "Wie balancieren Sie Vorhersagbarkeit mit Ehrgeiz in der Sprint-Planung?"

Gute Antwort: "Ich wuerde 'Yesterday's Weather' verwenden - sich auf das verpflichten, was wir tatsaechlich in den letzten Sprints geliefert haben, nicht auf das, was wir hoffen zu liefern. Das baut Stakeholder-Vertrauen durch Zuverlaessigkeit auf. Fuer Ehrgeiz wuerde ich Stretch Goals identifizieren, die wertvoll sind, wenn sie abgeschlossen werden, aber nicht zugesagt sind. Mit der Zeit, wenn das Team Prozesse verbessert und Hindernisse beseitigt, steigt die nachhaltige Velocity natuerlich. Vorhersagbarkeit ermoeglicht bessere Geschaeftsplanung."

Defect Escape Rate

Was wird gemessen: In der Produktion gefundene Bugs vs. waehrend der Entwicklung gefundene.

Defect Escape Rate = (Produktions-Bugs / Gesamt gefundene Bugs) x 100%

Ziel: < 10%

Interviewfrage: "40% der Bugs werden in der Produktion gefunden. Was ist Ihre Qualitaetsstrategie?"

Gute Antwort: "Hohe Escape Rates deuten auf Qualitaetsprobleme in unserem Entwicklungsprozess hin. Ich wuerde implementieren: Definition of Done, die Testanforderungen enthaelt, automatisierte Tests auf mehreren Ebenen (Unit, Integration, e2e), Code-Review-Checklisten, die Testabdeckung enthalten, und fruehere QA-Einbindung im Prozess. Ich wuerde auch entwichene Defekte analysieren, um Muster zu finden - sind sie in bestimmten Bereichen, von bestimmten Aenderungstypen oder fehlenden Testszenarien?"

Traditionelle Projektmanagement-Metriken

Earned Value Management (EVM)

Wichtige EVM-Metriken:

Planned Value (PV) = Budgetierte Kosten der geplanten Arbeit
Earned Value (EV) = Budgetierte Kosten der abgeschlossenen Arbeit
Actual Cost (AC) = Tatsaechliche Kosten der abgeschlossenen Arbeit

Schedule Variance (SV) = EV - PV
  Positiv = vor dem Zeitplan
  Negativ = hinter dem Zeitplan

Cost Variance (CV) = EV - AC
  Positiv = unter Budget
  Negativ = ueber Budget

Schedule Performance Index (SPI) = EV / PV
  > 1,0 = vor dem Zeitplan
  < 1,0 = hinter dem Zeitplan

Cost Performance Index (CPI) = EV / AC
  > 1,0 = unter Budget
  < 1,0 = ueber Budget

Interviewfrage: "Ihr Projekt hat einen SPI von 0,8 und einen CPI von 0,9. Interpretieren Sie das und empfehlen Sie Massnahmen."

Gute Antwort: "SPI 0,8 bedeutet, dass wir 80% der geplanten Arbeit liefern - wir liegen hinter dem Zeitplan. CPI 0,9 bedeutet, dass wir mehr ausgeben als budgetiert fuer die abgeschlossene Arbeit - wir liegen ueber dem Budget. Das Projekt ist in beiden Dimensionen in Schwierigkeiten. Ich wuerde: den verbleibenden Umfang neu bewerten, um zu identifizieren, was gekuerzt oder verschoben werden kann, untersuchen, warum die Produktivitaet unter Plan liegt (Ressourcenprobleme, Anforderungsaenderungen, technische Probleme), die Stakeholder-Erwartungen mit ueberarbeiteten Prognosen neu setzen und strengere Kontrollen fuer die verbleibende Arbeit implementieren."

Resource Utilization

Utilization Rate = (Abrechenbare Stunden / Verfuegbare Stunden) x 100%

Ziel variiert nach Rolle:
- Entwickler: 70-80% (brauchen Puffer fuer Lernen, Meetings)
- Berater: 80-90% (Abrechnungsziel)
- Manager: 50-60% (Koordinationsaufwand)

Interviewfrage: "Die Auslastung Ihres Teams liegt bei 95%. Ist das gut oder schlecht?"

Gute Antwort: "95% Auslastung ist eigentlich besorgniserregend. Es bedeutet, dass das Team fast keinen Puffer hat fuer: die Behandlung unerwarteter Probleme, Abbau technischer Schulden, Lernen und Verbesserung, Unterstuetzung von Teamkollegen oder Innovation. Hohe Auslastung fuehrt zu Burnout, Qualitaetsproblemen und der Unfaehigkeit, jegliche Variation aufzufangen. Ich wuerde 70-80% fuer nachhaltige Leistung anstreben und die verbleibende Kapazitaet fuer Verbesserungsarbeit und normale Variabilitaet nutzen."

On-Time Delivery

On-Time Delivery Rate = (Puenktlich gelieferte Projekte / Gesamtprojekte) x 100%

Interviewfrage: "Nur 50% Ihrer Projekte werden puenktlich geliefert. Wie verbessern Sie das?"

Gute Antwort: "Ich wuerde analysieren, warum Projekte spaet sind: Scope Creep, schlechte Schaetzung, Ressourcenbeschraenkungen oder externe Abhaengigkeiten. Loesungen umfassen: bessere Anforderungserfassung im Vorfeld, Schaetztechniken, die Unsicherheit beruecksichtigen (PERT, Monte Carlo), Puffermanagement, klare Aenderungskontrollprozesse und fruehere Risikoidentifikation. Ich wuerde auch pruefen, ob Deadlines realistisch basierend auf Umfang und Ressourcen gesetzt werden oder ob es willkuerliche Ziele sind."

Team-Gesundheitsmetriken

Team Morale / eNPS

Was wird gemessen: Mitarbeiterzufriedenheit und Wahrscheinlichkeit, den Arbeitsplatz weiterzuempfehlen.

Interviewfrage: "Der eNPS Ihres Teams ist innerhalb von zwei Quartalen von +30 auf -10 gefallen. Wie untersuchen und beheben Sie das?"

Gute Antwort: "Dies ist ein signifikanter Rueckgang, der sofortige Aufmerksamkeit erfordert. Ich wuerde: 1:1-Gespraeche fuehren, um individuelle Bedenken zu verstehen, eine anonyme Umfrage durchfuehren, um spezifische Probleme zu identifizieren, untersuchen, was sich geaendert hat (neue Fuehrung, Projektdruck, Prozessaenderungen), und benachbarte Metriken betrachten (Fluktuation, Krankheitstage). Sobald die Ursachen identifiziert sind, wuerde ich einen Aktionsplan erstellen, transparent kommunizieren, was wir zur Verbesserung tun, und regelmaessig nachfassen. Unbehandelte Moralprobleme verschlimmern sich schnell."

Code Review Turnaround

Durchschnittliche Review-Zeit = Summe von (Review abgeschlossen - PR geoeffnet) / Anzahl PRs

Ziel: < 24 Stunden fuer erstes Review

Interviewfrage: "Code Reviews dauern durchschnittlich 3 Tage. Wie wirkt sich das auf das Team aus und wie wuerden Sie es beheben?"

Gute Antwort: "Langsame Reviews verursachen Kontextwechsel (Entwickler wechseln zu neuer Arbeit und muessen dann zurueckkehren), laengere Cycle Times, groessere Review-Batches (was Reviews schwieriger macht) und Frustration. Ich wuerde implementieren: SLAs fuer Review-Reaktionszeiten, kleinere PR-Groessen, Pairing um den Review-Bedarf zu reduzieren, rotierende Review-Aufgaben, dedizierte Review-Zeitbloecke und Tooling, das veraltete PRs anzeigt. Das Ziel sind schnelle Feedback-Schleifen."

Metriken-Antimuster

Haeufige Fehler

Interviewfrage: "Was sind die Gefahren bei der Messung individueller Entwicklerproduktivitaet?"

Gute Antwort: "Die Messung von Einzelpersonen schafft perverse Anreize: Gaming von Metriken (Story Points aufblaehen, Commits auffuellen), reduzierte Zusammenarbeit (anderen zu helfen schadet den eigenen Zahlen) und Rosinenpicken einfacher Arbeit. Es ignoriert, dass Softwareentwicklung ein Teamsport ist - die besten Entwickler machen oft andere produktiver durch Mentoring, Architekturentscheidungen und das Aufloesen von Blockaden. Ich wuerde Team-Ergebnisse und Flow-Metriken messen statt individuellen Output."

Goodhart's Law

"Wenn ein Mass zum Ziel wird, hoert es auf, ein gutes Mass zu sein."

Interviewfrage: "Wie verhindern Sie, dass Metriken manipuliert werden?"

Gute Antwort: "Ich wuerde mehrere komplementaere Metriken verwenden, die schwer gleichzeitig zu manipulieren sind - zum Beispiel sowohl Velocity ALS AUCH Qualitaetsmetriken. Ich wuerde mich auf Ergebnis-Metriken konzentrieren (Kundenzufriedenheit, Geschaeftsergebnisse) statt auf Aktivitaets-Metriken (Codezeilen, gemergte PRs). Ich wuerde Metriken als diagnostische Werkzeuge zur Verbesserung behandeln, nicht als Leistungsziele. Und ich wuerde regelmaessig wechseln, welche Metriken wir betonen, um die Manipulation einzelner Masse zu verhindern."

Aufbau eines Metriken-Dashboards

Empfohlene Metriken nach Rolle:

Engineering Manager:
- DORA Metriken (Deployment Frequency, Lead Time, MTTR, Change Failure Rate)
- Sprint Predictability
- Team-Kapazitaetsauslastung
- Code Review Turnaround
- Defect Escape Rate

Product Manager:
- Velocity/Durchsatz
- Cycle Time
- Sprint Goal Success Rate
- Kundenseitig gemeldete Probleme
- Feature-Adoptionsraten

Executive/Stakeholder:
- On-Time Delivery Rate
- Budgetabweichung
- Teamzufriedenheit (eNPS)
- Kundenzufriedenheit (NPS)
- Geschaeftsergebnis-Metriken

Fazit

Effektive Metriken treiben Verbesserung voran, wenn sie durchdacht eingesetzt werden. Konzentrieren Sie sich auf ausgewogene Scorecards, die mehrere Dimensionen messen, betonen Sie Team-Ergebnisse gegenueber individuellem Output, und denken Sie daran, dass Metriken Werkzeuge zum Lernen und Verbessern sind - keine Waffen fuer Schuldzuweisungen. In Interviews demonstrieren Sie, dass Sie sowohl verstehen, was zu messen ist, als auch die menschliche Dynamik rund um Messung.