DORA-Metriken 2026 richtig messen — Vollständiger Leitfaden
Von DevPrism Team
Die DORA-Metriken (DevOps Research and Assessment) sind zum De-facto-Standard für die Bewertung der Leistung von Engineering-Teams geworden. Aber zwischen akademischer Theorie und realer Implementierung klafft eine Lücke, die die meisten Organisationen nie korrekt überbrücken.
Die DORA-Metriken erklärt
1. Deployment Frequency (DF)
Definition: Wie oft Ihr Team pro Zeiteinheit in Produktion deployt.
| Klassifizierung | Frequenz |
|---|---|
| Elite | Mehrmals täglich |
| High | 1x täglich bis 1x wöchentlich |
| Medium | 1x wöchentlich bis 1x monatlich |
| Low | Weniger als 1x monatlich |
Häufiger Fehler: Deployments aus allen Umgebungen zählen. Nur Produktion zählt.
2. Lead Time for Changes (LT)
Definition: Zeit zwischen dem ersten Commit und dem Deployment in Produktion.
Dies ist die am meisten missverstandene Metrik. Die “Lead Time” beginnt nicht, wenn ein Ticket erstellt wird — sie beginnt beim ersten Commit, der ins Repository gepusht wird.
Berechnung:
Lead Time = timestamp(deploy_prod) - timestamp(first_commit_of_change)3. Change Failure Rate (CFR)
Definition: Prozentsatz der Deployments, die einen Produktionsvorfall verursachen.
CFR = deployments_causing_incidents / total_deployments × 100Achtung: Ein “Failure” ist nicht nur ein Rollback. Es ist jeder Vorfall, der eine Intervention erfordert (Hotfix, Fix Forward, Rollback).
4. Mean Time to Restore (MTTR)
Definition: Medianzeit zwischen der Erkennung eines Vorfalls und seiner Behebung.
Empfehlung: Verwenden Sie den Median, nicht den Mittelwert. Ein einziger 48-Stunden-Vorfall verzerrt den Durchschnitt komplett.
5. Deployment Rework Rate
Definition: der Anteil der jüngsten Arbeit, der neu gemacht werden musste, statt neuen Wert auszuliefern — kurz nach dem Schreiben wieder umgeschriebener Code, Hotfixes, Patches, Rollbacks. Ein Instabilitätssignal.
Es ist die jüngste Metrik: DORA hat sie im April 2026 in den Quick Check aufgenommen, der den Gesamtscore nun aus fünf statt vier Metriken bildet (DORA, 2026).
Warum sie die anderen vier ergänzt: Die Change Failure Rate zählt Deployments, die etwas kaputt machen; die Rework Rate zählt die Arbeit, die danach neu gemacht werden musste. Ein Team kann eine ordentliche CFR ausweisen und dennoch einen wachsenden Teil seiner Kapazität damit verbringen, den eigenen Releases hinterherzuräumen.
Die drei Fehler, die Ihre DORA-Daten verfälschen
Fehler #1: Manuell messen
Wenn Ihre DORA-Metriken auf einem Spreadsheet basieren, das ein EM jeden Freitag ausfüllt, sind Ihre Daten falsch. Punkt. Menschen vergessen, runden und verzerren unbewusst.
Lösung: Synchronisieren Sie Ihre Metriken direkt aus Ihren Tools (GitHub, Azure DevOps, GitLab) über deren APIs.
Fehler #2: Keine Korrelation mit anderen Signalen
Eine “Elite” Deployment Frequency bedeutet nichts, wenn Ihre Change Failure Rate explodiert. DORA muss als System gelesen werden, nicht als Sammlung unabhängiger KPIs.
Fehler #3: DORA zur Bewertung von Einzelpersonen nutzen
DORA misst die Leistung eines Teams und seines Systems. Niemals einer Einzelperson. Die Lead Time eines Entwicklers für dessen Jahresbewertung zu nutzen, ist ein toxisches Anti-Pattern.
Die Evolution 2026: DORA + AI Impact
Mit der massiven Verbreitung von KI-Assistenten (GitHub Copilot, Cursor, Devin Desktop, Claude Code, Codex) stellt sich eine Frage: Verbessert KI tatsächlich Ihre DORA-Metriken?
Genau das misst die AI Impact Cross-Korrelation:
- Sinkt die Lead Time bei Teams, die Copilot nutzen?
- Steigt der Throughput proportional zur KI-Akzeptanzrate?
- Verschlechtert sich die Qualität (CFR), wenn mehr KI-Vorschläge akzeptiert werden?
Messen Sie den echten ROI Ihrer KI-Assistenten. Testen Sie DevPrism kostenlos — AI Impact Cross-Korrelation ab dem Starter-Plan inklusive.