Kollabe
Rückschauen
Planungspoker
Standups
Eisbrecher
Preise
Armaturenbrett

Beiträge

Der Code-Review-Engpass wächst: Was 11.000 Retro-Beschwerden zeigen

Flache Illustration einer langen Schlange von Papierdokumenten, die vor einem einzigen kleinen Tor warten, während eine Figur Dokumente abstempelt und sich andere dahinter stapeln
Kelly Lewandowski

Kelly Lewandowski

Zuletzt aktualisiert am 19/07/20267 Min. Lesezeit

Als wir eine Million Retro-Karten analysiert haben, war Code Review nicht die häufigste Beschwerde. Diese Krone holte sich Testing. Aber Code Review war die Beschwerde, für die Teams am häufigsten gestimmt haben, und sie hatte ein Detail, das uns nicht losließ: Über tausend Karten im Datensatz sind nahezu wortgleiche Umschreibungen eines Satzes: "Pull Requests hängen zu lange und warten auf Review." Also sind wir tiefer gegangen. Gleiche Methode wie zuvor: aggregierte Analyse von Retrospektiven, die auf Kollabe durchgeführt wurden, Spalten anhand des Namens als positiv oder negativ klassifiziert, Themen durch konservative englische Keywords zugeordnet, keine einzelne Karte zitiert oder identifizierbar. Das bringt 11.246 Code-Review-Beschwerdekarten zutage, geschrieben zwischen Oktober 2023 und Juli 2026, und einen Befund, der Engineering-Verantwortliche in der KI-Ära beunruhigen sollte.
11,246

Code-Review-Beschwerdekarten

+30%

Wachstum des Beschwerdeanteils seit 2024

0.75

Stimmen pro Karte — höchster aller Themen

Die einzige Pipeline-Beschwerde, die wächst

Die meisten Beschwerdethemen halten Jahr für Jahr einen konstanten Anteil an den Retro-Boards. Testing, der Spitzenreiter beim Volumen, liegt seit Anfang 2024 in jedem Quartal zwischen 10 % und 12 % der Beschwerden. Code Review ist die Ausnahme:

Durchschnitt 2024

3.8%

Durchschnitt 2025

4.1%

2026 bisher

4.8%

Anteil aller Beschwerdekarten, die Code Review, PRs oder Reviewer erwähnen: rund 30 % höher als der Durchschnitt von 2024, Quartal für Quartal stetig steigend und Mitte 2026 an der 5-%-Marke kratzend. Jede elfte Retrospektive enthält inzwischen eine Review-Beschwerde. Wir können die Ursache aus den Kartenzahlen nicht beweisen. Aber der zeitliche Verlauf passt zu der einen Sache, die sich am stärksten daran geändert hat, wie Software geschrieben wird: KI-Coding-Assistenten haben das Volumen an Code erhöht, der am Review-Tor ankommt, während die Zahl der Menschen auf der anderen Seite gleich blieb. Die Beschwerde, die wächst, ist die Warteschlange. Über das größere Muster haben wir in Warum Retrospektiven mit KI-Coding-Tools wichtiger werden geschrieben.

Was Teams tatsächlich über Review sagen

Innerhalb der 11.246 Karten ordnen sich die Unterthemen so ein (Kategorien überlappen sich; Keyword-Untergrenzen):

Warten — PRs hängen zu lange

10.4%

Feedback-Qualität und Nitpicks

6.3%

Verfügbarkeit von Reviewern

4.8%

PRs zu groß zum Reviewen

4.2%

Priorisierung von Reviews

2.5%

Merge-Konflikte durch veraltete PRs

1.0%

Warten dominiert, wie erwartet. Die Überraschung liegt in den Stimmen:
  • PR-Größe: 0,99 Stimmen pro Karte. Das meistgevotete Review-Unterthema, um die Hälfte über der Basislinie von 0,65. Teams wissen, dass überdimensionierte PRs die vorgelagerte Ursache für alles andere auf dieser Liste sind.
  • Feedback-Qualität: 0,77. Nitpick-Kriege und Drive-by-Kommentare finden schnell Zustimmung.
  • Warten: 0,73. Am häufigsten geschrieben, etwas weniger gevotet — jeder weiß es ohnehin schon.
Es gibt auch ein hoffnungsvolles Signal in den positiven Spalten: 7.943 Lob-Karten erwähnen Review. Auf jede drei Review-Beschwerden danken zwei Karten einem Reviewer oder feiern einen reibungslosen Review-Zyklus. Teams merken, wenn Review funktioniert.

Warum Review-Beschwerden zusätzliches Gewicht verdienen

Stimmen sind das ehrliche Signal der Retro. Jeder kann eine Karte schreiben; Stimmen kosten knappe Aufmerksamkeit. Ein Thema, das sowohl im Volumen steigt als auch bei den Stimmen führt, ist die Definition eines wachsenden Engpasses — und es ist die Art von Sache, die sich in aller Öffentlichkeit versteckt, weil sich Review-Verzögerung eher wie Wetter anfühlt als wie eine Entscheidung.

Den Engpass aufbrechen

Flache Illustration eines großen Papierdokuments, das in mehrere kleine, ordentliche Dokumente geschnitten wird, die zügig durch mehrere offene Tore fließen Die Stimmen der Unterthemen zeigen die Reihenfolge der Behebung:
  1. Verkleinere zuerst die PRs. Es ist aus gutem Grund die meistgevotete Beschwerde: Kleine PRs werden schneller und besser gereviewt, und sie veralten seltener. Wenn Stories immer wieder PRs mit tausend Zeilen erzeugen, beginnt das Problem im Refinement — Stories richtig aufzuteilen ist Review-Hygiene in Verkleidung.
  2. Mach die Review-Latenz sichtbar. Teams streiten über Anekdoten, bis jemand die Zeit bis zum ersten Review misst. Flow-Metriken verwandeln "PRs hängen ewig" in eine Zahl, die sinken kann.
  3. Einigt euch auf ein Zeitfenster für die erste Rückmeldung. Kein vollständiges Review, eine erste Rückmeldung. Der meiste Schmerz in den Warten-Karten ist das Schweigen, nicht die Gesamtdauer.
  4. Schließt den Kreis in der Retro. Eine Review-Beschwerde, die zwei Retros hintereinander auftaucht, ist kein Feedback mehr. Gib ihr einen Verantwortlichen und ein Fälligkeitsdatum — Action Items mit Verantwortlichem werden 2,7-mal häufiger abgeschlossen.
Wenn Review immer wieder auf deinem Board auftaucht, führe die nächste Retro mit einer eigens dafür bestimmten Spalte durch und stimme ehrlich ab. Der Generator für Retrospektiven-Vorlagen kann in wenigen Sekunden ein review-fokussiertes Format erstellen, und die vollständigen aggregierten Zahlen hinter diesem Beitrag findest du auf unserer Retrospektiven-Statistik-Seite.

Ja. In unseren Daten aus 87.719 Retrospektiven stieg der Anteil von Code Review an allen Beschwerdekarten von einem Durchschnitt von 3,8 % im Jahr 2024 auf 4,8 % im Jahr 2026, also rund 30 % Wachstum, während andere Pipeline-Themen wie Testing konstant blieben.

Über das Warten. Etwa jede zehnte Review-Beschwerde erwähnt ausdrücklich PRs, die zu lange hängen oder feststecken. Aber die meistgevotete Beschwerde ist die PR-Größe, was darauf hindeutet, dass Teams überdimensionierte PRs als eigentliche Ursache sehen.

Der zeitliche Verlauf ist aufschlussreich: Review-Beschwerden stiegen von 2024 bis 2026 stetig an, genau als KI-Assistenten das Volumen an Code erhöhten, das menschliche Reviewer erreicht. Kartenzahlen können keine Kausalität beweisen, aber Review ist das einzige Thema der Delivery-Pipeline, das in unseren Daten wächst.

Aggregierte, anonymisierte Analyse von 1.081.076 Karten aus 87.719 Sprint-Retrospektiven, die zwischen Oktober 2023 und Juli 2026 auf Kollabe durchgeführt wurden. Spalten nach Namen klassifiziert, Themen durch konservatives Keyword-Matching. Keine einzelne Karte wird zitiert oder ist identifizierbar. Abfrage vom 19. Juli 2026; die ursprüngliche Analyse nutzte einen Stand vom 14. Juli, daher sind ihre Gesamtzahlen etwas kleiner.