Inhaltsverzeichnis
Was ist die Deployment Rework Rate?
Die Deployment Rework Rate misst den Anteil aller Deployments, die innerhalb eines kurzen Zeitfensters nach dem ursprünglichen Release ein weiteres Deployment desselben Codeabschnitts erforderlich machen, um Fehler, Regressionen oder unfertige Logik zu beheben. Sie ist damit keine Throughput-Metrik wie Deployment Frequency und keine Stability-Metrik wie Change Failure Rate, sondern eine reine Qualitätsmetrik der Lieferentscheidung: Sie zeigt, wie oft Teams "fertig" sagen, obwohl der Build noch zwei Korrekturschleifen vor sich hat.
Mit der Veröffentlichung im April 2026 durch das Google-DORA-Team unter Nathen Harvey ist die Rework Rate die erste offizielle Erweiterung des kanonischen Vierersets seit dem 2018 erschienenen Buch "Accelerate". Hintergrund ist die Beobachtung, dass die klassischen vier Metriken eine fundamentale Lücke offenlassen: Ein Team kann hochfrequent deployen, niedrige MTTR und niedrige Change Failure Rate ausweisen — und trotzdem chronisch Code in Produktion bringen, der unmittelbar wieder angefasst werden muss. Die Rework Rate macht diese versteckte Instabilität sichtbar.
Die offizielle DORA-Quick-Check-Spezifikation (siehe https://dora.dev/quickcheck/) definiert Rework als jedes Deployment, das innerhalb von 72 Stunden nach einem vorherigen Deployment dieselbe Anwendung, denselben Service oder dasselbe Repository erneut anfasst. Der Schwellwert ist bewusst kurz gewählt: Was nach drei Tagen erneut gepatcht werden muss, war beim ursprünglichen Release nicht produktionsreif. Längere Zeitfenster vermischen normale Iterationszyklen mit echter Korrekturarbeit.
Wichtig: Rework Rate ist ausdrücklich keine Strafmetrik. Hohe Werte deuten auf systemische Schwächen in der Testabdeckung, im Code Review oder in der Spezifikationspraxis hin — nicht auf "schlechte" Einzelpersonen. Genau wie bei den ursprünglichen vier Metriken bleibt die Regel: kein Einsatz in der individuellen Leistungsbewertung, immer Aggregation auf Team- oder Service-Ebene.
Rework Rate beantwortet die Frage, die Change Failure Rate nicht stellt: Wie oft mussten wir denselben Code unmittelbar nach dem Release nochmal anfassen — egal, ob es ein klassischer Incident war oder nur ein "Naja, ist eigentlich noch ein Bug"-Patch?
Warum jetzt? Die KI-Verstärkung der Rework-Spirale
Die zeitliche Nähe der DORA-Erweiterung zur breiten Einführung KI-gestützter Code-Generierung ist kein Zufall. Mehrere Branchenquellen — darunter Gartners 2026er Hype Cycle for Agentic AI und der Thoughtworks Technology Radar v34 (April 2026, siehe https://www.thoughtworks.com/insights/blog/devex/cognitive-debt-defaults) — beobachten, dass KI-Werkzeuge die Vorlauf-Geschwindigkeit erhöhen, aber gleichzeitig die Nacharbeitsquote treiben. Was als Produktivitätsgewinn erscheint, kann sich in der zweiten Sprintwoche in einen versteckten Wartungsaufwand verwandeln.
Der Mechanismus ist nachvollziehbar: KI-Assistenten generieren plausibel aussehenden Code, der lokale Tests besteht, aber stille Annahmen über Schnittstellenverhalten, Zustandsmanagement oder Fehlerfälle trifft, die im Echtbetrieb erst auffallen. Klassische Stability-Metriken (Change Failure Rate, MTTR) erfassen nur den Anteil mit eindeutigem Incident — leise Korrekturen wandern nicht in den Pager. Rework Rate schließt diese Lücke, indem sie auch die "stillen Patches" zählt.
Erste empirische Daten aus dem DORA Quick Check zeigen, dass nur 7,3 % der teilnehmenden Teams eine Rework Rate von unter 2 % erreichen. Der Median liegt bei etwa 11–14 %, in KI-intensiv arbeitenden Teams höher. Der Google-DORA-Report 2025 (siehe https://dora.dev/research/2025/dora-report/) hatte bereits gezeigt, dass KI als Verstärker existierender Praktiken wirkt — Teams mit starker Test- und Reviewdisziplin werden besser, schwache Teams werden schlechter. Rework Rate ist die Metrik, die diese Spreizung explizit macht.
Damit ist die fünfte Metrik für CIOs und Engineering-Direktoren keine technische Detailfrage, sondern eine governance-relevante Steuergröße: Wer KI-gestützte Entwicklung breit ausrollt, ohne die Rework Rate parallel zu beobachten, riskiert eine Produktivitätskennzahl, die nach oben zeigt, während die tatsächliche Liefertreue darunter still bröckelt. Genau diese Diskrepanz war historisch das Muster vor jeder größeren Software-Qualitätskrise.
Wie misst man Rework Rate ohne neues Tooling?
Die gute Nachricht: Rework Rate lässt sich aus Daten ableiten, die nahezu jede CI/CD-Pipeline bereits produziert. Voraussetzung ist lediglich eine konsistente Markierung jedes Deployments mit einem stabilen Service- oder Repository-Identifier und einem Zeitstempel. Aus diesen beiden Feldern wird eine Stundenfunktion gebaut, die für jedes Deployment prüft, ob im 72-Stunden-Fenster davor bereits ein Deployment desselben Identifiers stattgefunden hat.
Konkret: Wenn Service X heute um 10:00 Uhr deployed wird und der letzte Deploy desselben Service vor 28 Stunden lag, gilt das heutige Deployment als Rework. Ist der vorletzte Deploy mehr als 72 Stunden alt, ist es ein regulärer Release. Die Rework Rate eines Zeitraums ist dann der Anteil der Rework-Deployments an allen Deployments im selben Zeitraum.
In der Praxis funktioniert das mit GitHub Actions, GitLab CI, Argo CD, Jenkins, Azure DevOps oder Spinnaker — alle Tools schreiben Deployment-Events in Logs oder eine Datenbank. Bereits ein einfaches SQL-Statement gegen die Deployment-Tabelle, ein Loki-Query oder ein Python-Skript mit Pandas reicht, um eine erste Baseline zu erstellen. Wir empfehlen, parallel die vier klassischen DORA-Metriken zu erfassen, damit die Rework Rate immer im Kontext der Throughput- und Stability-Werte interpretiert wird.
Wichtig ist die Definition von "demselben Code": Pure Konfigurationsänderungen, reine Infrastrukturänderungen oder geplante Hotfix-Schichten (z. B. wöchentliche Sicherheitspatches) sollten nicht als Rework zählen. Markieren Sie diese Deployments in der CI als "infra" oder "scheduled" und schließen Sie sie aus dem Zähler aus, sonst verzerren Sie die Quote nach oben.
Minimale Datenstruktur pro Deployment
Service- oder Repository-Identifier (string, stabil über Renames hinweg). Deployment-Zeitstempel (UTC). Deployment-Typ (feature, hotfix, infra, scheduled). Commit- oder Pull-Request-Referenz für die Nachvollziehbarkeit. Bei Microservice-Architekturen empfiehlt sich zusätzlich ein optionales "affected_modules"-Feld, damit Rework auch auf Modulebene messbar wird.
Aus diesen Feldern lässt sich die Rework Rate sowohl pro Service als auch aggregiert pro Team oder Domäne ableiten. Erfahrungsgemäß sind aggregierte Werte für Management-Reports geeignet, Service-Werte für Engineering-Retros.
Benchmarks: Wo stehen Sie wirklich?
Auf Basis der ersten DORA-Quick-Check-Daten (siehe https://dora.dev/quickcheck/) lassen sich vorläufige Performance-Cluster ableiten. Elite-Teams erreichen eine Rework Rate von unter 2 % — also weniger als eines von 50 Deployments ist eine Nacharbeit. High-Performer liegen bei 2–5 %, Medium bei 5–15 %, Low über 15 %. Diese Schwellwerte werden voraussichtlich nach 12 Monaten realer Daten kalibriert; bis dahin sind sie Richtwerte mit klarer Bandbreite.
Auffällig ist die starke Korrelation mit zwei anderen Praktiken: Teams mit Trunk-Based Development und automatisierter Pre-Merge-Testabdeckung über 70 % erreichen typischerweise unter 4 %. Teams mit Feature-Branches über fünf Tage Lebensdauer und manuellen QA-Stages landen meist im zweistelligen Bereich. Die fünfte Metrik bestätigt damit empirisch, was die bisherige DORA-Forschung bereits über Testautomatisierung und kleine Batch-Größen gesagt hatte.
Für deutsche Mittelstandsunternehmen mit klassischer monatlicher Release-Kadenz ist die Rework Rate paradoxerweise oft niedriger als bei agilen Konkurrenten — schlicht, weil weniger absolute Deployments stattfinden. In diesen Fällen ist die Rework Rate kein zuverlässiger Indikator allein, sondern muss zusammen mit Deployment Frequency interpretiert werden. Ein Team mit zwei Releases pro Quartal und 0 % Rework lebt nicht im Elite-Status, sondern in einer Welt ohne ausreichend Releases, um die Metrik aussagekräftig zu machen.
| Tier | Rework Rate | Typische Begleitpraktiken |
|---|---|---|
| Elite | < 2 % | Trunk-Based Dev, > 70 % Pre-Merge-Coverage, Feature Flags |
| High | 2–5 % | Tägliche Releases, vollautomatisierte Pipeline |
| Medium | 5–15 % | Wöchentliche Releases, manuelle QA-Schichten |
| Low | > 15 % | Monatliche Releases, hoher manueller Review-Anteil |
KI-spezifische Fallen und Gegenmittel
Wenn Sie KI-Coding-Assistenten breit einsetzen, gibt es drei wiederkehrende Muster, die Rework Rate hochtreiben. Erstens: optimistische Edge-Case-Behandlung — KI generiert defensive Wrapper, die sich in Tests gut anfühlen, aber im Produktivlast-Profil dramatisch andere Pfade nehmen. Gegenmittel: Property-Based Testing oder Fuzzing in der CI verpflichtend für KI-touched Files. Zweitens: stille Schnittstellen-Annahmen — der Assistent rät bei nicht eindeutiger API-Doku. Gegenmittel: erzwungene Spec-First-Praxis (siehe unseren Artikel zu Spec-driven Development unter /blog/spec-driven-development-governance).
Drittens: Konfigurations-Drift — KI-Codeänderungen referenzieren oft Feature Flags oder Env-Variablen, die in einer Umgebung existieren, in einer anderen aber nicht. Gegenmittel: Konfigurations-Linter im Pre-Merge-Check, ergänzt um eine "Promotion-Diff"-Stage zwischen Staging und Production. Diese drei Hebel zusammen senken die Rework Rate in unserer Beratungspraxis bei DACH-Mittelständlern typischerweise um 30–50 % innerhalb von 90 Tagen — ohne Reduktion der KI-Nutzung.
Wer noch tiefer ins KI-Code-Qualitätsthema einsteigen will, findet im Alev-B-Artikel zu Cognitive Debt (/blog/cognitive-debt-ki-code) den größeren systemischen Rahmen — Rework Rate ist gewissermaßen der numerische Frühindikator, an dem sich Cognitive Debt zuerst zeigt, bevor er als Wartungslast in den Backlog wandert.
Implementierung in 90 Tagen
Tag 1–14 (Baseline): Sammeln Sie 8 Wochen historischer Deployment-Daten retrospektiv aus Ihren CI-Logs. Berechnen Sie eine Erst-Baseline pro Service und aggregiert pro Team. Verzichten Sie bewusst auf Targets in dieser Phase — Sie wollen erst verstehen, was "normal" für Ihre Architektur und Ihren Release-Rhythmus ist.
Tag 15–45 (Sichtbarkeit): Bauen Sie ein einfaches Dashboard, das die Rework Rate neben den klassischen vier DORA-Metriken anzeigt. Etablieren Sie ein wöchentliches 15-Minuten-Standup-Item: "Welche Deployments waren diese Woche Rework, und welche Grundursache stand dahinter?" Wichtig: blameless, mit Fokus auf systemische Lerneffekte. Die ersten Auffälligkeiten werden meist Test-Coverage-Lücken oder fehlende Spec-Review-Gates sein.
Tag 46–90 (Intervention): Wählen Sie maximal zwei Hebel — zum Beispiel eine erzwungene Pre-Merge-Testabdeckung von 65 % und einen Property-Based-Test für KI-touched Files. Messen Sie nach 30 Tagen den Trend, nicht den Absolutwert. Eine Verringerung um 25 % in 30 Tagen ist ein realistisches und gleichzeitig nicht trivial zu erreichendes Ziel.
Wenn Sie diesen Rhythmus für drei Quartale durchhalten, ist die Wahrscheinlichkeit hoch, dass Sie ohne weitere Spezialwerkzeuge in den High-Performer-Bereich rutschen. Wer den vollen Reifegrad-Check für Engineering-Praktiken automatisiert haben möchte, findet eine passende Vorlage im Alev-B Template-Katalog unter /templates/devops-maturity sowie /templates/dora-metrics.
Die wichtigsten Erkenntnisse
- Die Deployment Rework Rate ist seit April 2026 die offizielle 5. DORA-Metrik und schließt eine bisher unsichtbare Qualitätslücke neben Deployment Frequency, Lead Time, MTTR und Change Failure Rate.
- Sie misst, welcher Anteil aller Deployments innerhalb von 72 Stunden ein weiteres Deployment desselben Codes erfordert — also "stille Patches", die kein klassischer Incident sind.
- KI-Coding-Assistenten erhöhen Vorlaufgeschwindigkeit und Rework parallel; nur die Rework Rate macht diesen Tradeoff zahlenmäßig sichtbar.
- Nur 7,3 % der Teams im DORA Quick Check erreichen Elite-Niveau (< 2 %); der Median liegt im zweistelligen Bereich.
- Die Metrik lässt sich aus bestehenden CI/CD-Logs berechnen — kein neues Tooling, kein Vendor-Lock-in nötig.
- Wer KI-gestützte Entwicklung ausrollt, ohne Rework Rate zu beobachten, riskiert eine Produktivitätsillusion, die sich nach 2–3 Quartalen als Wartungslast manifestiert.
Passende Assessment-Templates
Häufig gestellte Fragen
Nein, beide Metriken messen Unterschiedliches. Change Failure Rate erfasst Deployments, die einen klar erkennbaren Incident oder Rollback ausgelöst haben — also Vorfälle mit hoher organisatorischer Sichtbarkeit. Rework Rate erfasst zusätzlich die leise Korrekturarbeit, die kein Pager-Event auslöst, aber innerhalb von 72 Stunden trotzdem ein weiteres Deployment nötig macht. Elite-Teams beobachten beide Metriken parallel, weil hohe Change Failure Rate auf operative Stabilitätsprobleme deutet, hohe Rework Rate dagegen auf Qualitätsentscheidungen vor dem Release. Wer nur eine der beiden misst, sieht systematisch die Hälfte der Realität.
Die offizielle DORA-Spezifikation begründet das Fenster damit, dass es lang genug ist, um echte Korrekturarbeit von einem regulären Folge-Release zu unterscheiden, und kurz genug, um nicht normale Iterationszyklen einzufangen. In Branchen mit sehr schnellem Release-Rhythmus (z. B. konsumentennaher SaaS mit dutzenden Deployments pro Tag) kann eine kürzere Schwelle sinnvoll sein, in regulierten Branchen mit wöchentlichen Releases (Finance, Public Sector) bleibt 72 Stunden der pragmatische Standard. Wichtiger als die exakte Schwelle ist die Konsistenz: Wer einmal eine Schwelle gewählt hat, sollte sie für mindestens vier Quartale beibehalten, um Trendvergleiche zuzulassen.
Code Churn misst die Volatilität auf Code-Ebene — wie oft eine Zeile geändert wird, bevor sie stabil bleibt. Rework Rate misst auf Deployment-Ebene — wie oft derselbe Service erneut released wird. Beide Metriken können sich ergänzen, sind aber nicht austauschbar. Hoher Code Churn ohne hohe Rework Rate bedeutet meist intensive Iteration vor dem Release; hohe Rework Rate ohne hohen Code Churn deutet auf große Änderungen, die unzureichend getestet ins Produktivsystem gehen. Für Governance-Zwecke ist Rework Rate aussagekräftiger, weil sie die organisatorische Lieferentscheidung misst, nicht nur das Entwickler-Verhalten.
Ja, sogar besonders gut. In monolithischen Systemen ist die Identifikation des Service-Identifiers trivial — es gibt nur einen — und jedes Deployment betrifft per Definition denselben Codebase. Die typische Falle in Monolithen ist eher, dass Rework Rate künstlich niedrig erscheint, weil viele Änderungen in seltenere, große Releases gebündelt werden. Hier hilft eine Aufschlüsselung nach Code-Modul oder Domäne: Auch wenn nur ein Deployment-Artefakt existiert, lässt sich nachverfolgen, welche Module innerhalb des 72-Stunden-Fensters wiederholt angefasst wurden. Diese Modulebene wird zur sinnvollen Granularität für Monolithen.
Vermeiden Sie das Framing "neue Metrik" — verwenden Sie stattdessen "blinden Fleck der bisherigen Berichterstattung". Zeigen Sie konkret an einem Beispiel aus den letzten zwei Quartalen: Hier waren MTTR und Change Failure Rate grün, aber dieses Team hat denselben Service 17 Mal in vier Wochen erneut deployed. Das Management versteht intuitiv, dass das ein Problem ist. Die Rework Rate ist die Zahl, die diese intuitive Erkenntnis als wiederholbare Kennzahl liefert. Erfahrungsgemäß braucht es einen einzelnen konkreten Fall, um das Reporting-Set dauerhaft zu erweitern — kein Strategiepapier ersetzt diesen Praxisbeleg.
Stand Mai 2026 haben Faros AI, GetDX und Plandek erste Rework-Rate-Dashboards veröffentlicht; Sleuth und LinearB haben Implementierung für Q3 2026 angekündigt. Für Self-Hosted-Setups gibt es bereits Pull Requests in Googles "Four Keys"-Projekt auf GitHub (https://github.com/dora-team/fourkeys), die eine Rework-Rate-Berechnung ergänzen. Wer keine fertige Plattform nutzen möchte, kommt mit einem 50-Zeilen-Python-Skript oder einer SQL-View gegen die CI-Logs ans Ziel — die fünfte Metrik ist bewusst so spezifiziert, dass keine spezielle Infrastruktur nötig ist.