Was misst die Lead Time for Changes?
Die Lead Time for Changes misst die Zeit vom ersten Commit bis zum Deployment in Produktion. Sie ist eine der DORA-Metriken und zeigt, wie schnell eine Organisation Ideen in ausgelieferte Software umsetzen kann. Im DORA-Report 2024 braucht das Elite-Cluster weniger als einen Tag, das Low-Cluster ein bis sechs Monate.
Auch bekannt als: Lead Time · Change Lead Time · Änderungsvorlaufzeit · DORA Lead Time
Ist Lead Time for Changes 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.
Die Uhr startet mit dem Commit und stoppt, wenn die Änderung in Produktion läuft. Dazwischen liegen Code-Review, Merge, Build, automatisierte Tests, Freigabe und Deployment. Für die Messung ordnen Sie jedem Produktiv-Deployment die Commits zu, die es erstmals ausliefert, und berechnen für jeden Commit die Differenz der Zeitstempel. Die Commit-Zeit liefert Git, die Deployment-Zeit das Event der Pipeline. Aus allen Werten eines Zeitraums nehmen Sie den Median, weil ein einzelner Commit, der drei Monate in einem Feature-Branch lag, den Mittelwert sonst verfälscht.
Wichtig ist, wo die DORA-Metrik nicht misst. Die Lead Time im Value Stream Management beginnt oft bei der Idee oder dem Ticket und schließt Anforderungsklärung und Priorisierung ein. DORA startet bewusst erst beim Commit, damit die Kennzahl den Delivery-Prozess abbildet und nicht die Produktplanung. Im DORA-Report 2024 lag das Elite-Cluster unter einem Tag, das High-Cluster zwischen einem Tag und einer Woche, das Medium-Cluster zwischen einer Woche und einem Monat und das Low-Cluster zwischen einem und sechs Monaten. Kurze Lead Times sind meist die Voraussetzung dafür, dass ein Team häufig deployen kann.
In der Industrie verlängern Nachweispflichten die Vorlaufzeit vom Commit bis zur Produktion. Software für funktionssichere Systeme nach ISO 26262 oder für Anlagen nach IEC 62443 braucht dokumentierte Prüfungen, bevor sie ausgeliefert werden darf. Solche Prüfungen lassen sich oft als Pipeline-Stufe mit automatisch erzeugtem Nachweis abbilden. Was sich nicht automatisieren lässt, gehört als eigener Wartezeit-Block in die Messung, damit sichtbar bleibt, wie viel Zeit die Freigabe kostet.
Der teuerste Stolperstein ist eine Pipeline, die in zwölf Minuten durchläuft, während die Änderung danach fünf Tage auf eine Unterschrift wartet. Der Hotfix ist fertig, die Anlage läuft so lange mit dem bekannten Fehler weiter. Wer die Lead Time verkürzen will, zerlegt sie deshalb zuerst in Abschnitte: Wartezeit auf Review, Review, Build und Test, Wartezeit auf Freigabe, Deployment. Meist steckt der größte Block in einer Wartezeit und nicht in der Rechenzeit.
Drei von fünf Tagen Wartezeit vor der Freigabe
Ein Maschinenbau-Team hielt seine Build-Server für den Engpass und plante neue Hardware. Die erste zerlegte Messung zeigt eine Lead Time von fünf Tagen, von denen mehr als drei auf das Warten vor manuellen Freigaben entfallen. Das Team definiert Regeln, nach denen Änderungen mit grünen Tests und abgeschlossenem Review automatisch freigegeben werden, und behält die manuelle Freigabe für sicherheitsrelevante Module. Die Lead Time sinkt auf unter einen Tag, die Hardware-Bestellung entfällt.
IEC-62443-Prüfungen als Pipeline-Stufe
Ein Embedded-Team ließ Security-Prüfungen nach IEC 62443 am Ende jedes Release-Zyklus von Hand durchführen, was die Lead Time um Wochen verlängerte. Es verlagert Schwachstellen-Scans, SBOM-Erstellung (Software Bill of Materials) und Konfigurationsprüfungen als automatisierte Stufen in die Pipeline, die bei jedem Commit laufen. Der Nachweis entsteht dabei nebenbei, und die Lead Time bleibt kurz.
Wo steckt Ihre Wartezeit bis zum Deploy?
Lead Time ist zum Großteil Wartezeit — sie sitzt in Builds, Übergaben oder Freigaben. Zwei Klicks zeigen, wo Ihr Engpass liegt.
Wo geht die meiste Zeit verloren?
- Was misst DORA als Lead Time for Changes?
- DORA misst die Zeit, die eine Änderung vom Commit in die Versionsverwaltung bis zum Deployment in Produktion braucht. Vorgelagerte Phasen wie Anforderungsklärung oder Backlog-Priorisierung zählen nicht dazu. Die Metrik gehört im DORA-Modell zum Durchsatz, zusammen mit Deployment Frequency und Failed Deployment Recovery Time.
- Was ist eine gute Lead Time for Changes?
- Im DORA-Report 2024 lag das Elite-Cluster unter einem Tag, das High-Cluster zwischen einem Tag und einer Woche und das Medium-Cluster zwischen einer Woche und einem Monat. Der Report 2025 ordnet Teams nicht mehr in diese Stufen ein, sondern beschreibt sieben Team-Profile. Aussagekräftiger als der Vergleich mit anderen ist deshalb der Trend Ihres eigenen Services über mehrere Monate.
- Was bedeutet Lead Time außerhalb von DevOps?
- In Produktion und Logistik bezeichnet Lead Time die Durchlaufzeit vom Auftrag bis zur Lieferung, auf Deutsch meist Durchlauf- oder Vorlaufzeit. DevOps hat den Begriff übernommen und für die DORA-Metrik eingeengt. Wer mit Produktionsleitern über die Kennzahl spricht, sollte das dazusagen, sonst meinen beide Seiten unterschiedliche Strecken.
- Wie verkürzt man die Lead Time for Changes?
- Indem Sie zuerst messen, in welchem Abschnitt die Zeit verloren geht, und dort ansetzen. Meist sind es Wartezeiten auf Reviews oder Freigaben, nicht die Laufzeit der Pipeline. Kleinere Pull Requests werden schneller reviewt, automatisierte Tests ersetzen manuelle Testrunden, und Freigaberegeln in der Pipeline ersetzen die Unterschrift bei Routineänderungen.
- Was ist der Unterschied zwischen Lead Time und Cycle Time?
- Die Lead Time läuft ab dem Moment, in dem eine Anforderung gestellt oder zugesagt wird, die Cycle Time erst ab dem Beginn der Arbeit daran. Die Differenz ist die Zeit, die eine Anforderung im Backlog wartet. Die DORA-Metrik Lead Time for Changes ist trotz ihres Namens noch enger gefasst als beide, denn sie beginnt erst beim Commit und endet mit dem erfolgreichen Deployment in Produktion.
Wo steht Ihr Team bei Lead Time for Changes?
Uns interessiert, wo Ihr Team bei diesem Thema steht. Auf Basis Ihrer Antwort schlagen wir Ihnen den sinnvollsten nächsten Schritt vor — ganz ohne Formular.
Warum ist die MTTR so wichtig?
Was macht ein Platform-Engineering-Team?
Was unterscheidet SRE von klassischem Betrieb?
Was ist ein Maschinenstillstand?
Weiterführende Primärquellen zu Lead Time for Changes: Normtexte, Hersteller- und Projektdokumentation. Alle Ziele öffnen in einem neuen Tab.
- /01DORA / Google CloudDORA Metrics Guide(externe Seite, öffnet in neuem Tab)
Definiert die Zeitspanne vom Commit bis zum laufenden Produktivstand.
- /02Google Cloud BlogFour Keys in der Praxis messen(externe Seite, öffnet in neuem Tab)
Zeigt, welche Zeitstempel aus Git und Pipeline die Kennzahl speisen.
- /03IT RevolutionAccelerate(externe Seite, öffnet in neuem Tab)
Das Buch von Forsgren, Humble und Kim, in dem die Kennzahl wissenschaftlich hergeleitet wird.
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