Ja, Sie können PR-Durchlaufzeit messen ohne Teamüberwachung. Dafür genügen wenige Ablaufdaten aus der Pull Request selbst, etwa Erstellung, erste Reaktion und Abschluss. Entscheidend ist, diese Daten als Prozesssignal zu nutzen und nicht zur Bewertung einzelner Personen.
Dieser Beitrag betrachtet Azure DevOps Services mit Azure Repos. Eine Pull Request ist ein Änderungsvorschlag im Repository, der vor dem Merge geprüft wird. Gerade deshalb lassen sich Zeitpunkte aus dem normalen Review-Ablauf auslesen, ohne Bildschirmaktivität, Tastenanschläge oder ähnliche Formen personenbezogener Überwachung.
Im Kern brauchen Sie nur drei Blickrichtungen:
- Start der Pull Request
- erste erkennbare Reaktion
- Abschluss des Vorgangs
Wenn Sie den Ablauf zusätzlich gegen Richtlinien und maschinelle Prüfungen abgrenzen möchten, helfen die Beiträge zu KI-Code-Review für Azure Repos, was Maschinen prüfen und PR-Status als Richtlinie.
Welche Flow-Metriken wirklich helfen
Für den Einstieg reichen meist drei Flow-Metriken:
- Zeit bis zur ersten Review-Reaktion
- PR-Durchlaufzeit
- Größe der Pull Request
Die Zeit bis zur ersten Review-Reaktion ist ein Frühindikator. Sie zeigt, wie schnell eine Pull Request im Team Aufmerksamkeit bekommt. Sie sagt dagegen nicht, ob die Änderung gut war oder ob eine Person „schnell genug“ arbeitet. Als Reaktion können Sie zum Beispiel den ersten Kommentar, die erste Reviewer-Stimme oder eine erste formale Prüfung zählen.
Die PR-Durchlaufzeit ist die End-to-End-Metrik. Gemeint ist die Zeit vom Erstellen der Pull Request bis zum Abschluss, also bis zum Merge oder bis zum Schließen ohne Merge. End-to-End bedeutet hier: Sie betrachten den ganzen Ablauf vom Start bis zum Ende, nicht nur einen einzelnen Teilschritt. Diese Metrik macht vor allem Wartezeiten zwischen Übergaben sichtbar.
Die Größe der Pull Request ist die nötige Kontextmetrik. Sie lässt sich etwa über geänderte Dateien oder den Umfang der Änderungen beschreiben. Oft erklärt gerade sie, warum zwei Pull Requests sehr unterschiedliche Laufzeiten haben, obwohl derselbe Prozess gilt. Kleine Bugfixes und größere Umbauten sollten Sie deshalb nicht nach derselben Erwartung lesen.
Wichtig ist: Lesen Sie diese drei Metriken gemeinsam. Eine lange Durchlaufzeit ist für sich genommen noch kein Problem. Vielleicht war die Pull Request groß, brauchte einen zusätzlichen Build oder wartete auf einen fachlichen Reviewer. Auch reine Zählwerte wie Kommentaranzahl oder Reviewer-Anzahl helfen allein oft wenig, weil sie stark von Richtlinien, Codebasis und Teamgewohnheiten abhängen. Für typische Prüfpunkte im Review kann eine Checkliste im PR-Text oder eine fachliche Review-Checkliste den Ablauf besser strukturieren als bloß mehr Kommentare.
Dazu kommen die Richtlinien in Azure Repos. Branch Policies können unter anderem Mindestanzahl an Reviewern, Kommentarauflösung, verknüpfte Work Items, Build Validation, Status Checks, Merge-Typen und automatisch eingeschlossene Reviewer erzwingen; alle sind standardmäßig aus. Quelle: Microsoft Learn, „Branch policies overview“, gelesen am 01.11.2026, und „Branch policies“, gelesen am 01.11.2026. Wenn Sie etwa Pflicht-Reviewer gezielt einsetzen, Builds als Qualitätstor verwenden oder Reviewer-Stimmen bei neuen Pushes zurücksetzen, verändert das den Ablauf unmittelbar.
Mehr Pflichtschritte bedeuten jedoch nicht automatisch mehr Qualität. Sie verändern zunächst den Prozess, und genau das sehen Sie später in Ihren Metriken.
Woher die Daten in Azure DevOps kommen
Für belastbare PR-Metriken brauchen Sie keine Zusatzüberwachung, sondern eine saubere Ereignisquelle. In Azure Repos liegt sie in der Pull Request selbst: Zeitstempel für Erstellung und Abschluss, Review-Kommentare, Votes, Build-Ergebnisse, Statusmeldungen und Änderungen zwischen Iterationen. Iteration bedeutet hier: eine neue Fassung derselben Pull Request nach weiteren Pushes.
Entscheidend ist, die Ereignisse nach ihrer Funktion zu trennen. Für eine Auswertung sind vor allem diese Gruppen nützlich:
- Reaktionen von Menschen, etwa Kommentar oder Vote
- technische Prüfergebnisse aus Build oder Status Check
- Änderungen am Zustand der Pull Request, etwa abgeschlossen oder geschlossen
- neue Iterationen nach weiterem Push
Das ist in Azure DevOps mehr als ein Detail. Branch Policies können Mindestanzahl an Reviewern, verknüpfte Work Items, Kommentarauflösung, Build Validation, Status Checks, Merge-Typen und automatisch eingeschlossene Reviewer erzwingen; alle sind standardmäßig aus. Quelle: Microsoft Learn, „Branch policies overview“, gelesen am 01.11.2026, sowie „Branch policies“, gelesen am 01.11.2026.
Ebenso wichtig: Nicht jedes KI-Signal zählt wie eine Freigabe. Microsoft beschreibt für Azure Repos, dass Copilot code review in Public Preview ein Comment Review hinterlässt, damit keine Pflicht-Reviewer-Richtlinie erfüllt und kein Merge blockiert. Quelle: Microsoft Learn, „Review pull requests“, gelesen am 01.11.2026, sowie „Copilot code reviews“, gelesen am 01.11.2026. Das sollten Sie in Ihrer Messlogik getrennt halten.
Wenn Sie neue Werkzeuge prüfen, halten Sie Annahmen und offenen Stand sichtbar fest: auf der Seite zum Sicherheits- und Datenstand, im öffentlichen Änderungsverlauf und später bei Messwerten aus Realruns.
Metriken für den Prozess nutzen, nicht für Personen
Ablaufmetriken entfalten ihren größten Nutzen in der Prozesssteuerung. Sie machen sichtbar, wo Pull Requests warten, an welchen Übergaben Zeit verloren geht, wo Zuständigkeiten unklar sind und ab wann Änderungen schlicht zu groß für einen flüssigen Review-Ablauf werden.
Deshalb sollten Sie diese Daten vor allem auf Team-, Repository- oder Service-Ebene betrachten. Wenn Sie Metriken auf Personenebene veröffentlichen, verschiebt sich der Zweck schnell: Aus einem Signal für Engpässe wird dann leicht ein Instrument zur Leistungsdeutung. Für die Steuerung des Review-Prozesses ist das meist der falsche Fokus.
Sinnvoll sind eher Fragen wie diese:
- Wann liegen Pull Requests typischerweise unberührt?
- Welche Branch Policy erzeugt zusätzliche Wartezeit?
- Ab welcher PR-Größe steigt die Durchlaufzeit deutlich an?
- Wo entstehen wiederholt Rücksprünge zwischen Autorin oder Autor, Review und Build?
Gerade die PR-Größe sollten Sie getrennt auswerten. Große Architekturänderungen brauchen oft andere Review-Wege als kleine Bugfixes. Wenn beides in derselben Erwartungsklasse landet, wirken die Zahlen schnell schlechter, als der Prozess tatsächlich ist.
Auch die „Zeit bis zur ersten Review-Reaktion“ braucht Kontext. Bereitschaftsmodelle, Zeitzonen oder eine kleine Zahl domänenspezifischer Reviewer können diese Metrik stark prägen. Notieren Sie deshalb immer, unter welchen Rahmenbedingungen die Daten entstanden sind. Sonst vergleichen Sie scheinbar dieselbe Kennzahl, meinen aber unterschiedliche Arbeitsrealitäten.
Hinzu kommen Einstellungen in Azure Repos selbst. Policy-Optionen wie „Require at least one approval on the last iteration“, „Reset all approval votes“ oder „Reset all code reviewer votes“ bei neuen Pushes beeinflussen die gemessene Zeit direkt. Quelle: Microsoft Learn, „Branch policies“, gelesen am 01.11.2026.
Wichtig ist die Einordnung: Solche Optionen können Metriken verlängern, ohne dass Ihr Prozess schlechter geworden ist. Häufig steigt nur die Zahl der Pflichtschritte je Iteration. Eine längere Durchlaufzeit kann dann Ausdruck eines bewusst strengeren Review-Ablaufs sein, nicht eines schwächeren Teams.
Setzen Sie Zielwerte daher besser als Gesprächsanlass ein, nicht als starre Vorgabe. Sonst lernen Teams leicht, die Metrik zu optimieren, statt Reviews fachlich sinnvoll zu führen. Wenn Sie bei neuen Werkzeugen oder künftigen Paket- und Anmeldewegen später Kennzahlen ergänzen, gilt derselbe Grundsatz: erst den Prozess lesen, dann die Zahl.
Häufige Fragen dazu
Welche Startmetrik bringt schnell brauchbare Hinweise?
Wenn Sie nur mit einer Kennzahl beginnen, nehmen Sie die Zeit bis zur ersten Review-Reaktion. Sie zeigt, ob Pull Requests sichtbar werden oder zunächst liegen bleiben. Für die ersten Entscheidungen ist das oft leichter nutzbar als eine einzige End-to-End-Zahl.
Ergänzen Sie früh die PR-Durchlaufzeit. Sonst sehen Sie nur den Einstieg ins Review, nicht aber, wo der Rest der Zeit bleibt.
Was zählt als erste Review-Reaktion?
Legen Sie die Definition vorab fest und halten Sie sie stabil. Sonst werden Zeitreihen unruhig, obwohl sich der Prozess kaum geändert hat.
In der Praxis kommen meist diese Ereignisse infrage:
- erster Kommentar
- erste Reviewer-Stimme
- erstes technisches Prüfsignal aus Build Validation oder Status Check
Mischen Sie menschliche und technische Reaktionen nicht unbemerkt. Ein Status Check ist ein Prozessereignis, keine fachliche Rückmeldung.
Sollte ich geschlossene Pull Requests ohne Merge mitmessen?
Ja, in der Regel schon. Sonst blenden Sie einen Teil des tatsächlichen Ablaufs aus. Gerade verworfene oder ersetzte Pull Requests zeigen oft, wo Unklarheiten in Zuschnitt, Zuständigkeit oder Vorbereitung entstehen.
Sinnvoll ist eine Trennung nach Abschlussart:
- abgeschlossen mit Merge
- geschlossen ohne Merge
Dann bleibt erkennbar, ob lange Laufzeiten aus erfolgreichem Review oder aus abgebrochenen Vorgängen stammen.
Wie gehe ich mit neuen Pushes in dieselbe Pull Request um?
Behandeln Sie neue Iterationen bewusst als eigenen Einflussfaktor. Eine Iteration ist eine neue Fassung derselben Pull Request nach weiterem Push. Mehrere Iterationen können sinnvoll sein, verlängern aber häufig den Ablauf.
Wichtig ist dabei der Blick auf Ihre Richtlinien. In Azure Repos können Einstellungen wie „Require at least one approval on the last iteration“, „Reset all approval votes“ und „Reset all code reviewer votes“ bei neuen Pushes die Zeit messbar verändern. Quelle: Microsoft Learn, „Branch policies“, gelesen am 01.11.2026.
Reicht ein Median, oder brauche ich mehr?
Ein Median ist ein guter Anfang, weil einzelne Ausreißer ihn weniger stark verschieben. Für Steuerungsgespräche genügt aber selten nur ein einziger Wert.
Nehmen Sie mindestens dazu:
- Anzahl der Pull Requests im Zeitraum
- getrennte Sicht nach Größenklassen
- getrennte Sicht nach Abschlussart
So vermeiden Sie, aus wenigen Sonderfällen eine allgemeine Prozessdiagnose abzuleiten.
Wann wird die Messung rechtlich oder mitbestimmungsrelevant?
Die Frage stellt sich, sobald PR-Daten personenbezogen ausgewertet oder zur Deutung von Verhalten und Leistung genutzt werden könnten. Für Betriebsräte sind dabei insbesondere § 87 Abs. 1 Nr. 6 und § 90 BetrVG relevant. Bei regulierten Unternehmen können zudem DORA oder das NIS2UmsuCG berührt sein.
Was das in Ihrem Fall bedeutet, sollten Sie mit dem Betriebsrat, der Datenschutzbeauftragten oder dem Datenschutzbeauftragten und gegebenenfalls mit einer Anwältin oder einem Anwalt prüfen.
Nächster Schritt
Beginnen Sie mit einem kleinen, klaren Messset in einem abgegrenzten Bereich, zum Beispiel für einen Haupt-Repository-Zweig oder ein Produktteam:
- Zeit bis zur ersten Review-Reaktion
- PR-Durchlaufzeit
- PR-Größe
Lesen Sie diese Werte anschließend immer zusammen mit den geltenden Branch Policies. Leiten Sie daraus nur Prozessmaßnahmen ab, etwa kleinere Pull Requests, klarere Reviewer-Zuständigkeiten oder sauberer gesetzte Status-Gates.
Wenn Sie KI-Unterstützung für Azure Repos bewerten, trennen Sie vier Punkte sauber: Preview-Status, Datenpfade, Richtlinienwirkung und den Unterschied zwischen Kommentar und blockierender Prüfung.
Falls für Sie der Weg vom Work Item zur Pull Request in Azure DevOps Services relevant ist: Polier von ballmüller solutions ist in Entwicklung und noch nicht verfügbar. Vorgesehen ist, Azure Boards Work Items in geprüfte Pull Requests in Azure Repos umzusetzen, ohne selbst zu mergen, unter den Branch Policies des Kunden.