DORA-Metriken
Inhaltsverzeichnis: Definition – Überblick – Aussagekraft – Messung und Verbesserung – Anti-Patterns – Fragen aus der Praxis – Hinweise
DORA-Metriken: Software schnell und zuverlässig bereitstellen
Ein Entwicklungsteam veröffentlicht regelmäßig neue Funktionen. Manche Änderungen erreichen die Produktion innerhalb weniger Stunden, andere benötigen mehrere Tage. Gelegentlich führt ein Deployment zu einem Fehler, der schnell behoben wird, manchmal dauert die Wiederherstellung deutlich länger. Doch wie gut funktioniert die Softwarebereitstellung tatsächlich? Und woran lässt sich erkennen, ob sie sich mit der Zeit verbessert?
Genau hier setzen DORA-Metriken an. DORA steht für DevOps Research and Assessment und untersucht, welche Fähigkeiten und Arbeitsweisen erfolgreiche Softwareteams auszeichnen. Daraus sind Kennzahlen entstanden, mit denen sich wichtige Aspekte der Softwarebereitstellung messen lassen.
Die DORA-Metriken betrachten dabei vor allem zwei Fragen: Wie schnell gelangen Änderungen in die Produktion? Und wie stabil und zuverlässig funktioniert dieser Prozess?
Sie helfen Teams, Engpässe und Verbesserungspotenziale zu erkennen, Entwicklungen über einen längeren Zeitraum zu beobachten und die Wirkung von Verbesserungen zu prüfen. Dabei geht es nicht darum, einzelne Entwickler oder Teams miteinander zu vergleichen, sondern den eigenen Entwicklungs- und Bereitstellungsprozess besser zu verstehen und gezielt zu verbessern.
Die DORA-Metriken im Überblick
Lange Zeit waren vor allem vier DORA-Metriken bekannt, die häufig auch als „Four Keys“ bezeichnet wurden. DORA hat dieses Modell im Laufe der Jahre weiterentwickelt. Heute umfasst es fünf Metriken, die zwei Bereiche betrachten: den Durchsatz und die Instabilität der Softwarebereitstellung. [1]
Drei Metriken beschreiben den Durchsatz, also wie schnell Änderungen den Weg bis in die Produktion schaffen. Zwei weitere Metriken betrachten die Instabilität und zeigen, wie häufig Probleme entstehen oder ungeplante Nacharbeiten notwendig werden.
| Bereich | DORA-Metrik | Was wird gemessen? |
| Durchsatz | Change Lead Time | Wie lange dauert es vom Commit einer Änderung bis zur erfolgreichen Bereitstellung in Produktion? |
| Durchsatz | Deployment Frequency | Wie häufig werden Änderungen in Produktion bereitgestellt? |
| Durchsatz | Failed Deployment Recovery Time | Wie lange dauert es, nach einem fehlgeschlagenen Deployment den normalen Betrieb wiederherzustellen? |
| Instabilität | Change Fail Rate | Welcher Anteil der Änderungen führt zu Problemen und erfordert eine direkte Korrektur? |
| Instabilität | Deployment Rework Rate | Welcher Anteil der Deployments ist ungeplant und dient dazu, Probleme in Produktion zu beheben? |
Die einzelnen Metriken betrachten unterschiedliche Teile der Softwarebereitstellung. Gemeinsam zeigen sie, wie schnell ein Team Änderungen ausliefern kann und wie zuverlässig dieser Prozess funktioniert.
Was sagen die DORA-Metriken aus und wie werden sie gemessen?
Die DORA-Metriken betrachten zwei Seiten der Softwarebereitstellung: Geschwindigkeit und Stabilität. Change Lead Time und Deployment Frequency zeigen, wie schnell und häufig Änderungen in Produktion gelangen. Change Fail Rate, Deployment Rework Rate und Failed Deployment Recovery Time machen sichtbar, wie zuverlässig dies gelingt und wie ein Team mit Problemen umgeht.
Entscheidend ist das Zusammenspiel der Metriken. Ein einzelner Wert kann Hinweise liefern, sagt aber noch wenig über die Qualität des gesamten Bereitstellungsprozesses aus. Erst mehrere Werte zusammen ermöglichen eine bessere Einordnung:
| Beobachtung | Mögliche Aussage |
| Kurze Change Lead Time und hohe Deployment Frequency | Änderungen können schnell und regelmäßig bereitgestellt werden. |
| Hohe Deployment Frequency und hohe Change Fail Rate | Das Team liefert häufig aus, die Änderungen führen aber vergleichsweise oft zu Problemen. |
| Lange Change Lead Time und niedrige Change Fail Rate | Änderungen sind zwar stabil, benötigen aber möglicherweise unnötig lange bis zur Produktion. |
| Niedrige Change Fail Rate und kurze Recovery Time | Probleme treten selten auf und können zudem schnell behoben werden. |
| Hohe Deployment Rework Rate | Ein größerer Teil der Deployments entsteht ungeplant durch Fehler und notwendige Nacharbeiten. |
| Verbesserte Geschwindigkeit bei gleichbleibender oder höherer Stabilität | Der Bereitstellungsprozess entwickelt sich insgesamt positiv. |
Gemessen werden die DORA-Metriken anhand von Ereignissen, die im Entwicklungs- und Bereitstellungsprozess ohnehin entstehen. Dazu gehören beispielsweise Commits, Deployments, fehlgeschlagene Änderungen und deren Behebung. Als Datenquellen können unter anderem Versionsverwaltung, CI/CD-Systeme sowie Systeme für Monitoring und Incident Management dienen.
Besonders wertvoll ist nicht ein einzelner Messwert, sondern seine Entwicklung über die Zeit. Teams können bspw. prüfen, ob Änderungen nach einer Verbesserung schneller in Produktion gelangen, ohne dass dadurch mehr Fehler entstehen. DORA-Metriken dienen somit weniger als Punktestand, sondern als Werkzeug, um Entwicklungen zu erkennen und den eigenen Bereitstellungsprozess gezielt zu verbessern.
Von der Messung zur Verbesserung
DORA-Metriken entfalten ihren Nutzen erst dann, wenn aus Messwerten konkrete Verbesserungen entstehen. Es reicht also nicht, Kennzahlen regelmäßig zu erfassen und in einem Dashboard anzuzeigen. Entscheidend ist, welche Fragen ein Team daraus ableitet.
Ein sinnvoller Ablauf kann so aussehen:
Ausgangssituation bestimmen
Zunächst werden die aktuellen Werte über einen ausreichend langen Zeitraum betrachtet. Einzelne Ausreißer sind weniger wichtig als wiederkehrende Muster und erkennbare Trends.
Auffälligkeiten erkennen
Welche Metrik verändert sich deutlich? Wo entstehen lange Wartezeiten? Wo steigt die Zahl fehlgeschlagener Änderungen? Wichtig ist, nicht vorschnell eine Ursache anzunehmen.
Ursachen untersuchen
Eine lange Change Lead Time kann zum Beispiel durch große Arbeitspakete, lange Code Reviews, manuelle Freigaben oder instabile Tests entstehen. Die Metrik zeigt das Problemfeld, nicht automatisch die Ursache.
Eine gezielte Verbesserung ausprobieren
Statt viele Dinge gleichzeitig zu verändern, ist es meist hilfreicher, eine konkrete Maßnahme umzusetzen. Das kann beispielsweise die Automatisierung eines Freigabeschritts, kleinere Changes oder eine stabilere Testpipeline sein.
Wirkung überprüfen
Anschließend wird beobachtet, ob sich die erwartete Metrik verbessert und ob andere Werte stabil bleiben. Verkürzt sich zum Beispiel die Change Lead Time, ohne dass die Change Fail Rate steigt, spricht das für eine positive Veränderung.
Auf diese Weise werden DORA-Metriken zu einem Werkzeug für kontinuierliche Verbesserung. Sie helfen Teams nicht dabei, möglichst gute Zahlen zu produzieren, sondern dabei, Hypothesen zu prüfen und den eigenen Softwarebereitstellungsprozess Schritt für Schritt zu verbessern.
Besonders wichtig ist dabei der Blick auf das Gesamtsystem. Eine Maßnahme gilt nicht schon dann als erfolgreich, wenn sich eine einzelne Kennzahl verbessert. Erst wenn Geschwindigkeit, Stabilität und notwendige Nacharbeit gemeinsam betrachtet werden, lässt sich beurteilen, ob sich der Prozess tatsächlich verbessert hat.
Anti-Patterns und häufige Fehler
DORA-Metriken können sehr hilfreich sein. Falsch eingesetzt erzeugen sie jedoch schnell falsche Anreize oder führen zu irreführenden Schlussfolgerungen:
DORA-Metriken als Leistungsbewertung verwenden
Die Metriken eignen sich nicht dazu, einzelne Entwickler oder Teams zu bewerten. Werden Kennzahlen an persönliche Ziele, Boni oder Rankings gekoppelt, entsteht schnell ein Anreiz, die Zahl statt den Prozess zu optimieren.
Eine hohe Deployment Frequency lässt sich bspw. steigern, indem sehr kleine und fachlich kaum relevante Änderungen häufiger ausgeliefert werden. Die Kennzahl verbessert sich, ohne dass dadurch automatisch mehr Wert entsteht.
Teams anhand ihrer Werte vergleichen
Vergleiche zwischen Teams wirken attraktiv, sind aber oft wenig aussagekräftig. Unterschiedliche Produkte, technische Plattformen, Risiken oder regulatorische Anforderungen beeinflussen die Metriken stark. Sinnvoller ist es, ein Team oder einen Service mit seiner eigenen Entwicklung zu vergleichen. So wird sichtbar, ob Veränderungen tatsächlich zu einer Verbesserung geführt haben.
Einzelne Metriken isoliert optimieren
Wer nur eine Kennzahl verbessert, kann an anderer Stelle neue Probleme schaffen. Eine kürzere Change Lead Time ist beispielsweise kein Erfolg, wenn gleichzeitig die Change Fail Rate deutlich steigt.
Die Metriken sollten deshalb immer gemeinsam betrachtet werden. Entscheidend ist nicht der Bestwert einer einzelnen Kennzahl, sondern ein ausgewogenes Verhältnis aus Geschwindigkeit, Stabilität und möglichst wenig ungeplanter Nacharbeit.
Benchmarks zu starren Zielwerten machen
Benchmarks können Orientierung geben, sollten aber nicht automatisch zu verbindlichen Zielwerten werden. Ein Wert, der für ein anderes Team sinnvoll ist, muss nicht zum eigenen Produkt oder System passen. Problematisch wird es vor allem dann, wenn nur noch auf das Erreichen eines Zielwerts hingearbeitet wird. Dann steigt die Gefahr, dass Kennzahlen optimiert werden, ohne dass sich der Softwarebereitstellungsprozess tatsächlich verbessert.
Zu früh auf einzelne Messwerte reagieren
Ein einzelner schlechter Wert kann durch einen Ausreißer entstehen. Ein schwieriges Release, ein größerer Incident oder eine ungewöhnliche Änderung kann eine Metrik kurzfristig deutlich verschlechtern. Aussagekräftiger sind wiederkehrende Muster und Entwicklungen über einen längeren Zeitraum. Teams sollten deshalb Trends untersuchen, statt jede kurzfristige Schwankung sofort als Problem zu behandeln.
Metriken sammeln, ohne etwas daraus abzuleiten
Ein Dashboard allein verbessert keinen Prozess. Wenn Kennzahlen regelmäßig erfasst, aber weder diskutiert noch mit konkreten Maßnahmen verbunden werden, entsteht vor allem zusätzlicher Messaufwand.
DORA-Metriken sind dann besonders wertvoll, wenn sie Fragen auslösen, Hypothesen unterstützen und Veränderungen überprüfbar machen. Ihr Zweck liegt nicht im Reporting, sondern in der Verbesserung des Softwarebereitstellungsprozesses.
Fragen aus der Praxis
Hier finden Sie einige Fragen und Antworten aus der Praxis:
Bedeutet eine hohe Deployment Frequency automatisch, dass ein Team gut arbeitet?
Eine hohe Deployment Frequency ist kein Beleg für gute Arbeit, denn sie zeigt zunächst nur, wie häufig Änderungen produktiv bereitgestellt werden können. Sie sagt weder, ob diese Änderungen für Anwender nützlich sind, noch ob damit die richtigen Funktionen entwickelt werden.
Ein Team kann mehrmals täglich deployen und trotzdem am Bedarf seiner Nutzer vorbeiarbeiten. Umgekehrt kann ein Team wertvolle Software entwickeln, obwohl seine technische Bereitstellung unnötig langsam ist. DORA-Metriken messen daher vor allem die Leistungsfähigkeit der Softwarebereitstellung, nicht den geschäftlichen Erfolg eines Produkts. Für ein vollständigeres Bild sollten sie beispielsweise mit Produkt-, Nutzungs- oder Zuverlässigkeitskennzahlen kombiniert werden.
Kann eine niedrige Change Fail Rate täuschen?
Eine niedrige Change Fail Rate kann täuschen, wenn sie ohne den Kontext anderer Metriken betrachtet wird. Angenommen, Team A führt 100 kleine Deployments durch, von denen fünf Probleme verursachen. Team B veröffentlicht nur vier große Änderungen, von denen keine fehlschlägt. Die Change Fail Rate von Team B sieht besser aus. Daraus folgt aber nicht automatisch, dass Team B den besseren Bereitstellungsprozess besitzt.
Seltene und große Änderungen können ein höheres Risiko enthalten, obwohl dieses Risiko in der Change Fail Rate zunächst nicht sichtbar wird. Außerdem sagt die Kennzahl nichts darüber aus, wie schwer ein Fehler ist. Eine kleine fehlerhafte Darstellung und ein mehrstündiger Ausfall können beide als fehlgeschlagene Änderung zählen.
Die Change Fail Rate sollte daher nicht mit der Zuverlässigkeit eines Systems gleichgesetzt werden. Für diese sind zusätzliche Informationen wie Ausfallzeiten, Service Level Objectives oder die Auswirkungen auf Anwender wichtig.
Warum können Geschwindigkeit und Stabilität gleichzeitig besser werden?
Geschwindigkeit und Stabilität können sich gleichzeitig verbessern, weil häufige und kleine Änderungen oft leichter beherrschbar sind als seltene und große Releases. Kleine Änderungen lassen sich leichter testen, überprüfen und bei Problemen zurücknehmen. Gleichzeitig erhalten Teams schneller Feedback und können Fehler früher erkennen. Häufiges Ausliefern kann somit gerade dazu beitragen, das Risiko einzelner Änderungen zu reduzieren.
Das Ziel lautet deshalb nicht „Geschwindigkeit statt Stabilität“, sondern einen Bereitstellungsprozess zu schaffen, der beides ermöglicht.
Was bedeutet es, wenn sich die DORA-Metriken unterschiedlich entwickeln?
Unterschiedliche Entwicklungen bei den DORA-Metriken sind besonders aufschlussreich, weil sie auf mögliche Zielkonflikte oder Schwachstellen hinweisen können. Verbessern sich alle Werte gleichzeitig, ist die Interpretation relativ einfach. Entwickeln sie sich in unterschiedliche Richtungen, lohnt sich ein genauerer Blick.
Eine kürzere Change Lead Time bei gleichzeitig steigender Change Fail Rate könnte beispielsweise bedeuten, dass Änderungen schneller ausgeliefert werden, dabei aber wichtige Prüfungen zu kurz kommen. Eine niedrige Change Fail Rate bei sehr langer Change Lead Time könnte dagegen auf lange Freigaben, Warteschlangen oder aufwendige Testprozesse hinweisen.
Solche Kombinationen liefern noch keine Ursache, sie zeigen aber, wo es sich lohnt nachzufragen. Genau darin liegt ein großer Nutzen der DORA-Metriken.
Warum sollte man DORA-Metriken nicht einfach für das ganze Unternehmen mitteln?
Es ist keine gute Idee, DORA-Metriken zu mitteln, da Durchschnittswerte wichtige Unterschiede verdecken können. Eine moderne Webanwendung mit mehreren Deployments pro Tag hat andere Voraussetzungen als ein Altsystem, das nur wenige Male im Jahr geändert wird.
Wer beide Werte zu einer unternehmensweiten Kennzahl zusammenfasst, erhält möglicherweise eine präzise Zahl, aber wenig hilfreiche Information. Ein sehr leistungsfähiger Service kann die Probleme eines anderen Services rechnerisch ausgleichen. Es lohnt sich daher, die Metriken auf Ebene einer Anwendung oder eines Services zu betrachten. Vergleiche sind vor allem dann hilfreich, wenn Kontext und technische Rahmenbedingungen ähnlich sind.
Was sind gute DORA-Werte?
Gute DORA-Werte lassen sich nicht sinnvoll auf eine einzige allgemeingültige Zahl reduzieren. Benchmarks können zeigen, wie die eigenen Werte im Vergleich zu anderen Teams oder Anwendungen einzuordnen sind. Sie sollten jedoch nicht automatisch zu Zielwerten werden.
Ein Benchmark beantwortet eher die Frage „Wo stehen wir ungefähr?“ als die Frage „Was sollten wir als Nächstes verbessern?“. Wird bspw. „mehrmals täglich deployen“ zum verbindlichen Ziel erklärt, kann die Kennzahl optimiert werden, ohne dass daraus ein Nutzen entsteht.
Hilfreicher ist es, die eigenen Werte als Ausgangspunkt zu verwenden: Wo verlieren Änderungen besonders viel Zeit? Wo entsteht unerwartete Nacharbeit? Welche Verbesserung wollen wir ausprobieren und verändert sie die entsprechenden Metriken? Damit werden DORA-Metriken vom Leistungsvergleich zum Werkzeug für kontinuierliche Verbesserung.
Können DORA-Metriken die Ursache eines Problems zeigen?
DORA-Metriken zeigen in der Regel nicht die Ursache eines Problems, sondern machen dessen Auswirkungen sichtbar. Sie können bspw. zeigen, dass Änderungen lange benötigen oder häufig zu Problemen führen. Sie erklären aber nicht automatisch, warum das passiert.
Eine lange Change Lead Time kann viele Ursachen haben: lange Code Reviews, instabile Tests, manuelle Freigaben, fehlende Testumgebungen, große Arbeitspakete oder Abhängigkeiten zu anderen Teams. Die eigentliche Arbeit beginnt daher oft erst nach der Messung. Teams können den betroffenen Prozess genauer untersuchen und anschließend prüfen, ob eine Veränderung die DORA-Metriken verbessert. Die Kennzahlen funktionieren damit eher wie Warnleuchten als wie eine Fehlerdiagnose.
Warum zählt die Failed Deployment Recovery Time heute zum Durchsatz?
Die Failed Deployment Recovery Time zählt heute zum Durchsatz, weil sie misst, wie schnell ein Team nach einem fehlgeschlagenen Deployment wieder einen funktionierenden Zustand herstellen kann. Auch die Wiederherstellung ist damit Teil der Fähigkeit, Änderungen wirksam durch den Bereitstellungsprozess zu bewegen. [2]
Früher wurde diese Metrik eher der Stabilität zugeordnet. Deshalb findet man in älteren Darstellungen der DORA-Metriken häufig noch eine andere Einteilung. Dass DORA die Zuordnung später verändert hat, zeigt, dass das Modell nicht unverändert geblieben ist, sondern auf Basis neuer Forschung und neuer Erkenntnisse weiterentwickelt wurde.
Das aktuelle DORA-Modell unterscheidet zwischen Software Delivery Throughput und Software Delivery Instability. Zum Durchsatz gehören Change Lead Time, Deployment Frequency und Failed Deployment Recovery Time. Die Instabilität wird über Change Fail Rate und Deployment Rework Rate beschrieben.
Die Logik dahinter ist interessant: Die Change Fail Rate beantwortet die Frage, wie häufig etwas schiefgeht. Die Failed Deployment Recovery Time beantwortet dagegen, wie schnell das Team darauf reagieren kann. Ein Fehler beschreibt also Instabilität, die Geschwindigkeit seiner Behebung hingegen eine Fähigkeit des Delivery-Prozesses.
Impuls zum Diskutieren:
Was ist für gute Software wichtiger: möglichst schnell auszuliefern oder möglichst selten Fehler zu verursachen?
Hinweise:
Wenn Ihnen der Beitrag gefällt oder Sie darüber diskutieren wollen, teilen Sie ihn gerne in Ihrem Netzwerk. Und falls Sie sich für weitere Tipps aus der Praxis interessieren, dann testen Sie unseren beliebten Newsletter mit neuen Beiträgen, Downloads und Empfehlungen.
[1] Überblick über die Entwicklung der DORA-Metriken, von den klassischen vier Kennzahlen bis zum heutigen Modell mit fünf Metriken
[2] Einteilung der fünf DORA-Metriken
Hier finden Sie wissenschaftlichen Grundlagen, Forschungsmodelle und Studien der DORA Research.
Empfehlenswert sind auch die beiden Beiträge Auf der Jagd nach Kennzahlen und Wenn Zusammenarbeit mehr wird als die Summe ihrer Teile.
Hier finden Sie ergänzende Informationen aus unserer Rubrik Wissen kompakt:
Herausforderungen bei der Nutzung von Metriken
Erfolgsfaktoren beim Release Management
Was ist die Developer Velocity?
„Wissen kompakt“ ist unser Glossar für Menschen in Organisationen, die sich mit Softwareentwicklung, Projekt- und Produktmanagement beschäftigen. Für genau diese Menschen und ihre Organisationen entwickeln und modernisieren wir seit 2012 Software. Pragmatisch. ✔️ Persönlich. ✔️ Professionell. ✔️
Lernen Sie t2informatik aus Berlin als Entwicklungspartner kennen.