DORA Metrics.
Messen. Verstehen.
Verbessern.
Deployment Frequency, Lead Time for Changes, Change Failure Rate und Mean Time to Recovery — der Goldstandard zur Messung der Software-Delivery-Performance.
Andreas Schönfeld
Geschäftsführer & DevOps-Berater, Comquent GmbH
18+ Jahre Erfahrung in DevOps, CI/CD und Industrial Automation
DORA-Metriken (englisch DORA Metrics) sind die vier zentralen DevOps-Metriken zur Messung der Delivery-Performance: Deployment Frequency (Deployments pro Tag/Woche), Lead Time for Changes (Commit-zu-Deploy-Dauer), Change Failure Rate (Anteil fehlerhafter Releases) und Mean Time to Recovery (Wiederherstellungszeit nach Incidents). Sie stammen aus dem Forschungsprogramm DORA — DevOps Research and Assessment — und korrelieren nachweislich mit Geschäftserfolg. Elite-Performer deployen mehrmals täglich mit Lead Times unter 1 Stunde und MTTR unter 1 Stunde. Seit 2021 kommt Reliability als fünfte Metrik hinzu.
Einordnung: DORA Metrics sind eine Mess-Methode aus dem Cloud-/SaaS-Umfeld — nicht die einzige. Für Industrial DevOps, Embedded und OT-Kontexte ergänzen wir DORA um Reifegrad-Stufen für Versionierung, Test-Abdeckung, Toolchain-Konsolidierung und IEC-62443-Pipeline-Gates. Wer den eigenen Stand schnell einordnen möchte, startet beim DevOps-Reifegrad-Check; der Industrial-DevOps-Leitfaden setzt DORA in den industriellen Kontext. Die Kurzdefinition aller vier Kennzahlen liefert der Glossar-Eintrag DORA-Metriken.
Ohne Metriken
bleibt DevOps
Bauchgefühl.
„Wir sind schneller geworden." „Die Qualität hat sich verbessert." — Solche Aussagen hören wir häufig. Aber auf die Nachfrage „Um wie viel schneller?" wird es still. Fast jedes Team startet an genau diesem Punkt: Das Gefühl stimmt, nur belegen kann es niemand — spätestens in der Budget-Runde wird das zum Problem.
Hier kommen die DORA Metrics ins Spiel — die vier DevOps-Metriken, die sich als Standard der Erfolgsmessung durchgesetzt haben. Entwickelt vom DORA-Team (heute Teil von Google Cloud), basieren sie auf Forschung mit Daten von über 36.000 Fachleuten weltweit. Sie korrelieren nachweislich mit dem Geschäftserfolg von Softwareorganisationen.
Grundlage des jährlichen State of DevOps Report.
Quelle: Accelerate State of DevOps Report 2024 · DORA / Google Cloud
Wofür stehen die DORA-Metriken?
DORA steht für DevOps Research and Assessment — das Forschungsprogramm, das die Kennzahlen seit 2014 erhebt und seit 2018 zu Google Cloud gehört. Nicht zu verwechseln mit dem Digital Operational Resilience Act, der ebenfalls als DORA abgekürzt wird: Das ist eine EU-Verordnung für den Finanzsektor und hat mit DevOps-Messung nichts zu tun.
Die Verwechslung ist keine Randnotiz — beide Begriffe landen in denselben Suchergebnissen, und in Meetings mit Compliance-Beteiligung reden die Anwesenden regelmäßig aneinander vorbei. Wer über Delivery-Kennzahlen spricht, meint das Forschungsprogramm; die aufsichtsrechtliche Seite erklärt der Glossar-Eintrag zur DORA-Verordnung (Digital Operational Resilience Act).
Ist die DORA-Messung bei Ihnen gerade ein Thema?
Wir fragen kurz, wie dringend das Thema bei Ihnen gerade ist. Je nach Antwort zeigen wir Ihnen direkt den passenden nächsten Schritt — ganz ohne Formular.
DORA misst Outcomes.— Forsgren, Humble, Kim · „Accelerate" (2018)
Velocity misst nur
geschätzten Aufwand.
- 01Messen tatsächliche Delivery-Leistung
- 02Korrelieren mit Geschäftserfolg
- 03Branchenübergreifend vergleichbar
- 04Schwer zu manipulieren
- 05Berücksichtigen Geschwindigkeit UND Stabilität
- 01Messen nur geschätzten Aufwand, nicht Wertlieferung
- 02Kein Zusammenhang mit Geschäftserfolg belegt
- 03Nicht zwischen Teams vergleichbar
- 04Leicht aufzublähen (Inflation)
- 05Ignorieren Qualität und Stabilität
Was sind die DORA-Metriken in agilen Projekten?
In agilen Projekten ersetzen die DORA-Metriken nicht die Sprint-Planung, sondern die Erfolgsmessung. Velocity beantwortet, wie viel ein Team in einem Sprint geschafft hat; die DORA-Metriken beantworten, wie viel davon beim Nutzer angekommen ist und wie stabil es dort läuft. Erhoben werden sie pro Team und pro Delivery-Pipeline, nicht pro Sprint.
Der häufigste Fehler dabei: die vier Werte in das Sprint-Review zu heben und wie Velocity zu behandeln. Ein einzelner Sprint sagt über die Lead Time wenig aus — der Trend über ein Quartal dagegen sehr viel. Und sobald die Zahlen in die Team-Bewertung einfließen, werden sie optimiert statt verbessert: Deployments werden kleingeschnitten, Incidents nicht mehr als Change Failure gezählt. Die Metriken gehören dem Team, das mit ihnen arbeitet, nicht dem Reporting darüber.
Die 4 DORA-Metriken.
Geschwindigkeit
und Stabilität.
Jede DORA-Metrik beleuchtet einen anderen Aspekt Ihrer Delivery-Performance. Gemeinsam bilden sie ein ausgewogenes Bild aus Geschwindigkeit (Deployment Frequency, Lead Time) und Stabilität (Change Failure Rate, MTTR).
- /01Deployment Frequency · Deployment-Häufigkeit
Was ist Deployment Frequency (Deployment-Häufigkeit)?
Deployment Frequency misst, wie oft ein Team erfolgreich Code in die Produktion ausliefert — die Throughput-Metrik der Software-Delivery.
Wie oft deployt Ihr Team erfolgreich in die Produktion? Diese Metrik misst die Geschwindigkeit, mit der Ihr Team Wert an Kunden liefert. Eine hohe Deployment Frequency ist ein Indikator für kleine Batch-Größen, automatisierte Pipelines und Vertrauen in den Release-Prozess.
EliteMehrmals pro TagHighEinmal pro Woche bis einmal pro MonatMediumEinmal pro Monat bis alle 6 MonateLowSeltener als alle 6 MonateSo messen SieZählen Sie die Anzahl erfolgreicher Deployments in die Produktionsumgebung pro Zeiteinheit. Nutzen Sie Deployment-Logs aus Jenkins, GitLab CI, ArgoCD oder Ihrem Release-Management-Tool.
Verbesserungstipps- 01Reduzieren Sie die Batch-Größe: Kleinere, häufigere Releases statt großer Big-Bang-Deployments
- 02Automatisieren Sie den gesamten Deployment-Prozess — kein manueller Schritt darf den Release blockieren
- 03Implementieren Sie Feature Flags, um unfertigen Code sicher zu deployen
- 04Entkoppeln Sie Deployment von Release: Deployen Sie kontinuierlich, aktivieren Sie Features gezielt
- /02Lead Time for Changes · Vorlaufzeit für Änderungen
Was ist Lead Time for Changes?
Lead Time for Changes misst die Zeitspanne vom ersten Code-Commit bis zum produktiven Deployment — die Effizienz der gesamten Delivery-Pipeline.
Wie lange dauert es vom Code-Commit bis zum produktiven Deployment? Die Lead Time for Changes misst die Effizienz Ihrer gesamten Delivery-Pipeline — von der Entwicklung über Tests und Quality Gates bis zum Release.
EliteWeniger als 1 StundeHigh1 Tag bis 1 WocheMedium1 Woche bis 1 MonatLowMehr als 1 MonatSo messen SieMessen Sie die Zeitspanne vom ersten Commit eines Changesets bis zum erfolgreichen Deployment in Produktion. Erfassen Sie die Daten aus Ihrem Git-System und Deployment-Tool.
Verbesserungstipps- 01Identifizieren Sie Wartezeiten mit Value-Stream-Mapping — oft sind 80 % der Lead Time reine Wartezeit
- 02Automatisieren Sie Quality Gates: Code Review, Tests, Security Scans müssen parallel laufen
- 03Eliminieren Sie manuelle Freigabeprozesse — ersetzen Sie sie durch automatisierte Policy Checks
- 04Nutzen Sie Trunk-Based Development statt langlebiger Feature-Branches
- /03Change Failure Rate · Änderungs-Fehlerquote
Wie berechnet man die Change Failure Rate?
Change Failure Rate misst den Anteil der Deployments, die in Produktion einen Fehler verursachen und einen Hotfix, Rollback oder Patch erfordern — die Qualitäts-Metrik der Releases.
Wie viel Prozent der Deployments führen zu einem Fehler, der einen Hotfix, Rollback oder Patch erfordert? Die Change Failure Rate misst die Qualität Ihrer Releases und die Effektivität Ihrer Quality Gates.
Elite0–5 %High6–15 %Medium16–30 %LowMehr als 30 %So messen SieTeilen Sie die Anzahl fehlgeschlagener Deployments (die einen Hotfix, Rollback oder Patch erfordern) durch die Gesamtzahl der Deployments. Erfassen Sie Incidents aus Ihrem Incident-Management-System.
Verbesserungstipps- 01Investieren Sie in automatisierte Tests: Unit, Integration, E2E — je mehr, desto besser
- 02Implementieren Sie Canary Deployments oder Blue-Green Deployments für risikoarme Releases
- 03Führen Sie Post-Mortems nach jedem Fehler durch — ohne Schuldzuweisungen (Blameless)
- 04Stärken Sie Code Reviews: Vier-Augen-Prinzip mit klaren Review-Checklisten
- /04Mean Time to Recovery (MTTR) · Mittlere Wiederherstellungszeit
Was ist Mean Time to Recovery (MTTR)?
Mean Time to Recovery misst, wie schnell ein Team einen Service nach einem Ausfall in der Produktion wiederherstellt — die Resilienz-Metrik der Systeme.
Wie schnell kann Ihr Team einen Service nach einem Ausfall oder Fehler wiederherstellen? MTTR misst die Resilienz Ihrer Systeme und die Reaktionsfähigkeit Ihres Teams — von der Erkennung des Problems bis zur Lösung.
EliteWeniger als 1 StundeHighWeniger als 1 TagMedium1 Tag bis 1 WocheLowMehr als 1 WocheSo messen SieMessen Sie die Zeitspanne vom Erkennen eines Produktionsproblems bis zur vollständigen Wiederherstellung. Nutzen Sie Daten aus Monitoring-Tools (Grafana, Datadog, PagerDuty) und Incident-Tickets.
Verbesserungstipps- 01Investieren Sie in Observability: Logging, Monitoring und Alerting müssen lückenlos sein
- 02Implementieren Sie automatisierte Rollback-Mechanismen — ein Klick, nicht ein Kriegsrat
- 03Führen Sie regelmäßige Incident-Response-Übungen durch (Game Days)
- 04Reduzieren Sie die Mean Time to Detect (MTTD) mit proaktivem Monitoring und Anomalie-Erkennung
Was sind die
5 DORA-Metriken?
Die klassischen DORA-Metriken sind vier. 2021 hat das DORA-Team eine fünfte ergänzt: Reliability — die Frage, ob ein System die Zusagen einhält, die dem Nutzer gegeben wurden. Sie ist die einzige der fünf, für die es keinen allgemeinen Benchmark-Wert gibt: Gemessen wird gegen die eigenen Service Level Objectives, nicht gegen einen Branchendurchschnitt.
Genau deshalb wird sie in vielen Dashboards weggelassen — sie lässt sich nicht aus Git- und CI/CD-Logs allein ableiten, sondern verlangt eine vorher getroffene Aussage darüber, was „verfügbar genug" überhaupt bedeutet. Für industrielle Umgebungen ist das die interessanteste der fünf: Eine Anlage, die im Wartungsfenster planbar steht, ist zuverlässig — eine, die zwischen zwei Schichten unangekündigt ausfällt, nicht. Diesen Unterschied bilden die vier Delivery-Kennzahlen für sich genommen nicht ab.
Praktisch heißt das: Beginnen Sie mit den vier Delivery-Metriken, und nehmen Sie Reliability dazu, sobald belastbare Service Level Objectives existieren. Umgekehrt funktioniert es selten — ohne definiertes Ziel wird die fünfte Metrik zur Meinungsfrage.
Ein häufiger Irrtum: Schnellere Deployments führen zu mehr Fehlern. Die DORA-Forschung zeigt das Gegenteil — Elite-Performer sind gleichzeitig schneller und stabiler. Kleine, häufige Releases reduzieren das Risiko pro Release und ermöglichen schnellere Recovery. Wie sich die Lead Time for Changes im Detail definiert und abgrenzt, erklärt unser Glossar — ebenso die Change Failure Rate mit Formel und DORA-Benchmarks.
Die meisten Daten
liegen bereits
in Ihren Systemen.
Sie müssen sie nur zusammenführen. Drei Kategorien von Quellen und Tools. Eine saubere CI/CD-Pipeline als Datenbasis für die Messung liefert die meisten Events bereits automatisch — und die Automatisierung der Metrik-Erhebung macht aus einer einmaligen Momentaufnahme einen verlässlichen Trend. Wer die Pipeline-Plattform nicht selbst betreiben will, lagert den Betrieb als DevOps as a Service (Managed CI/CD) aus — inklusive der Datenstrecke für die DORA-Messung.
Datenquellen
- —CI/CD-Systeme: Jenkins, GitLab CI, GitHub Actions, Azure DevOps
- —Versionskontrolle: Git-Commit-Historie und Merge-Zeitpunkte
- —Deployment-Logs: ArgoCD, Spinnaker, Octopus Deploy
- —Incident-Management: PagerDuty, Opsgenie, ServiceNow
- —Monitoring: Grafana, Datadog, Prometheus, New Relic
Spezialisierte DORA-Tools
- —Sleuth — automatische DORA-Erfassung aus Git und CI/CD
- —LinearB — Developer Productivity und DORA Metrics
- —Faros AI — Engineering Intelligence Platform
- —Jellyfish — Engineering Management Platform
- —Eigene Dashboards mit Grafana + Prometheus
Open-Source-Optionen
- —Four Keys Project (Google) — Referenzimplementierung auf GitHub
- —DevLake (Apache) — Open-Source Engineering Analytics
- —Backstage (Spotify) — Developer Portal mit Metrics-Plugins
- —Custom Scripts mit Git-Log-Analyse und API-Integration
DORA-Dashboard aufbauen —
fünf Schritte.
- /01
Datenquellen identifizieren
Welche CI/CD-Tools, Git-Hosting und Incident-Systeme nutzen Sie?
- /02
Events definieren
Was zählt als „Deployment"? Was als „Change Failure"? Klare Definitionen sind entscheidend.
- /03
Daten zusammenführen
Webhooks, API-Calls oder Batch-Jobs — bringen Sie alle Events in ein zentrales System.
- /04
Dashboard visualisieren
Grafana, Datadog oder ein Custom-Dashboard — zeigen Sie Trends, nicht nur Momentaufnahmen.
- /05
Team-Review etablieren
Monatliches Review der DORA Metrics im Team. Trends besprechen, Maßnahmen ableiten.
Wo steht die
Branche?
Der jährliche State of DevOps Report kategorisiert Teams in vier Performance-Stufen.
Gleiche Metriken.
Andere
Benchmarks.
Die Standard-DORA-Benchmarks stammen aus der IT-Welt — Webapplikationen, Cloud-Services, SaaS. Für industrielle Umgebungen gelten andere Maßstäbe. Die Metriken bleiben dieselben, aber die Interpretation ändert sich.
In der OT-Welt sind ungeplante Deployments ein Sicherheitsrisiko. Elite-Performance bedeutet hier: automatisierte, reproduzierbare Releases im geplanten Wartungsfenster — nicht 50 Deployments pro Tag.
Industrielle Systeme erfordern oft Hardware-in-the-Loop-Tests, Simulationen und Validierungsschritte, die Zeit brauchen. Der Fokus liegt auf der Automatisierung dieser Schritte, nicht auf deren Elimination.
Bei SPS-gesteuerten Anlagen kann ein fehlerhaftes Deployment Menschen gefährden. Die Change Failure Rate muss hier durch umfassende Simulation, Quality Gates und IEC 62443-konforme Prozesse minimiert werden. Und spätestens wenn der Auditor fragt, welcher Softwarestand zum Zeitpunkt eines Vorfalls auf der Linie lief, muss die Antwort aus der Pipeline kommen — nicht aus der Erinnerung des Instandhalters.
Ein Rollback auf einer SPS-Anlage ist komplexer als ein Container-Neustart. Automatisierte Rollback-Mechanismen und getestete Recovery-Prozeduren sind der Schlüssel — nicht die reine Geschwindigkeit.
In der OT-Welt geht es nicht darum, so schnell wie möglich zu deployen. Es geht darum, den Weg vom Commit zum Deployment vollständig zu automatisieren — mit allen notwendigen Quality Gates, Simulationen und Validierungsschritten. Mehr dazu in unserem Industrial DevOps Angebot.
Von der Messung
zur
Verbesserung.
Metriken erheben ist der erste Schritt. Der eigentliche Wert entsteht durch die systematische Verbesserung. Dieser 6-Schritte-Plan hat sich in über 75 Projekten bewährt.
- /01
Baseline etablieren
Erheben Sie die vier DORA Metrics für mindestens ein Team über 4 Wochen. Nutzen Sie vorhandene Daten aus Git, CI/CD und Incident-Management. Perfekte Datenqualität ist nicht nötig — eine grobe Baseline reicht.
- /02
Engpässe identifizieren
Analysieren Sie, welche Metrik am weitesten vom Zielwert entfernt ist. Führen Sie ein Value-Stream-Mapping durch, um die Ursachen zu finden. Oft sind es Wartezeiten auf Freigaben, fehlende Testautomatisierung oder manuelle Deployment-Schritte. Ein typischer Befund: Ein Feature, das zwei Tage Entwicklung gekostet hat, liegt drei Wochen fertig getestet im Freigabe-Stau — bezahlte Arbeit, die in dieser Zeit niemandem Wert liefert.
- /03
Einen Hebel wählen
Fokussieren Sie sich auf eine Metrik und einen konkreten Verbesserungsbereich. Beispiel: Wenn die Lead Time hoch ist, automatisieren Sie zuerst die Quality Gates. Nicht alles auf einmal ändern.
- /04
Maßnahme umsetzen (2–4 Wochen)
Setzen Sie die gewählte Verbesserung in einem kurzen Sprint um. Kleine, messbare Änderungen sind besser als große Transformationsprojekte. Dokumentieren Sie, was Sie verändert haben.
- /05
Messen und vergleichen
Erheben Sie die DORA Metrics erneut und vergleichen Sie mit der Baseline. Hat sich die Zielmetrik verbessert? Haben sich andere Metriken verschlechtert (Trade-offs)? Teilen Sie die Ergebnisse im Team.
- /06
Kontinuierlich iterieren
Wiederholen Sie den Zyklus: nächster Engpass, nächste Maßnahme, nächste Messung. Etablieren Sie ein monatliches oder quartalmäßiges DORA Review im Team. Der Trend ist wichtiger als der absolute Wert.
Was kommt
nach DORA?
DORA misst die Software-Delivery-Performance über vier Metriken. Das SPACE-Framework (2021) erweitert den Blick auf fünf Dimensionen der Developer Productivity — inklusive Zufriedenheit und Zusammenarbeit. DX Core 4 (2024) vereint DORA, SPACE und DevEx zu vier Dimensionen: Speed, Effectiveness, Quality und Business Impact. DORA bleibt der beste Einstieg — SPACE und DX Core 4 ergänzen es, ersetzen es aber nicht.
Für Industrial DevOps zählt nicht das Framework, sondern die Anschlussfähigkeit an Ihre Toolchain. Wo Sie heute stehen, zeigt der DevOps-Reifegrad-Check — als Ergänzung zur reinen DORA-Baseline.
Messen.
Verstehen.
Verbessern.
DORA Metrics sind kein Selbstzweck. Sie sind ein Werkzeug, um datengetriebene Entscheidungen über Ihre DevOps-Strategie zu treffen. Die vier Metriken decken Geschwindigkeit und Stabilität gleichermaßen ab — und zeigen, dass beides kein Widerspruch ist.
Starten Sie einfach: Erheben Sie die vier Metriken für ein Team, vergleichen Sie mit den Benchmarks und identifizieren Sie Ihren größten Hebel. Das dauert einen halben Tag — und liefert Erkenntnisse, die Ihre gesamte DevOps-Strategie auf eine solide Basis stellen. Der Moment, in dem das erste Dashboard den Freigabe-Stau schwarz auf weiß zeigt, verändert die Diskussion im Team mehr als jede Grundsatzpräsentation. Wenn Sie dabei Unterstützung möchten: Unsere DevOps Beratung startet genau hier — mit Reifegradanalyse und DORA-Baseline.
Für industrielle Umgebungen gelten besondere Maßstäbe — aber die Metriken funktionieren auch hier. Der Schlüssel ist nicht blinde Geschwindigkeit, sondern automatisierte, reproduzierbare und sichere Delivery-Prozesse. Wo wir dabei konkret unterstützen, zeigt unsere Übersicht aller DevOps-Leistungen.
Der Trend ist wichtiger als der absolute Wert.
Was Kunden
wirklich fragen.
- Q.01
- Was sind DORA-Metriken (DORA Metrics)?
- DORA-Metriken sind vier Kennzahlen zur Messung der Software-Delivery-Performance: Deployment Frequency, Lead Time for Changes, Change Failure Rate und Mean Time to Recovery. Sie stammen aus dem Forschungsprogramm DORA (DevOps Research and Assessment) und korrelieren nachweislich mit dem Geschäftserfolg von Softwareorganisationen. Im Deutschen finden Sie sie auch als DORA-Kennzahlen oder DORA-Metriken geschrieben — gemeint sind immer dieselben vier Werte.
- Q.02
- Was sind die 5 DORA-Metriken?
- Die klassischen DORA-Metriken sind vier. 2021 hat das DORA-Team eine fünfte ergänzt: Reliability — also die Frage, ob ein System die Zusagen einhält, die dem Nutzer gegeben wurden. Sie ist die einzige der fünf, für die es keinen allgemeinen Benchmark gibt, denn gemessen wird gegen die eigenen Service Level Objectives. Wer von „den 5 DORA-Metriken" spricht, meint die vier Delivery-Kennzahlen plus Reliability.
- Q.03
- Wie viele DORA-Metriken gibt es?
- Es gibt vier klassische DORA-Metriken: Deployment Frequency, Lead Time for Changes, Change Failure Rate und Mean Time to Recovery. Seit 2021 ergänzt Reliability das Set als fünfte Metrik. In der Praxis starten die meisten Teams mit den vier Delivery-Kennzahlen — sie lassen sich direkt aus CI/CD-, Git- und Incident-Daten erheben, während Reliability definierte Service Level Objectives voraussetzt.
- Q.04
- Wofür stehen die DORA-Metriken?
- DORA steht für DevOps Research and Assessment — das Forschungsprogramm, das die Kennzahlen seit 2014 erhebt und seit 2018 zu Google Cloud gehört. Nicht zu verwechseln mit dem Digital Operational Resilience Act, der ebenfalls als DORA abgekürzt wird: Das ist eine EU-Verordnung für den Finanzsektor und hat mit DevOps-Messung nichts zu tun. Beide Begriffe tauchen in denselben Suchergebnissen auf — wer nach Kennzahlen sucht, ist beim Forschungsprogramm richtig.
- Q.05
- Was sind die DORA-Metriken in agilen Projekten?
- In agilen Projekten ersetzen die DORA-Metriken nicht die Sprint-Planung, sondern die Erfolgsmessung. Velocity beantwortet, wie viel ein Team in einem Sprint geschafft hat; die DORA-Metriken beantworten, wie viel davon beim Nutzer angekommen ist und wie stabil es dort läuft. Erhoben werden sie pro Team und pro Delivery-Pipeline, nicht pro Sprint — die Aussage liegt im Trend über mehrere Sprints hinweg.
- Q.06
- Wie misst man DORA-Metriken?
- DORA-Metriken werden aus CI/CD-Pipeline-Daten, Git-Commits, Deployment-Logs und Incident-Management-Systemen erhoben. Tools wie Sleuth, LinearB, Faros AI, das Open-Source-Projekt Four Keys von Google oder eigene Dashboards mit Grafana können die Erfassung automatisieren. Die meisten Daten liegen bereits in Ihren bestehenden Systemen.
- Q.07
- Was ist ein guter Wert für die DORA-Metriken?
- Elite-Teams deployen laut State of DevOps Report 2024 mehrmals täglich, halten Lead Time for Changes und Mean Time to Recovery unter einer Stunde und liegen bei der Change Failure Rate zwischen 0 und 5 Prozent. High-Performer deployen wöchentlich bis monatlich bei einer Lead Time von einem Tag bis einer Woche. Aussagekräftiger als der einmalige Benchmark-Vergleich ist der eigene Trend über mehrere Monate.
- Q.08
- Was ist eine gute Deployment Frequency?
- Laut DORA-Benchmark deployen Elite-Performer mehrmals täglich, High-Performer wöchentlich bis monatlich. Für Industrial DevOps gelten andere Maßstäbe — hier ist ein kontrollierter Release-Rhythmus mit Quality Gates entscheidend, nicht die bloße Häufigkeit.
- Q.09
- Warum sind DORA-Metriken besser als Velocity oder Story Points?
- DORA-Metriken messen Outcomes (tatsächliche Delivery-Leistung), während Velocity und Story Points nur Output messen. DORA korreliert nachweislich mit Geschäftserfolg und organisatorischer Performance, während Velocity leicht manipulierbar ist und keinen Zusammenhang mit dem Geschäftsergebnis hat.
- Q.10
- Wie oft sollte man DORA-Metriken erheben?
- Idealerweise kontinuierlich und automatisiert über ein Dashboard. Mindestens aber sollten Sie die Metriken monatlich erheben und im Team besprechen. Entscheidend ist der Trend über die Zeit, nicht eine einzelne Momentaufnahme.
- Q.11
- Gelten DORA-Metriken auch für industrielle Umgebungen?
- Ja, die vier Metriken sind universell anwendbar. Allerdings müssen die Benchmarks an den industriellen Kontext angepasst werden. Eine SPS-Anlage braucht keine 50 Deployments pro Tag — aber automatisierte, reproduzierbare Releases im geplanten Wartungsfenster sind auch hier Elite-Performance.
- Q.12
- Was ist der Unterschied zwischen Lead Time und Cycle Time?
- Lead Time for Changes (DORA) misst die Zeit vom ersten Commit bis zum produktiven Deployment. Cycle Time misst die Zeit von der ersten Arbeit an einem Item bis zu dessen Fertigstellung. DORA fokussiert bewusst auf die Pipeline-Effizienz, nicht auf die gesamte Entwicklungszeit.
- Q.13
- Kann man DORA-Metriken auch ohne spezielle Tools messen?
- Ja. Für den Start genügen Git-Logs, CI/CD-Logs und eine einfache Tabellenkalkulation. Zählen Sie Deployments, messen Sie die Zeit vom Commit zum Deployment, notieren Sie fehlgeschlagene Releases und Recovery-Zeiten. Automatisierung kommt später.
- Q.14
- Was kommt nach DORA — SPACE und DX Core 4?
- DORA misst die Software-Delivery-Performance über vier Metriken. Das SPACE-Framework (2021) erweitert den Blick auf fünf Dimensionen der Developer Productivity — inklusive Zufriedenheit und Zusammenarbeit. DX Core 4 (2024) vereint DORA, SPACE und DevEx zu vier Dimensionen: Speed, Effectiveness, Quality und Business Impact. DORA bleibt der beste Einstieg und wird durch SPACE und DX Core 4 ergänzt, nicht ersetzt.
Weitere Antworten rund um DevOps, CI/CD und Industrial DevOps sammeln wir in unseren häufig gestellten Fragen zu DevOps und CI/CD.
Bevor Sie
DORA messen.
3 Minuten.
Unser kostenloser DevOps-Reifegrad-Schnellcheck als erste Orientierung. Personalisierter Report mit Score, Benchmark-Vergleich und Top-3-Handlungsempfehlungen. Ohne Anmeldung, ohne Verpflichtung — und wenn Sie die Ergebnisse besprechen möchten, kostet Sie das Erstgespräch 30 Minuten Ihrer Zeit, sonst nichts.
Wie geht es bei Ihnen mit der DORA-Messung weiter?
Sagen Sie uns mit einem Klick, wie es bei Ihnen weitergeht. Passend dazu bekommen Sie direkt einen konkreten nächsten Schritt — ganz ohne Formular.
Verwandte Artikel
DevOps Value Stream Mapping
Wo die Lead Time wirklich verloren geht — Engpässe in 6 Schritten sichtbar machen.
DevOps-Reifegrad messen & benchmarken
DORA-Metriken, Reifegradmodelle und Value-Stream-Mapping — die wichtigsten Methoden.
DevOps-Kultur aufbauen: CALMS & Coaching
Kultur, Automatisierung, Lean, Messung und Sharing — das CALMS-Framework in der Praxis.
Industrial DevOps: Der komplette Leitfaden
Was ist Industrial DevOps? CI/CD für cyber-physische Systeme und Industrie 4.0.
Erstgespräch.
Kostenlos.
90 Tage zum Ergebnis.
Wir klären gemeinsam, wie Sie in 90 Tagen die ersten messbaren Industrial-DevOps-Erfolge erzielen.
Industrie · Automotive · Finance