Das Ritual kennt jedes Team: Sprintende, drei Stories sind nicht fertig. Sie wandern in den nächsten Sprint. In der Retro sagt jemand „wir haben uns übernommen", man nimmt sich vor, konservativer zu planen, vielleicht wird noch kurz über Schätzgenauigkeit philosophiert. Zwei Wochen später: dasselbe Bild, andere Stories.
Nach ein paar Monaten hat sich das Team daran gewöhnt. Der Sprint ist keine Verpflichtung mehr, sondern ein Vorschlag. Das Planning wird zur Zeremonie, deren Ergebnis niemand ernst nimmt — warum auch, es stimmt ja nie. Und die Velocity springt von Sprint zu Sprint so wild, dass jede Prognose Kaffeesatz ist.
Falls du glaubst, das sei die Ausnahme schlecht geführter Teams: Eine Befragung von Easy Agile — einem Anbieter von Jira-Werkzeugen, das gehört dazugesagt — unter 419 Engineers in fünf Ländern kam Anfang 2026 auf 80 Prozent der Teams, die jeden Sprint unfertige Arbeit in den nächsten schieben. Nur eines von fünf Teams schliesst seine Sprints regelmässig sauber ab. Spillover ist nicht der Betriebsunfall. Er ist der Normalzustand.
Der Fehler liegt in der Diagnose. „Besser schätzen" behandelt Spillover als Prognoseproblem — als hätte das Team nur die falsche Zahl gewürfelt. Aber eine Story wird nicht deshalb nicht fertig, weil die Schätzung falsch war. Die Schätzung war falsch, weil etwas die Story aufgehalten hat. Die Frage ist nicht „warum haben wir uns verschätzt", sondern „was hat sie aufgehalten".
Jede übergelaufene Story hat einen Absender
Lies Spillover wie Post: Jede Story, die den Sprint nicht schafft, ist eine Postkarte aus deinem System — und auf jeder steht ein Absender. Es sind fast immer dieselben fünf:
„Ich war grösser, als ihr dachtet." Die Story entpuppte sich als Wundertüte — die Überraschung sass tief drin und wurde erst am Tag sechs gefunden. Das ist keine Schätzschwäche, das ist eine Schnitt-Entscheidung.
„Ich habe auf jemanden gewartet." Die Freigabe der Security, die Antwort der Fachabteilung, die Lieferung des anderen Teams. Die Abhängigkeit war da, bevor der Sprint begann — entdeckt wurde sie mittendrin.
„Mich hat unterwegs jemand überholt." Etwas „Dringendes" kam rein, das Team wurde umgelenkt, die Story blieb liegen. [Wo kein Sprintziel sagt, was zählt, gewinnt der Lauteste.](→ Link zum Sprintziel-Artikel)
„Ich war nicht fertig gedacht, als ich anfing." Halbklare Anforderung, offene Fachfragen, Stop-and-Go. Die Story war nie ready — sie hätte den Sprint gar nicht betreten dürfen.
„Ich stand in der Schlange." Fertig entwickelt am Dienstag, gemerged am übernächsten Montag — dazwischen Review-Warteschlange. Die Arbeit war schnell, das Warten war langsam.
Fünf Absender, fünf verschiedene Gegenmassnahmen — und keine einzige davon heisst „konservativer schätzen". Wer auf Spillover mit Schätz-Disziplin reagiert, beantwortet Post, ohne den Absender zu lesen.
Was Spillover wirklich kostet
Der Schaden ist grösser als die verlorene Planbarkeit:
Übergelaufene Arbeit altert schlecht. Daniel Vacanti, dessen Arbeit zu Fluss-Kennzahlen das Standardwerk ist, hält Work Item Age — das Alter angefangener Arbeit — für den wichtigsten Frühindikator überhaupt: Je länger etwas offen ist, desto unwahrscheinlicher wird sein sauberes Ende. Der Kontext verdunstet, der Branch driftet weg, die Anforderung überholt sich. Eine Story im dritten Sprint ist nicht dieselbe Story wie im ersten — sie ist teurer, riskanter und unbeliebter.
Die Sprintgrenze verliert ihre Funktion. Der Sinn der Timebox ist der Takt: ein festes Intervall, an dem Realität und Plan verglichen werden. Wenn Überlaufen normal ist, gibt es keinen Vergleich mehr — nur noch einen kontinuierlichen Brei mit zweiwöchentlichen Meetings. Der Heartbeat schlägt dann noch, aber er pumpt nichts mehr.
Das Team lernt Resignation. Nichts demoralisiert zuverlässiger als ein Commitment, das strukturell nie zu halten ist. Nach genug übergelaufenen Sprints hört das Team auf, das Planning ernst zu nehmen — die vernünftigste Reaktion auf ein Versprechen, das das System nicht einlösen lässt.
Die Velocity wird zum Rauschen. Nicht, weil die Kennzahl lügt — das tut sie auf andere Weise —, sondern weil halbfertige Arbeit die Zählung zerhackt: null Punkte im einen Sprint, doppelte im nächsten. Wer damit plant, plant mit einem Zufallsgenerator.
Der eine Eingriff
Eine Klarstellung vorweg, damit der Eingriff nicht ins Falsche zielt — sie stammt von Mike Cohn: Gelegentliches Spillover ist gesund. Ein Team, das nie überläuft, zielt zu tief; wer ambitioniert plant, verfehlt manchmal, und das ist ein Zeichen von Anspruch, nicht von Versagen. Das Problem ist das habituelle Spillover — wenn Überlaufen die Regel ist und das Sprintende zu einem willkürlichen Datum verkommt. Die Absender-Liste unterscheidet genau das: Beim gesunden Überlaufen wechseln die Absender. Beim habituellen gewinnt immer derselbe.
Wenn du nur eine Sache änderst, dann diese:
Führe in der Retro eine Absender-Liste: Jede übergelaufene Story bekommt genau ein Wort — zu gross, Abhängigkeit, Prio-Wechsel, nicht ready, Warteschlange. Nach drei Sprints zählst du die Striche.
Keine Diskussion pro Story, keine Rechtfertigung, nur ein Wort und ein Strich. Der Aufwand liegt bei zwei Minuten pro Retro — und nach drei Sprints hast du etwas, das fast kein Team besitzt: eine Datenlage darüber, woran Sprints wirklich scheitern. Der häufigste Absender ist dein Engpass, und jetzt weisst du, welchen Artikel — und welche Massnahme — du zuerst brauchst.
Die Alternative ist die übliche: jedes Sprintende ein bisschen Schulterzucken, jede Retro derselbe Vorsatz, und die Post stapelt sich ungelesen.
Spillover ist nicht das Problem. Spillover ist die kostenlose, sprintgenaue Diagnose deines Systems — geliefert frei Haus, alle zwei Wochen. Du musst nur den Absender lesen, statt den Briefkasten zu beschimpfen.
Nächste Schritte
Wenn der häufigste Absender „zu gross" ist: → Zu grosse Stories sind kein Schätzfehler - sie sind eine Entscheidung
Wenn es „Abhängigkeit" ist: → Der stille Killer deiner Sprints sitzt nicht im Nachbarteam
Wenn es „Prio-Wechsel" ist: → Ein Sprint ohne Ziel ist eine ToDo-Liste mit Deadline
Wenn es „nicht ready" ist: → Die Kunst des effizienten Refinements
Wenn es „Warteschlange" ist: → Wo der Engpass auf deinem Board sichtbar wird
Führ die Absender-Liste drei Sprints lang und schreib mir, welcher Absender bei euch gewonnen hat. → Taleon LinkedIn
Quellen
- Easy Agile Research — Befragung von 419 Engineers in fünf Ländern, Februar 2026 (80 % der Teams schieben jeden Sprint unfertige Arbeit weiter; Easy Agile ist ein kommerzieller Anbieter von Jira-Werkzeugen). https://www.easyagile.com
- Vacanti, D. — «Actionable Agile Metrics for Predictability», ActionableAgile Press, 2015 (Work Item Age als wichtigster Frühindikator; Alterung angefangener Arbeit). https://actionableagile.com
- Cohn, M. — «Spillover in Agile: 3 Ways to Break an Unfinished Work Habit», Mountain Goat Software (Unterscheidung gelegentliches vs. habituelles Spillover). https://www.mountaingoatsoftware.com/blog/unfinished-work-every-sprint-three-ways-to-break-the-habit
- Schwaber, K.; Sutherland, J. — «The Scrum Guide», 2020 (der Sprint als feste Timebox und Taktgeber der Inspektion). https://scrumguides.org