Lead Time ist die Durchlaufzeit einer Änderung vom festgelegten Start bis zum klar definierten Ende. In Azure DevOps messen Sie Lead Time sinnvoll, wenn Sie Start und Ziel pro Team eindeutig festlegen und die Zahl immer im Zusammenhang mit Ihrem Pull-Request-Ablauf lesen.
Für die Praxis heißt das: Definieren Sie zuerst, welche Änderung Sie überhaupt messen. Sonst vergleichen Sie später verschiedene Strecken miteinander und erhalten eine Zahl, die präzise wirkt, aber wenig erklärt.
Sinnvoll ist eine knappe, feste Definition je Repository, zum Beispiel:
- Start an einem fachlichen Ereignis
- Ende bei der Integration über den Pull Request
- gleiche Regel für alle Auswertungen
In Azure DevOps gehört dazu auch der Rahmen, in dem Pull Requests geprüft und abgeschlossen werden. Branch Policies in Azure DevOps beeinflussen, welche Stationen zwischen Erstellung und Abschluss liegen und sollten deshalb von Anfang an Teil Ihrer Definition sein.
Welche Flow-Metriken wirklich helfen
Wer nach lead time sucht, meint oft eine einzige Zahl. In Azure DevOps wird diese Kennzahl aber erst dann belastbar, wenn Sie Start und Ende im Ablauf sauber festlegen: zum Beispiel vom Wechsel eines Work Items in die aktive Umsetzung bis zum Abschluss des zugehörigen Pull Requests.
Für Pull-Request-getriebene Teams helfen vor allem drei Teilmetriken:
- Zeit bis zur ersten Review: Diese Strecke zeigt, ob Änderungen zügig wahrgenommen werden. Für CTOs und Engineering Manager ist das nützlich, weil Engpässe häufig nicht im Coding liegen, sondern bei Aufmerksamkeit, Zuständigkeiten oder fehlender Reviewer-Abdeckung.
- Zeit bis zum Merge: Gemeint ist die Zeit vom eröffneten Pull Request bis zur Integration. Darin stecken Rückfragen, Überarbeitungen, Build-Wartezeiten und Policy-Prüfungen.
- Größe der Änderung: Große Pull Requests verzerren fast jede Zeitkennzahl. Deshalb sollten Sie Lead Time immer mit Größenkontext lesen, etwa nach Zahl geänderter Dateien oder Umfang der Änderung. Gerade bei Draft Pull Requests lohnt sich eine getrennte Betrachtung.
Für die Praxis wichtig: Berichten Sie nicht nur Mittelwerte. Schauen Sie zusätzlich auf Verteilungen und Ausreißer. Ein Durchschnitt kann verdecken, dass viele kleine Änderungen schnell laufen, während wenige große Pull Requests den Fluss blockieren.
Ebenso wichtig ist die Lesart: Diese Metriken beschreiben den Fluss des Systems, nicht die Leistung einzelner Personen. Sobald daraus ein Personenranking wird, verschlechtern sich meist sowohl Datenqualität als auch Verhalten im Prozess.
Andere Kennzahlen bleiben trotzdem relevant, aber mit anderer Rolle. Build-Dauer, Wartezeit auf Freigaben oder Zahl offener Kommentare ersetzen Lead Time nicht; sie helfen eher dabei, Ursachen zu erklären.
Wenn bei Ihnen Branch Policies aktiv sind, gehören sie zum gemessenen System. Microsoft nennt als typische Richtlinien Mindestanzahl von Reviewern, verknüpfte Work Items, Kommentarauflösung, Merge-Typen, Build Validation, Status Checks und automatisch eingeschlossene Reviewer; alle sind standardmäßig deaktiviert (Microsoft Learn, „Branch policies overview“, gelesen am 01.11.2026). Für die praktische Umsetzung helfen oft Branch Policies als Code, Bypass-Rechte und PR-Status als Richtlinie.
Woher die Daten in Azure DevOps kommen
Für lead time in Azure DevOps brauchen Sie die Messpunkte meist aus drei Quellen: Azure Boards für den Start der Arbeit, Azure Repos für Pull Requests und Commits sowie Pipelines und Policy-Ergebnisse für Prüf- und Wartezeiten.
Wichtig ist dabei Konsistenz. Legen Sie pro Metrik genau eine Ereignisquelle fest. Sonst messen Sie dieselbe Strecke einmal über Work-Item-Zustände und ein anderes Mal über PR-Zeitstempel. Das klingt klein, erzeugt in Berichten aber schnell widersprüchliche Werte.
Typische Zeitstempel sind:
- Erstellung eines Work Items
- Zustandswechsel in die Umsetzung
- Erstellung des Pull Requests
- erste Reviewer-Aktivität
- erfolgreiche Builds
- Status Checks
- Abschluss des Pull Requests
In Azure Repos wird der Verlauf eines Pull Requests auch durch Branch Policies geprägt. Microsoft beschreibt, dass sich Richtlinien per „az repos policy“ oder per REST API setzen lassen (Microsoft Learn, „Branch policies“ sowie „Securely use Git and pull requests in Azure Repos“, gelesen am 01.11.2026). Das ist relevant, wenn Sie Metriken organisationsweit mit denselben Regeln aufbauen wollen.
Für die Auswertung ist noch ein Punkt wichtig: Der Merge-Typ ist laut Microsoft eher History-Governance als ein direkter Sicherheitsmechanismus. Squash vereinfacht die Zielhistorie, bildet die Reihenfolge der Quell-Commits aber nicht vollständig ab. Wenn Ihr Audit-Modell auf der exakten Commitfolge beruht, empfiehlt Microsoft Merge-Commit-Strategien statt Squash (Microsoft Learn, „Securely use Git and pull requests in Azure Repos“, gelesen am 01.11.2026).
Das beeinflusst auch Ihre Messung. Wenn Sie Rework oder Commit-Abfolgen aus der Historie ableiten, müssen Sie wissen, ob Squash im Repository erlaubt ist.
Praktisch ist deshalb ein kleines Datenmodell zum Start: erst wenige, eindeutige Ereignisse messen und dann Stichproben in echten Pull Requests prüfen, bevor Sie Dashboards breit ausrollen. Wenn Sie die Erfassung automatisieren wollen, helfen die Vertiefungen zu Pull Requests per REST API und zu Service Hooks für Pull Requests.
Metriken für den Prozess nutzen, nicht für Personen
Wer nach lead time sucht, will am Ende meist nicht nur messen, sondern besser steuern. Dafür taugt die Kennzahl vor allem dann, wenn Sie sie als Signal für Prozessfragen lesen: Wo staut sich Arbeit, welche Regeln erzeugen Wartezeit, und an welcher Stelle wird aus einer kleinen Änderung unnötig ein langer Vorgang?
Nützlich sind Auswertungen, die Entscheidungen im Ablauf unterstützen, zum Beispiel:
- nach Repository oder Teamkontext,
- nach Größe und Zuschnitt der Änderung,
- nach Art der Freigabe im Pull-Request-Prozess,
- nach Wartephasen zwischen Review, Build und Abschluss,
- nach wiederkehrenden Mustern bei Rückfragen oder Nacharbeit.
So sehen Sie eher Systemeffekte als Einzelfälle. Eine Kennzahl ist dann hilfreich, wenn sie eine konkrete Anschlussfrage auslöst, etwa ob Reviewer zu spät eingebunden werden, ob Builds zu lange blockieren oder ob Änderungen zu groß in den Review gehen.
Vorsicht ist sinnvoll, sobald neue Automatisierung oder KI-Unterstützung hinzukommt. Mehr Kommentare, zusätzliche Statusmeldungen oder ein anderer Zuschnitt von Arbeit bedeuten für sich genommen noch keine nachgewiesene Verbesserung. Wenn Sie Wirkung prüfen wollen, brauchen Sie eine feste Ausgangsbasis, einen klar benannten Zeitraum und dieselbe Messlogik vor und nach der Änderung.
Für die Einordnung geplanter Ansätze hilft ein Blick auf Auswahlkriterien für Coding-Agenten. Wenn Sie später konkrete Produktangaben prüfen wollen, trennen Sie sauber zwischen aktuellem Stand, Änderungen und künftigen Nachweisen: was heute gilt und was noch nicht gilt, öffentliche Änderungen am Stand, später belastbare Messwerte und der vorgesehene Weg zur Anmeldung.
Betriebsrat und Governance kurz eingeordnet
Sobald sich Lead-Time-Daten auf Personen, Teams oder Arbeitsverhalten zurückführen lassen, geht es nicht mehr nur um saubere Messpunkte. Dann werden auch Mitbestimmung, Transparenz und die zulässige Nutzung der Auswertung wichtig.
Für Betriebsräte sind in Deutschland vor allem zwei Bezugspunkte typisch:
- § 87 Abs. 1 Nr. 6 BetrVG: vereinfacht geht es um technische Einrichtungen, die zur Verhaltens- oder Leistungsüberwachung geeignet sind.
- § 90 BetrVG: vereinfacht geht es um Informationen zu Arbeitsverfahren und zum Einsatz von KI.
In regulierten Umfeldern kommen weitere Fragen hinzu. Dazu zählen DORA, NIS2 und Datenschutz. Praktisch geht es dann etwa um folgende Punkte:
- welche Daten wohin fließen,
- wer Auftragsverarbeiter ist,
- welche Protokollierung vorgesehen ist,
- welche Kontrollen und Freigaben erwartet werden.
Dieser Artikel gibt dazu bewusst keine Rechtsberatung. Sinnvoll ist, die konkrete Ausgestaltung mit Rechtsabteilung, Datenschutzbeauftragten und gegebenenfalls dem Betriebsrat zu prüfen.
Zusätzlich kann bei Preview-Funktionen relevant sein, wo Daten verarbeitet werden. Für Copilot code review nennt Microsoft in der FAQ, dass die Data Residency nicht an die Azure-DevOps-Organisation gebunden ist und Verarbeitung auch in einer anderen Geografie wie den USA stattfinden kann (Microsoft Learn, „Copilot code reviews FAQ“, gelesen am 01.11.2026).
Wenn Sie den Governance-Rahmen für KI-gestützte PR-Prozesse weiter einordnen wollen, lohnt sich dazu ein gesonderter Blick.
Häufige Fragen zum Lead Time in Azure DevOps
Welche Enddefinition passt für Lead Time in Azure DevOps am besten?
Wer nach Lead Time sucht, will meist wissen, wann eine Änderung in Azure DevOps wirklich „fertig“ ist. Für Pull-Request-getriebene Teams ist ein Ende beim abgeschlossenen Pull Request oft praktikabel, weil dort Review, Policies und Integration zusammenlaufen.
Abweichungen sind sinnvoll, wenn Sie bewusst etwas anderes messen wollen:
- Abschluss des Pull Requests für die Strecke bis zur Integration
- erfolgreicher Produktionsschritt für die Strecke bis zur Auslieferung
- Abschluss eines verknüpften Work Items für die fachliche Sicht
Entscheidend ist, dass das Ende fachlich und technisch zusammenpasst.
Wie gehe ich mit Reopens und mehreren PR-Iterationen um?
Ein Reopen ist das erneute Öffnen eines bereits geschlossenen Pull Requests. Solche Fälle sollten Sie vorab als eigene Kategorie festlegen, statt sie still wie normale Fälle mitzuzählen.
Für die Messung helfen einfache Regeln:
- ursprünglichen PR als einen zusammenhängenden Vorgang zählen,
- Reopen-Fälle separat ausweisen,
- Iterationen nicht als neue Lead Time behandeln.
Sonst vergleichen Sie lineare Änderungen mit Rückläufern, ohne es im Bericht zu sehen.
Was tun, wenn ein Work Item mehreren Pull Requests zugeordnet ist?
Das kommt in Azure DevOps regelmäßig vor, etwa bei Nacharbeiten, Teilumsetzungen oder getrennten Repositories. Dann braucht Ihre Auswertung eine Vorrangregel. Ohne sie wird dieselbe Arbeit mehrfach gezählt.
Praktikabel sind zum Beispiel zwei Varianten: entweder den ersten abgeschlossenen Pull Request als Endpunkt nehmen oder den letzten, wenn erst dann die fachliche Änderung integriert ist. Wählen Sie genau eine Regel.
Gehören Auto-Complete und Queue-Zeiten in die Lead Time?
Ja, wenn sie Teil Ihres realen Ablaufs sind. Auto-Complete bedeutet, dass Azure DevOps den Pull Request erst abschließt, wenn die geforderten Bedingungen erfüllt sind. Wartet ein Pull Request auf Build Validation, Status Checks oder erforderliche Reviewer, dann ist das Durchlaufzeit des Systems.
Gerade für Entscheidungen im Engineering ist diese Sicht nützlich: Nicht jede Verzögerung ist aktive Bearbeitung, aber jede Verzögerung prägt den Fluss.
Nächster Schritt: klein anfangen, Definitionen festziehen
Setzen Sie für den Start einen kurzen Messzyklus auf. Nicht mit einem großen Dashboard, sondern mit einer kleinen Stichprobe aus einem klar abgegrenzten Ablauf.
Praktisch reicht zunächst:
- ein Repository,
- eine feste Startdefinition,
- eine feste Enddefinition,
- ein kurzer Zeitraum,
- eine manuelle Plausibilitätskontrolle.
Eine Plausibilitätskontrolle ist der Abgleich, ob die gemessenen Zeitpunkte zum tatsächlichen Ablauf passen. Erst wenn das sauber sitzt, lohnt sich Automatisierung.
Falls Sie später KI-Unterstützung im PR-Prozess bewerten wollen, trennen Sie die Frage nach der Messung von der Frage nach dem Werkzeug. Polier von ballmüller solutions, Berlin, ist ein Coding-Agent für Azure DevOps in Entwicklung und am 01.11.2026 noch nicht verfügbar.