Kontextwechsel-Kosten: Was 5 Mio. GitHub-PRs verraten
Wir haben Daten aus über 5 Mio. PRs ausgewertet, um die echten Kontextwechsel-Kosten für Entwickler zu messen – und sie liegen nicht dort, wo man denkt.
By Ellis Keane · 2026-03-29
Die Kontextwechsel-Kosten, die die meisten Artikel zitieren – 23 Minuten zur Refokussierung nach einer Unterbrechung, aus Gloria Marks UC-Irvine-Forschung – sind ein echtes Ergebnis einer echten Studie. Aber sie maß allgemeine Wissensarbeiter im Jahr 2008, nicht Softwareentwickler. Und die Cottage-Industrie von Blogbeiträgen, die 23 Minuten mit einer angenommenen Unterbrechungsanzahl multipliziert, um alarmierende jährliche Dollarbeträge zu produzieren (immer begleitet von einem Stockfoto von jemandem, der den Kopf hält), tut etwas, das die ursprüngliche Forschung nie beabsichtigt hat.
Ich habe ein persönliches Interesse an dieser Frage. Bei einem früheren Unternehmen verbrachte ich – und das ist keine Übertreibung – 80 bis 100 Prozent mancher Tage damit, ein menschlicher Router zu sein. Nicht Code schreiben, nicht Code reviewen. Informationen zwischen Menschen und Tools weiterleiten, weil kein einzelnes System sie verband. Diese Erfahrung ist ein Teil des Grundes, warum wir Sugarbug gebaut haben, aber auch ein Grund, warum ich den standardmäßigen Kontextwechsel-Kostenrechnern gegenüber skeptisch bin. Sie messen die Unterbrechung. Sie messen nicht die Tage, die man damit verbringt, nie zu dem zu kommen, womit man eigentlich beschäftigt sein sollte.
Daher wollten wir wissen, was Kontextwechsel bei der Entwicklungsarbeit tatsächlich kostet – nicht in abstrakten Begriffen der Entwicklerproduktivität, sondern gemessen an dem Artefakt, das Teams täglich produzieren: Pull Requests. Wir haben Erkenntnisse aus drei groß angelegten Studien zusammengefasst, die über 5 Millionen PRs in Tausenden von Open-Source-Projekten abdecken, und analysiert, was die Pull-Request-Review-Zeit tatsächlich bestimmt.
Der Hauptbefund: Der teuerste Kontextwechsel ist nicht die Slack-Benachrichtigung, die den Flow unterbricht. Es ist der Pull Request, der einen Tag lang in einer Review-Warteschlange sitzt und den Autor zwingt, ein ganzes mentales Modell neu aufzubauen, wenn endlich Fragen eintreffen.
Die Datensätze, auf die wir uns stützten
Wir haben keinen eigenen Scraper gebaut und 10.000 PRs isoliert analysiert. Wir haben Erkenntnisse aus zwei peer-reviewten Studien und einem großen Branchen-Datensatz synthetisiert und deren Schlussfolgerungen dann gegeneinander auf Belastbarkeit geprüft.
stat: "3,35 Mio." headline: "Von Zhang et al. analysierte Pull Requests" source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"
Die drei primären Datensätze:
- Zhang et al. (2022), peer-reviewed: 3.347.937 geschlossene PRs aus 11.230 Projekten. Verwendete gemischte lineare Regressionsmodelle, um zu identifizieren, was PR-Review-Verzögerungen verursacht. Veröffentlicht in Empirical Software Engineering.
- Adadot (2023), Branchen-Datensatz: Über 300.000 zusammengeführte PRs von ~30.000 Entwicklern. Nicht peer-reviewed, aber die Stichprobe ist groß und die Methodik (Kendall-tau-Korrelation) ist transparent. Fokus auf PR-Größe vs. Durchlaufzeit.
- Multi-Review-Studie (2019), peer-reviewed: 1.836.280 PRs aus 760 GitHub-Projekten. Veröffentlicht in Information and Software Technology. Untersucht gleichzeitiges Review-Verhalten – ein direkter Proxy für Kontextwechsel beim Code-Review.
Wir haben diese mit dem 2024 DORA State of DevOps Report und dem Atlassian Developer Experience Report 2024 (Befragung von über 2.100 Entwicklern zu Kontextwechsel, Entwicklerproduktivität und dem menschlichen Aspekt) querverwiesen.
Die Warteschlange ist der eigentliche Killer
Zhang et al. stellten fest, dass die Zeit, die ein PR benötigt, um seine erste Reaktion zu erhalten – erster Kommentar, erstes Review, irgend etwas Erstes – 58,7 % der Varianz in der Gesamtlebensdauer des PR erklärt. Das ist der stärkste beobachtete Prädiktor im Datensatz – vor PR-Größe, Code-Komplexität oder Anzahl der geänderten Dateien! Nicht einmal annähernd.
Die größten Kosten des Kontextwechsels beim Code-Review entstehen nicht durch das Wechseln selbst – sondern durch die Warteschlange, die sich bildet, während alle damit beschäftigt sind, zwischen anderen Dingen zu wechseln.
Denken Sie darüber nach, was das in der Praxis bedeutet. Ein Entwickler öffnet einen PR um 10 Uhr. Der designierte Reviewer steckt tief in seinem eigenen Feature-Branch, oder ist in einem Meeting, oder triage-t Slack-Nachrichten (und ehrlich gesagt wahrscheinlich alle drei nacheinander). Der PR wartet. Als jemand ihn um 15 Uhr aufgreift, ist der Autor längst zu etwas anderem übergegangen. Jetzt hat der Reviewer Fragen, was bedeutet, dass der Autor zu Code zurückwechseln muss, den er vor fünf Stunden geschrieben hat, das mentale Modell neu aufbauen und antworten muss. Diese Antwort trifft um 16:30 Uhr ein, aber der Reviewer ist nach Hause gegangen.
Der PR altert einen weiteren Tag.
Die Daten deuten darauf hin, dass dies eher ein Warteschlangenproblem als ein Disziplinproblem ist – und die Kontextwechsel-Kosten dieser Warteschlange potenzieren sich auf eine Weise, die Unterbrechungskalkulatoren vollständig übersehen.
Kleine PRs werden Sie nicht retten
Das haben Sie schon einmal gehört: Kleinere PRs werden schneller reviewed, also halten Sie Ihre PRs klein. Das ist nicht falsch, aber die Effektgröße ist (wirklich) kleiner als erwartet.
Adadots Analyse von über 300.000 PRs ergab eine Kendall-tau-Korrelation von nur 0,06 zwischen PR-Größe und Durchlaufzeit – eine schwache Assoziation, obwohl die Studie keine Konfidenzintervalle für die aggregierte Zahl angab. PRs unter 100 Zeilen haben eine Abschlusswahrscheinlichkeit von etwa 80 % innerhalb einer Woche, was großartig klingt, bis man erkennt, dass das die gleiche Abschlussrate ist wie bei einem PR, der sechs Tage lang in der Review-Warteschlange von jemandem saß!
stat: "0,06" headline: "Korrelation zwischen PR-Größe und Durchlaufzeit" source: "Adadot-Analyse von über 300.000 PRs von ~30.000 Entwicklern (2023)"
Der interessantere Befund: Diese Korrelation variierte stark zwischen Organisationen und reichte je nach Unternehmen von 0,1 bis fast 0,7. Was darauf hindeutet, dass die PR-Größe von sich aus nicht der Engpass ist – sondern die Review-Kultur und der Prozess um den PR herum. Ein Team mit einem starken Review-Rhythmus kann größere PRs effizient bearbeiten. Ein Team, bei dem Reviews nachrangig behandelt werden, wird mit PRs jeder Größe zu kämpfen haben.
Die 400-Zeilen-Schwelle aus der SmartBear/Cisco-Code-Review-Studie bleibt als nützliche Faustregel bestehen – Adadots Daten zeigten ebenfalls, dass das Review-Engagement über diesen Bereich hinaus nachlässt. Aber die PR-Größe zu optimieren, ohne den zugrunde liegenden Review-Rhythmus zu verbessern, ist (und das sage ich mit echter Sympathie für jeden Engineering Manager, der es versucht hat) das Umstellen von Liegestühlen auf der Titanic.
Alle reviewen alles gleichzeitig
Die Multi-Review-Studie ergab, dass 62 % der Pull Requests Entwickler umfassen, die gleichzeitig mehrere PRs reviewen. Noch wichtiger: Sie fanden eine statistisch signifikante Korrelation – mehr gleichzeitige Reviews pro Reviewer waren mit längerer PR-Auflösungslatenz verbunden.
62 % der Pull Requests betreffen Entwickler, die gleichzeitig mehrere PRs reviewen – und Multi-Review korreliert direkt mit längeren Auflösungszeiten. attribution: Multi-reviewing pull-requests study, 1,8 Mio. PRs aus 760 Projekten
Der Mechanismus ist intuitiv (auch wenn die Studie, da sie beobachtend ist, keine Kausalitätsrichtung beweist). Ein Reviewer nimmt PR Nr. 1 auf, liest den Diff durch und beginnt, ein mentales Modell davon aufzubauen, was der Code zu tun versucht. Dann trifft eine Benachrichtigung ein – PR Nr. 2 braucht ein Review, weil er ein Deployment blockiert. Der Reviewer wechselt. Wenn er zu PR Nr. 1 zurückkehrt, muss er die Hälfte des Diffs erneut lesen, weil das mentale Modell verblasst ist.
Wenn man das auf ein Team von acht Entwicklern skaliert, von denen jeder zwei oder drei PRs offen hat und jeweils für zwei oder drei Kollegen reviewt, beginnt der Koordinationsaufwand sich von selbst zu erklären. Getrennt davon stellte der 2024 DORA Report fest, dass der „High Performer"-Cluster von 31 % auf 22 % schrumpfte, während der Low-Performer-Cluster von 17 % auf 25 % wuchs. DORA isoliert die Gleichzeitigkeit von PR-Reviews nicht als Faktor, aber zunehmender Koordinationsaufwand ist ein plausibler Beitrag zu dieser Verschiebung.
Was die Schätzungen der Kontextwechsel-Kosten falsch machen
Lassen Sie mich direkt über die „50.000 $ pro Entwickler und Jahr"-Zahl sprechen, die in Artikeln über Kontextwechsel-Kosten weit verbreitet ist. Die Methodik hinter den meisten dieser Schätzungen lautet: Nehmen Sie die 23-minütige Refokussierungszeit, multiplizieren Sie mit der geschätzten Anzahl täglicher Unterbrechungen (meist irgendwo zwischen 6 und 15, je nachdem wie dramatisch der Autor gerade ist), multiplizieren Sie mit einem stündlichen Entwicklersatz und annualisieren Sie.
Das Problem ist nicht, dass die Mathematik falsch ist. Das Problem ist, dass alle Kontextwechsel als gleichwertig behandelt werden. Von tiefem Programmieren zu einer Slack-Nachricht wechseln, die fragt, wo das Team-Mittagessen stattfindet – das ist ein Kontextwechsel. Von einem PR-Review zu einem anderen PR-Review in einer völlig anderen Codebasis wechseln – das ist auch ein Kontextwechsel. Aber die kognitive Belastung ist nicht annähernd vergleichbar, und sie alle in einen einzigen Stundensatz zu pressen, verschleiert, wo der eigentliche Schaden entsteht.
Konkret ausgedrückt: Bei meinem letzten Job bedeutete ein typischer Tag das Wechseln zwischen Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster und unzähligen Telegram- und Signal-Kanälen – und ich bin sicher, dass ich ein halbes Dutzend vergesse. Jetzt nutze ich eine Handvoll (Signal, Obsidian, Figma, GitHub, E-Mail, Kalender). Die Kosten pro Wechsel haben sich nicht verändert. Was sich veränderte, war, wie viele Kontexte auf Aufmerksamkeit warteten – und welche davon tatsächlich wichtig waren.
Die PR-Daten deuten darauf hin, dass die teuren Wechsel diejenigen sind, die Warteschlangen erzeugen, nicht diejenigen, die den Flow unterbrechen. Ein Entwickler, der sofort (innerhalb von Minuten) angepingt wird, einen PR zu reviewen, und ein schnelles 50-Zeilen-Review macht – das ist eine kurze Unterbrechung mit hohem Ertrag. Ein Entwickler, der diese Review-Anfrage neben vier anderen in die Warteschlange stellt und sich morgen darum kümmert – das ist eine längere Unterbrechung für den Reviewer, erzeugt aber deutlich höhere Kosten für den Autor und das Team.
Was die Kostenkalkulatoren messen
- Individuelle Unterbrechungen – wie oft jemandes Flow unterbrochen wird
- Refokussierungszeit – wie lange es dauert, zur vorherigen Aufgabe zurückzukehren
- Multiplikation mit dem Stundensatz – große, beängstigende Jahreszahlen
Was die PR-Daten tatsächlich zeigen
- Warteschlangenbildung – PRs warten auf erste Reaktion
- Review-Gleichzeitigkeit – Reviewer jonglieren mehrere PRs
- Kaskadenverzögerungen – Autor-Kontextwechsel, die Reviewer-Verzögerungen verstärken
Was das für Ihr Team bedeutet
Wenn Sie versuchen, die Kontextwechsel-Kosten für Entwickler in Ihrem Team zu reduzieren, ist die praktische Antwort langweilig – was wahrscheinlich der Grund ist, warum darüber nicht viel geschrieben wird. Es ist kein Tool. Es ist kein Prozessrahmen mit einem Zertifizierungsprogramm. Es ist der Review-Rhythmus. (Ich weiß, ich weiß. Niemand wurde je für die Verbesserung des Review-Rhythmus befördert.)
LinearBs Engineering-Benchmarks 2025, die aus 6,1 Millionen PRs aus 3.000 Organisationen gewonnen wurden, ergaben, dass Teams mit Elite-Zykluszeiten (unter 2,5 Tagen) eine gemeinsame Eigenschaft hatten: Sie reviewten PRs schnell. Nicht weil sie weniger PRs hatten oder weil ihre PRs kleiner waren (obwohl das oft der Fall war), sondern weil das Reagieren auf Review-Anfragen innerhalb von Stunden eine Teamnorm war, kein Nachgedanke.
Der Vollständigkeit halber: Ben und ich – ein Zweierteam – reagieren durchschnittlich in Minuten auf die erste PR-Antwort, nicht in Stunden. Das ist keine Zurschaustellung von Disziplin (die haben wir nicht). Es ist eine Teamvereinbarung: Review-Anfragen sind die eine Benachrichtigung, die man nicht in die Warteschlange stellt. CI-Aktionen und automatisierte Tests erledigen die mechanischen Überprüfungen, was bedeutet, dass das menschliche Review – der Teil, der tatsächlich Kontext erfordert – kürzer ist und sofort stattfindet. Die Vereinbarung kam zuerst. Das Tooling hat sie nur nachhaltig gemacht.
Praktisch bedeutet das:
- Messen Sie die Zeit bis zur ersten Reaktion, nicht nur die Zykluszeit. Wenn Sie DORA-Metriken verfolgen, fügen Sie diese hinzu. Es ist der stärkste einzelne Prädiktor für den PR-Durchsatz (erklärt 58,7 % der Lebensdauervarianz, laut Zhang et al.).
- Begrenzen Sie die Review-Gleichzeitigkeit. Wenn ein Reviewer drei ausstehende Review-Anfragen hat, wird eine vierte ohnehin kein gutes Review bekommen. Die Multi-Review-Daten zeigten eine klare Assoziation zwischen Gleichzeitigkeit und Latenz. Beginnen Sie mit einem WIP-Limit von zwei gleichzeitigen Reviews und überwachen Sie die Auswirkung.
- Hören Sie auf, die PR-Größe isoliert zu optimieren. Kleine PRs sind gut, aber kein Ersatz für ein Team, das Dinge tatsächlich reviewt. Ein Team, das täglich zwanzig 50-Zeilen-PRs mit einem 48-Stunden-Review-Rückstand produziert, ist schlechter dran als ein Team, das fünf 200-Zeilen-PRs mit Review am selben Tag produziert.
- Erkennen Sie an, dass Reviewen echte Arbeit ist. Atlassians Umfrage von 2024 ergab, dass 69 % der Entwickler wöchentlich mehr als 8 Stunden durch Ineffizienzen verlieren. Review muss keine dieser Ineffizienzen sein – aber nur, wenn es als erstklassige Engineering-Aktivität behandelt wird, nicht als Unterbrechung der „echten" Arbeit.
Und hier ist der Teil, den niemand im Bereich der Produktivitäts-Tools (uns selbst eingeschlossen, um fair zu sein) laut sagen möchte: Die wirkungsvollste Intervention für Kontextwechsel-Kosten in Entwicklungsteams ist kein Tool. Es ist eine Teamvereinbarung darüber, wann PRs reviewed werden. Wenn die implizite Norm Ihres Teams „Ich kümmere mich um Reviews, wenn ich eine Lücke habe" ist, wird kein Ausmaß an Tooling die Warteschlangenkaskade verhindern, die die PR-Daten offenbaren.
Tools helfen – in der Lage zu sein, den vollständigen Kontext eines PR zu sehen, ohne vier Browser-Tabs zu öffnen, reduziert die kognitive Belastung pro Wechsel, und das Hervorheben, welche Reviews die Arbeit anderer blockieren, hilft bei der Priorisierung. Aber der Kernhebel ist die Vereinbarung, und Vereinbarungen sind kostenlos. Kein 23-Minuten-Kalkulator erforderlich.
Der teuerste Kontextwechsel ist nicht die Benachrichtigung, die Ihren Flow unterbricht. Es ist die Review-Anfrage, die einen Tag lang in einer Warteschlange sitzt und den Autor zwingt, mentalen Kontext neu aufzubauen, wenn endlich Fragen eintreffen.
Erhalten Sie Signalintelligenz direkt in Ihren Posteingang.
Häufig gestellte Fragen
Q: Wie hoch sind die Kontextwechsel-Kosten pro Entwickler und Jahr? A: Schätzungen variieren, doch die zugrunde liegende Forschung ist dünner als die meisten Artikel vermuten lassen. Gloria Marks Studie an der UC Irvine ergab 23 Minuten Refokussierungszeit pro Unterbrechung, und Atlassians Umfrage von 2024 unter über 2.100 Entwicklern stellte fest, dass 69 % wöchentlich mehr als 8 Stunden durch Ineffizienzen verlieren. Der Geldbetrag hängt stark von Gehaltsannahmen, Unterbrechungsfrequenz und der Definition von „Wechsel" ab – weshalb wir uns auf PR-Daten konzentriert haben.
Q: Hilft Sugarbug dabei, Kontextwechsel für Entwicklungsteams zu reduzieren? A: Ja. Sugarbug verbindet Tools wie Linear, GitHub, Slack und Figma in einem einzigen Wissensgraph, sodass Entwickler den vollständigen Kontext einer Aufgabe sehen können – den relevanten PR, die Slack-Diskussion, den Figma-Kommentar – ohne vier Tabs zu öffnen. Das Ziel ist weniger Wechsel, nicht weniger Tools.
Q: Was ist die ideale Pull-Request-Größe, um Review-Verzögerungen zu minimieren? A: Adadots Analyse von über 300.000 PRs ergab, dass PRs unter 100 Codezeilen mit einer Wahrscheinlichkeit von etwa 80 % innerhalb einer Woche abgeschlossen werden. Über 400 Zeilen sinken sowohl Review-Qualität als auch Abschlussgeschwindigkeit. Kleinere PRs reduzieren außerdem die Kontextwechsel-Last für den Reviewer.
Q: Integriert sich Sugarbug mit GitHub-Pull-Requests? A: Ja. Sugarbug erfasst GitHub-Aktivitäten – PRs, Kommentare, Reviews und Statusänderungen – und verknüpft sie mit verwandten Signalen in Ihren anderen Tools. Wenn ein Linear-Issue den PR ausgelöst hat und ein Slack-Thread den Ansatz diskutiert hat, verbindet Sugarbug alle drei automatisch.
Q: Woher stammt die Statistik „23 Minuten bis zur Refokussierung"? A: Sie stammt aus Gloria Marks Forschung an der UC Irvine, veröffentlicht in „The Cost of Interrupted Work: More Speed and Stress" (CHI 2008). Die Studie stellte fest, dass Mitarbeiter nach einer Unterbrechung durchschnittlich 23 Minuten und 15 Sekunden benötigten, um zu ihrer ursprünglichen Aufgabe zurückzukehren. Es ist erwähnenswert, dass die Studie allgemeine Wissensarbeiter beobachtete, nicht speziell Softwareentwickler.