Agile Sprints sollten unser Team schneller machen. Doch mit der Zeit bewirkten sie das genaue Gegenteil.

Tickets häuften sich. Teammitglieder jonglierten mit mehreren Aufgaben gleichzeitig. „Done“ bedeutete plötzlich nur noch „fast fertig“. Wir verbrachten mehr Zeit damit, Boards zu aktualisieren und Prioritäten zu klären, als tatsächlich Product zu shippen.

Also haben wir ein Experiment gestartet.

Das Problem mit klassischen Sprint-Strukturen

Die meisten Sprint-Systeme gehen davon aus, dass das Aufteilen von Arbeit in kleinere Tasks den Flow verbessert. In der Praxis haben wir aber das Gegenteil erlebt:

• Stories wurden in technische Subtasks zerstückelt
• Teammitglieder waren auf mehrere parallele Workstreams verteilt
• Context Switching wurde zum täglichen Normalzustand
• Standups verkamen zu einem Rauschen aus halbfertigen Statusmeldungen
• Wir haben Aktivität geliefert — keine Ergebnisse.

Also stellten wir eine andere Frage:
Was wäre, wenn wir komplette Arbeitseinheiten bauen — eine nach der anderen — und jede wie ein Mini-Produkt behandeln?

Unsere Lösung: Der Product Card Flow

Wir haben unser Sprint Backlog durch ein neues System ersetzt: Product Cards.

Jede Card war eine kleine, eigenständige Produktinitiative — so konzipiert, dass sie von einem Micro-Team verstanden, verantwortet und abgeschlossen werden konnte. Kein Aufteilen, kein Multitasking. Nur ein klares Ziel und ein vollständiger Execution-Zyklus.

Jede Product Card enthielt:

• Action Items & Tasks — Mit klaren Abnahmekriterien
• Vision & Ziele — Warum es diese Card gibt
• Eine grobe Schätzung in Tagen, nicht in Story Points
• Scope — Was rein gehört und was nicht
• Nächste Schritte — Was danach kommt, falls relevant
• Vorherige Iterationen — Was wir bereits gemacht und gelernt haben

Wir haben eine Card einem Team zugewiesen — in der Regel 2–3 Personen — und sie von Anfang bis Ende daran arbeiten lassen. Erst nach Abschluss einer Card ging es zur nächsten.

Kein Jonglieren. Keine überlappenden Aufgaben. Nur Deep Work an echten Ergebnissen.

Was wir beobachtet haben

Nach den ersten Wochen war der Unterschied offensichtlich.

• Die Delivery lief deutlich runder
• Ownership wurde klarer
• Gespräche verlagerten sich von Statusupdates hin zu Reviews und Demos
• Weniger Bugs, weniger Carry-overs und deutlich schnellere Lernzyklen

Noch wichtiger: Unser Team fühlte sich besser. Weniger Druck. Weniger Rauschen. Mehr Klarheit.

Wir haben nicht einfach „Tasks abgehakt“. Wir haben Features fertig gebaut.

Warum das funktioniert hat

Die Magie lag nicht nur im Format — sondern im Fokus.

• Eine Card pro Team eliminierte Context Switching
• Definierte Endzustände zeigten uns genau, wann wir fertig waren
• Klare Ziele und User-Kontext gaben jeder Zeile Code einen Sinn
• Ownership von Anfang bis Ende förderte Stolz und Verantwortungsbewusstsein

Kurz gesagt: Wir haben aufgehört, Aufwand zu zerschneiden — und angefangen, echten Mehrwert zu shippen.

Wäre das auch etwas für euer Team?

Wenn euer Team unter Folgendem leidet:

• Sprint Spillover
• Ständiger Parallelarbeit
• Oberflächlicher Ownership
• Standups voller „Ich bin immer noch an dem Ticket dran“

…dann probiert doch mal ein einmonatiges Product-Card-Experiment aus.

Vielleicht entdeckt ihr wieder, wie sich fokussiertes Shipping anfühlt.

Product Cards als lebendige Product Map

Eine der größten Veränderungen passierte schleichend über die Zeit: Wir fingen an, die Cards wiederzuverwenden.

Beim ersten Mal half uns eine Product Card dabei, ein Feature zu scopen und abzuschließen. Doch ein paar Monate später, als wir denselben Bereich verbessern oder erneut anfassen wollten — Onboarding, Reporting, Berechtigungen — haben wir nicht bei null angefangen. Wir haben einfach dieselbe Card wieder geöffnet.

Jede Card hatte bereits:

• Den Kontext
• Die Constraints
• Die getroffenen Entscheidungen
• Die Historie der Änderungen
• Und Ideen, die wir zurückgestellt hatten

Statt verstreuter Dokumente oder Wissen, das nur in den Köpfen einzelner existiert, hielt die Card den gesamten Lebenszyklus dieses Produktbereichs fest.

Als sich das wiederholte, passierte etwas Bemerkenswertes: Unser Board mit Product Cards wurde zur Map des Produkts selbst.

Es war keine Aufgabenliste mehr. Es wurde zu:

• 🧱 Der Architektur jedes Features
• 📚 Der Dokumentation von Entscheidungen
• 🧭 Einer navigierbaren, sich entwickelnden Map der Produktgeschichte
• 🔁 Einem Weg, Arbeit fortzusetzen, ohne erst wieder Kontext aufbauen zu müssen

Wenn wir jetzt ein neues Quartal planen oder ein neues Teammitglied onboarden, gehen wir Cards durch, nicht Meetings. Wenn wir ein Feature revisiten, starten wir mit Verständnis, nicht mit Neuerfindung.

Das war nicht nur eine bessere Art, Arbeit zu liefern. Es war eine bessere Art, das Produkt im Gedächtnis zu halten — als System, nicht nur als Backlog.

Fazit

Wir haben Sprints nicht ersetzt, weil wir sie gehasst haben. Wir haben sie ersetzt, weil sie uns nicht mehr dabei geholfen haben, echte Dinge fertigzustellen. Product Cards haben uns gegeben:

• Fokus
• Flow
• Ownership
• Und eine nachhaltige Spur von Arbeit, die auf sich selbst aufbaut

Es war eine der wichtigsten Prozessänderungen, die wir je gemacht haben — nicht weil es gerade im Trend lag, sondern weil es tatsächlich funktioniert hat.