Es gibt eine Story-Sorte, die jedes Board kennt. Sie heisst „Checkout überarbeiten" oder „Reporting-Modul" oder einfach „Migration, Teil 2". Sie wurde mit acht Punkten geschätzt, ist seit neun Tagen in Arbeit, und auf die Frage im Daily kommt seit einer Woche dieselbe Antwort: „Bin dran, fast fertig."
Niemand lügt dabei. Es fühlt sich wirklich fast fertig an — die ganze Zeit. Das ist die Eigenschaft grosser Stories: Sie sind unbestimmbar weit fortgeschritten. Bei einer Story von einem Tag Länge ist „fast fertig" eine Aussage. Bei einer von zwei Wochen ist es ein Gefühl.
Was eine grosse Story wirklich kostet
Die Kosten sind gut versteckt, weil sie nicht auf der Story selbst landen, sondern im System drumherum:
Sie versteckt Risiko. Eine grosse Story ist eine Wundertüte: Irgendwo in ihr steckt die Überraschung — die Legacy-Schnittstelle, die ungeklärte Fachfrage, die Abhängigkeit, die niemand vorab geprüft hat. Man findet sie garantiert, aber erst nach Tagen, wenn schon investiert ist und der Sprint halb vorbei. Kleine Stories finden dieselben Überraschungen — nur am Tag eins, wo sie billig sind.
Sie erzwingt Task Switching. Der Entwickler, der in der grossen Story auf die Überraschung trifft, ist blockiert — also springt er zum nächsten Ticket. Grosse Stories sind der zuverlässigste Erzeuger von halbfertiger Parallelarbeit, den es gibt.
Sie verdirbt jede Prognose. Ob ein Sprint zehn kleine Stories liefert oder neun, ist ein Rundungsfehler. Ob die eine grosse fertig wird oder nicht, ist ein Münzwurf — und mit ihr steht und fällt das Sprintziel. Teams mit grossen Stories wirken unzuverlässig, obwohl sie gleich gut arbeiten; ihre Varianz ist nur pro Stück grösser.
Sie verzögert Feedback. Solange die Story offen ist, sieht niemand etwas — kein Review, kein Test durch die Fachseite, kein Nutzerkontakt. Zwei Wochen Bauzeit heisst zwei Wochen Blindflug, und wenn die Richtung falsch war, sind es zwei Wochen Rückbau.
Donald Reinertsen, dessen «Principles of Product Development Flow» das Standardwerk zu dieser Frage ist, hat den Mechanismus dahinter ökonomisch durchgerechnet: Grosse Batches erhöhen Wartezeiten, Varianz und Risiko nichtlinear — halbierte Batch-Grösse bringt überproportional schnelleren Fluss. Sein trockenster Befund: Die Batch-Grösse ist in den meisten Organisationen die am wenigsten bewirtschaftete Stellgrösse überhaupt — dabei ist sie eine der wenigen, die nichts kostet ausser einer Entscheidung. Und DORA führt „Arbeiten in kleinen Batches" seit Jahren als eine der Kernfähigkeiten, die leistungsfähige von durchschnittlichen Organisationen trennen — im 2025er Report ausdrücklich auch als Voraussetzung dafür, dass KI-Tempo überhaupt in Lieferleistung ankommt statt in längeren Warteschlangen.
Die Fähre und die Ruderboote
Eine grosse Story ist eine Fähre: Sie legt erst ab, wenn sie voll ist. Alles, was auf ihr mitfahren soll, wartet — auf das letzte Detail, den letzten Sonderfall, die letzte Abklärung. Und wenn sie unterwegs ein Leck schlägt, sinkt die ganze Ladung zusammen.
Kleine Stories sind Ruderboote. Jedes legt ab, sobald es beladen ist. Kommt eines nicht an, verlierst du ein Boot, nicht die Flotte. Und du weisst nach dem ersten Boot, ob die Strömung stimmt — nicht erst, wenn alles auf dem Wasser ist.
Der Einwand kommt sofort: „Aber die Fähre ist pro Stück effizienter!" Stimmt — pro Stück, im Leerlauf gerechnet. Nur bezahlst du die Effizienz mit allem, was oben steht: Wartezeit, Blindflug, Klumpenrisiko. Fluss schlägt Auslastung. Das ist die vielleicht kontraintuitivste Lektion der Produktentwicklung, und Reinertsen hat ihr ein ganzes Buch gewidmet.
Warum Teams trotzdem gross schneiden
Weil klein schneiden Arbeit ist — und zwar genau die Denkarbeit, die man mit der grossen Story aufschieben kann.
Eine Story „vertikal" zu schneiden — so, dass jede Scheibe für sich lieferbar ist und etwas Prüfbares tut — zwingt dazu, das Problem wirklich zu verstehen: Was ist der Kern? Was ist Sonderfall? Was kann warten? Das ist anstrengend, und im Refinement ist es verführerisch leicht, stattdessen zu sagen: „Machen wir eine Acht draus." Die Acht ist keine Schätzung. Sie ist die Vertagung des Verstehens auf den Sprint — dorthin, wo es am teuersten ist. Wie ein Refinement aussieht, das diese Denkarbeit leistet, habe ich hier beschrieben.
Was vertikal heisst, hat Bill Wake mit INVEST zeitlos zusammengefasst — das V und das S sind die entscheidenden Buchstaben: Valuable (jede Scheibe tut etwas, das jemand prüfen kann) und Small (klein genug, dass „fast fertig" wieder eine Aussage ist). Nicht schneiden nach Schichten — „erst Backend, dann Frontend, dann Tests" erzeugt drei Stories, von denen keine allein etwas beweist. Schneiden nach Durchstichen: der einfachste Fall zuerst, komplett, von der Oberfläche bis zur Datenbank.
Der eine Eingriff
Wenn du nur eine Sache änderst, dann diese:
Führe im Refinement eine Grössengrenze ein: Jede Story, bei der das Team nicht überzeugt „in zwei, drei Tagen lieferbar" sagt, wird geschnitten, bevor sie sprintfähig ist. Keine Ausnahme für „lässt sich nicht schneiden" — das heisst übersetzt fast immer „haben wir noch nicht verstanden".
Die Grenze ist bewusst in Kalendertagen formuliert, nicht in Punkten — Punkte lassen sich verhandeln und inflationieren, Tage nicht. Und die Wirkung geht über die Story hinaus: Die Schneide-Diskussion im Refinement ist die Risikoanalyse, die sonst nie stattfindet. Wo sich eine Story nicht schneiden lässt, liegt fast immer die ungeklärte Fachfrage oder die versteckte Abhängigkeit — und jetzt findet ihr sie am Tisch statt am neunten Tag.
Grosse Stories fühlen sich an wie Gründlichkeit. Sie sind das Gegenteil: aufgeschobenes Verstehen, verstecktes Risiko und garantiertes Warten, verpackt in ein einziges Ticket. Das Schneiden ist nicht die Bürokratie vor der Arbeit. Es ist die Arbeit.
Nächste Schritte
Wenn beim Schneiden Abhängigkeiten zum Vorschein kommen: Gut — genau dafür ist es da. Wie sie geklärt werden, bevor sie blockieren: → Der stille Killer deiner Sprints sitzt nicht im Nachbarteam
Wenn dein Team trotz kleiner Stories ständig springt: Dann liegt die Ursache woanders. → Task Switching ist kein Fehler - es ist ein Symptom
Wenn Stories gross bleiben, weil das Refinement dafür keinen Raum hat: → Die Kunst des effizienten Refinements
Wenn du sehen willst, was kleine Batches auf Systemebene bewirken: → Wo dein Engpass auf dem Board sichtbar wird
Probier die Zwei-drei-Tage-Grenze zwei Sprints lang aus und schreib mir, was beim Schneiden zum Vorschein kam. → Taleon LinkedIn
Quellen
- Reinertsen, D. G. — «The Principles of Product Development Flow: Second Generation Lean Product Development», Celeritas Publishing, 2009 (Batch-Size-Ökonomie, Fluss vor Auslastung). https://www.celeritaspublishing.com
- DORA / Google Cloud — Capability «Working in Small Batches»; bestätigt im «State of AI-assisted Software Development» 2025 als Voraussetzung für wirksame KI-Nutzung. https://dora.dev/capabilities/working-in-small-batches/
- Wake, B. — «INVEST in Good Stories, and SMART Tasks», xp123.com, 2003 (Ursprung der INVEST-Kriterien). https://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
