Skip to content

DORA-Metriken 2026 richtig messen — Vollständiger Leitfaden

By DevPrism Team

dora engineering-metrics guide

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 4 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 × 100

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

Fehler, die 90% der Teams machen

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 4 unabhängige 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.