Warum "Beschreiben und Launchen" Sprint-Planung ersetzen wird

TL;DR: Sprint-Planung entstand in einer Zeit, in der das Ausliefern von Software Wochen dauerte und Schätzungen verteidigt werden mussten. 2026 komprimieren KI-App-Builder Build-Zyklen dramatisch. Der Schätzaufwand — Story Points, Velocity-Berechnungen, Sprint-Commitments, Retro-Postmortems — übersteigt jetzt den Wert, den er schafft. "Beschreiben und Launchen" ist das aufkommende Muster: ein knappes PRD schreiben, das Feature in Stunden oder Tagen ausliefern, von echten Nutzern lernen, iterieren. Dieser Guide erklärt, warum Sprint-Planung zerbricht, was sie ersetzt und die neue operative Disziplin für Produktteams im Zeitalter der KI-App-Builder.

Einleitung

Sprint-Planung ist eines der universell verbreitetsten Rituale in moderner Software. Zweiwöchige Zyklen. Story Points. Velocity-Berechnungen. Sprint-Commitments und Retrospektiven. Die Methodik wird an Business Schools gelehrt, von Trainingsorganisationen zertifiziert und in jedes größere Projektmanagement-Tool eingebettet. Sie wurde zum Standard, weil sie ein reales Problem löste: Wenn das Ausliefern eines einzelnen Features Wochen an Engineering-Arbeit brauchte, benötigten Teams strukturierte Schätzung, Priorisierung und Verantwortlichkeit, um zu funktionieren.

2026 hat sich die zugrunde liegende Physik verändert. KI-App-Builder komprimieren Build-Zyklen von Wochen auf Stunden oder Tage. Features, die früher drei Engineers zwei Wochen lang brauchten, brauchen jetzt einen Builder für einen halben Tag. Der Schätzaufwand — Debatten darüber, ob etwas 3 oder 5 Story Points ist, Retros, die analysieren, was schiefgelaufen ist, Sprint-Commitments und verpasste Deadlines — übersteigt zunehmend den Wert, den er schafft. Die Methodik, die für langsame Build-Zyklen entworfen wurde, passt nicht zu schnellen.

Ein anderes Muster entsteht. "Beschreiben und Launchen." Ein knappes PRD schreiben, das Feature ausliefern, von echten Nutzern lernen, iterieren. Weniger Zeremonie, mehr Shipping. Dieser Guide erklärt, warum Sprint-Planung zerbricht, was sie ersetzt und welche operative Disziplin Produktteams für die neue Physik brauchen.

Was Sprint-Planung eigentlich löst

Sprint-Planung entstand aus einer spezifischen operativen Realität. Als das Ausliefern eines Features 2–4 Wochen Engineering-Arbeit brauchte, summierten sich mehrere Probleme.

• Hohe Kosten bei Fehlentscheidungen — Ein Feature brauchte 80–200 Stunden; das falsche zu bauen war teuer
• Bedarf an Priorisierung — Engineering-Kapazität war knapp; das Team konnte pro Sprint vielleicht 3 Features ausliefern
• Koordination zwischen Personen — Mehrere Engineers mussten sich auf Scope und Ownership einigen
• Stakeholder-Verantwortlichkeit — Business-Stakeholder brauchten planbare Liefertermine
• Karriere-Anreize — Engineers wurden an Delivery gemessen; Schätzung wurde ihr Accountability-Instrument

Sprint-Planung adressierte das. Schätzung gab Teams ein gemeinsames Verständnis der Kosten. Sprint-Commitments gaben Stakeholdern planbare Lieferung. Velocity-Berechnungen ließen die Führung Kapazität prognostizieren. Retros zwangen Teams, aus Fehlschlägen zu lernen. Die Methodik funktionierte, weil sie zur operativen Realität passte.

Was 2026 anders ist

Drei strukturelle Verschiebungen haben die zugrunde liegende Physik verändert.

Verschiebung 1: Build-Zyklen haben sich dramatisch komprimiert

Was früher 80 Stunden Engineering brauchte, braucht heute 4–8 Stunden Vibe Coding. Die Kompression ist nicht 2× — sie ist 10–20×. Ein CRUD-Feature, das ein Zweiwochenprojekt war, ist jetzt ein Nachmittag. Ein neuer nutzerseitiger Screen, der Designer plus Frontend-Engineer plus Backend-Engineer brauchte, ist jetzt eine einzige Prompt-Sequenz.

Verschiebung 2: Die Kosten der Schätzung blieben konstant

Die Zeit, ein Feature zu schätzen, zu planen, zu committen und zu reviewen, ist nicht mit der Build-Zeit geschrumpft. Eine 30-minütige Schätzungsdiskussion über ein Feature, das 4 Stunden zu bauen ist, sind 12 % Overhead. Dieselbe Diskussion über ein Feature, das 80 Stunden braucht, sind 0,6 % Overhead. Der Overhead der Sprint-Planung ist unverhältnismäßig geworden.

Verschiebung 3: Die Kosten von Fehlentscheidungen sind geschrumpft

Wenn ein Feature 80 Stunden zu bauen braucht, verschwendet das falsche Feature eine Woche Engineering. Wenn das Feature 4 Stunden braucht, verschwendet das falsche einen halben Tag. Die Risikoprämie, die detaillierte Vorabplanung rechtfertigte, ist mit den Build-Kosten geschrumpft. Es ist jetzt billiger, zu shippen, zu lernen und zu iterieren, als in aufwendige Prognosen zu investieren.

Warum Sprint-Planung zerbricht

Diese Verschiebungen erzeugen spezifische Fehlermuster, die erfahrene Produktteams wiedererkennen.

• Story Points fühlen sich bedeutungslos an — "Klein/Mittel/Groß" für ein 4-Stunden-Feature zu schätzen ist Theater
• Velocity-Berechnungen werden absurd — Wenn Build-Zyklen je nach Prompt-Qualität um das 5-fache variieren, ist Velocity Rauschen statt Signal
• Sprint-Commitments komprimieren sich — Teams planen zweiwöchige Sprints und liefern den geplanten Scope in 3 Tagen, dann verschwenden sie Tage mit dem Warten auf das Sprint-Review
• Retros werden repetitiv — "Wir sind wieder zu früh fertig geworden" ist keine nützliche Erkenntnis
• Stakeholder-Planbarkeit wird überkalibriert — Eine Zweiwochenlieferung zu versprechen für etwas, das in 3 Tagen ausgeliefert wird, ist konservatives Theater
• Sprint-Zeremonien fressen die Zeitersparnis auf — Sprint-Planung, Daily Standups, Retros, Demos können 4–6 Stunden pro Woche und Person verschlingen — dieselben Stunden, die KI-App-Builder eingespart haben

Das Muster "Beschreiben und Launchen"

Was sich bei Produktteams zeigt, die KI-App-Builder in ihren Workflow aufgenommen haben.

Der Kernzyklus

1. Beschreiben — Ein knappes einseitiges PRD schreiben mit Ziel, Zielgruppe, Erfolgsmetriken und klaren Abnahmekriterien
2. Launchen — Über den KI-App-Builder bauen und deployen, oft in Stunden oder einem Tag
3. Messen — Echte Nutzer beobachten; Feedback sammeln; Nutzungsmetriken gegen Erfolgskriterien prüfen
4. Iterieren — Anpassen basierend auf dem Gelernten; die nächste Version ausliefern
5. Wiederholen — Der Zyklus läuft kontinuierlich, nicht in zweiwöchigen Sprint-Zyklen

Was er ersetzt

• Story-Point-Schätzung → ersetzt durch klare PRDs mit explizitem Scope
• Velocity-Berechnungen → ersetzt durch Shipping-Kadenz (Features pro Woche ausgeliefert)
• Sprint-Commitments → ersetzt durch eine wöchentlich aktualisierte Roadmap
• Daily Standups (manchmal) → ersetzt durch asynchrone Updates in gemeinsamen Kanälen
• Retros → ersetzt durch Post-Feature-Reviews, wenn spezifisch etwas schiefging

Was von der Sprint-Planung bleibt

Nicht alles, was Sprint-Planung löste, verschwindet. Mehrere Prinzipien bleiben wertvoll.

• Priorisierung — Immer nötig; braucht nur keine Story-Point-Schätzung mehr
• Stakeholder-Kommunikation — Läuft weiter, aber auf wöchentlicher statt Sprint-Granularität
• Team-übergreifende Koordination — Kritisch bei übergreifenden Änderungen; erreicht über asynchrone Koordination
• Aus Fehlern lernen — Bleibt wichtig; passiert direkt nach dem Fehler statt in zweiwöchigen Retrospektiven
• Roadmap-Klarheit — Bleibt wichtig; wöchentlich statt pro Sprint fixiert aktualisiert

Die PRD-Disziplin, die Schätzung ersetzt

Im Muster "Beschreiben und Launchen" entscheidet das PRD über Erfolg oder Misserfolg des Zyklus. Knappe PRDs shippen schnell; lose PRDs erfordern Iteration, die den Geschwindigkeitsgewinn zunichtemacht.

Was ein knappes PRD enthält

• Ziel — Ein Satz darüber, wie Erfolg aussieht
• Zielgruppe — Wer konkret profitiert
• Erfolgsmetriken — Quantitativ; woran man erkennt, dass es funktioniert hat
• User Stories oder Abnahmekriterien — Konkrete Szenarien, die das Feature abdecken muss
• Out of Scope — Was v1 explizit nicht enthält
• Design-Vibe — Visuelle Richtung (falls zutreffend)
• Technische Constraints — Datenbankänderungen, API-Integrationen, Security-Überlegungen
• Risikobereiche — Was schiefgehen könnte und besondere Aufmerksamkeit braucht

Was ein knappes PRD nicht enthält

• Story-Point-Schätzungen
• Sprint-Zuteilung oder Velocity-Berechnungen
• Vorhergesagtes Lieferdatum (der Fokus liegt auf Shippen, nicht auf Vorhersagen)
• Ausufernde Risikoanalysen (besser ausliefern und lernen, als endlos analysieren)

Ein gutes PRD passt auf eine Seite oder einen Screen. Längere PRDs haben meist unklares Denken, das die zusätzlichen Worte nicht beheben.

Kadenz: Wie "Beschreiben und Launchen" in der Praxis aussieht

Für Solo-Gründer

• Montag — 3–5 PRDs für die Features der Woche schreiben
• Dienstag–Donnerstag — Features bauen und ausliefern
• Freitag — Reviewen, was ausgeliefert wurde; Feedback von Nutzern sammeln
• Täglich — Asynchrone Updates bei Zusammenarbeit mit Co-Founder oder Freelancern

Für kleine Teams (2–5 Personen)

• Montag — Kurzes Alignment-Meeting (30 Min); Prioritäten für die Woche vereinbaren
• Täglich — Asynchrone Standups in Slack/Discord; kein synchrones Meeting
• Mitte der Woche — Pair-Review für Features, die ausgeliefert werden (15–30 Min nach Bedarf)
• Freitag — Demo-Session (60 Min); zeigen, was ausgeliefert wurde; Prioritäten für die nächste Woche vereinbaren

Für größere Teams (5+ Personen)

• Wöchentliche Planung ersetzt zweiwöchige Sprint-Planung
• Asynchrone Koordination zwischen Squads über gemeinsame Docs und Slack-Kanäle
• Kleinere, häufigere Demos statt zweiwöchentlicher Sprint-Reviews
• Roadmap wöchentlich statt pro Sprint fixiert aktualisiert

Häufige Einwände gegen "Beschreiben und Launchen"

"Ohne Schätzungen haben Stakeholder keine Planbarkeit mehr"

Planbarkeit kommt von der Shipping-Kadenz, nicht von der Schätzung. Ein Team, das zuverlässig 3 Features pro Woche ausliefert, ist planbarer als ein Team, das jedes Feature schätzt, aber 30 % der Sprints verpasst. Stakeholder interessieren sich für Lieferung, nicht für Schätzgenauigkeit.

"Wie managen wir technische Schulden ohne Sprint-Planung?"

Genauso: explizit priorisieren. Tech-Debt-Features durchlaufen PRDs und werden wie jede andere Arbeit ausgeliefert. Der Unterschied: keine "wir widmen 20 % der Sprint-Kapazität technischen Schulden"-Rituale mehr. Einfach priorisieren und ausliefern.

"Was ist mit komplexen Features, die nicht an einem Tag ausgeliefert werden können?"

Die gibt es weiterhin. Das Muster: in kleinere, ausliefer­bare Teile zerlegen (jedes mit eigenem PRD), oder ein mehrtägiges Projekt nutzen, aber den zweiwöchigen Sprint-Container weglassen. Projekte werden an der tatsächlichen Arbeit bemessen, nicht am Kalender.

"Wir brauchen Retros, um aus Fehlern zu lernen"

Aus Fehlern lernen, wenn sie passieren, nicht zwei Wochen später. Post-Mortems für konkrete Vorfälle bleiben wichtig; zweiwöchentliche Retros, die generisch fragen "was lief gut/was nicht" nicht. Ritual-Retros durch vorfallgetriebene Post-Mortems ersetzen.

"Velocity hilft uns, Kapazität zu prognostizieren"

Velocity machte Sinn, als Build-Zeit die dominante Variable bei der Feature-Lieferung war. Wenn KI-App-Builder Features in Stunden ausliefern, ist die dominante Variable Produktklarheit (wie klar das PRD ist) und Urteilsvermögen (welche Features wichtig sind). Velocity ist nicht mehr die richtige Einheit.

Was das für Engineers, PMs und Designer bedeutet

Engineers (im Zeitalter der KI-App-Builder)

• Weniger Coding von Grund auf; mehr Prompt-Design und Code-Review
• Engineering-Skill wird "PRDs in Prompt-Sequenzen übersetzen" neben traditionellem Engineering
• Architektur- und Härtungsarbeit bleibt genuines Engineering
• Karrierepfad zunehmend: Senior Engineers formen PRDs und reviewen KI-generierten Output

Produktmanager

• PRD-Schreiben ist der zentrale Skill
• Weniger Zeit in Sprint-Zeremonien; mehr Zeit mit Kunden
• Priorisierung ist konstant statt pro Sprint
• Direkte Beteiligung an Shipping-Entscheidungen; weniger Warten auf Engineering-Kapazität

Designer

• Design-Vibes werden vorab in PRDs festgelegt
• Iteration auf Visuals über Prompts, parallel zur Engineering-Iteration
• Mehr Designs werden ausgeliefert; weniger Designs liegen in Figma und warten auf Engineering-Kapazität
• Design-System-Denken wird wichtiger — konsistente Vibes über viele schnell ausgelieferte Features hinweg

Der Übergangspfad für etablierte Teams

Bestehende Teams, die Sprint-Planung nutzen, wechseln nicht über Nacht. Der Übergang sieht typischerweise so aus.

• Monat 1 — Ein Squad auf "Beschreiben und Launchen" pilotieren; andere bei Sprint-Planung belassen
• Monat 2–3 — Kadenz und Ergebnisse vergleichen; das Muster verfeinern
• Monat 3–6 — Auf mehr Squads ausweiten; Sprint-Planung nur für spezifisch langsame Build-Zyklen beibehalten
• Monat 6+ — Sprint-Planung wird zur Ausnahme, nicht zum Standard
• Laufend — Kontinuierlich bewerten, ob Zeremonien Wert schaffen oder die Zeitersparnis der KI-App-Builder auffressen

Wann Sprint-Planung weiterhin sinnvoll ist

Das Muster ist nicht "Sprint-Planung ist tot." Es ist "Sprint-Planung passt zu einer bestimmten Art Arbeit." Fälle, in denen Sprints weiterhin Sinn ergeben:

• Große Engineering-Teams mit hohem Koordinationsoverhead
• Komplexe Backend- oder Systemarbeit, deren Build-Zyklen sich nicht so stark komprimiert haben
• Compliance-regulierte Umgebungen, in denen formale Schätzung für Audits wichtig ist
• Team-übergreifende Abhängigkeiten, die explizite Synchronisation brauchen
• Teams mit Stakeholdern, die traditionelle Reporting-Strukturen verlangen

Für die meisten Produktteams, die KI-gebaute oder vibe-gecodete Anwendungen ausliefern, passt das neue Muster besser. Für traditionelle Engineering-Teams auf Legacy-Stacks bleiben Sprints eine vernünftige Wahl.

Häufige Fehler beim Übergang von Sprints weg

• Sprints wegwerfen, ohne die Struktur zu ersetzen — Manche Teams entfernen Zeremonien und verlieren die Koordination komplett. Das neue Muster hat Struktur; sie ist nur anders.
• PRDs überspringen — Ohne knappe PRDs wird "Beschreiben und Launchen" zu "shippen, was sich richtig anfühlt." Das scheitert.
• Den PM-Workload unterschätzen — PRDs sind das neue zentrale PM-Artefakt. PMs, die keine knappen PRDs schreiben können, tun sich schwer.
• Es als "kein Prozess" behandeln — Das Muster hat Disziplin; sie ist nur in PRDs vorverlagert statt über Sprint-Zeremonien verteilt.
• Team-Buy-in ignorieren — Teams, die mit der neuen Kadenz unwohl sind, setzen sie nicht gut um. Den Übergang coachen.
• Stakeholder-Aufklärung überspringen — Stakeholder, die auf Sprint-Reviews trainiert sind, brauchen neue Wege, um Fortschritt zu verfolgen.
• Nicht bewahren, was funktioniert — Manche Sprint-Zeremonien (Demos, Retros für Vorfälle) sind genuin nützlich. Die behalten; nur weglassen, was keinen Wert schafft.
• Versuchen, alles schnell auszuliefern — Manche Features brauchen genuin mehrtägige Arbeit. "Beschreiben und Launchen" heißt nicht, dass alles an einem Tag ausgeliefert wird — es heißt, dass es keinen künstlichen Zweiwochen-Container gibt.

Häufig gestellte Fragen

F1: Stirbt Sprint-Planung wirklich oder ist das nur Hype? Beides. Für Teams, die KI-App-Builder intensiv nutzen, ist der Wandel real und bedeutsam. Für Teams auf Legacy-Stacks bleibt Sprint-Planung nützlich. Der branchenweite Wandel ist graduell und ungleichmäßig; die Vorreiterteams arbeiten bereits anders.

F2: Wie überzeuge ich mein Team, das auszuprobieren? Ein Squad einen Monat lang pilotieren. Messen: ausgelieferte Features, Kundenfeedback, Teamzufriedenheit. Wenn die Ergebnisse besser werden, ausweiten. Wenn nicht, lernen, was nicht funktioniert hat. Den Wandel nicht ohne Belege top-down verordnen.

F3: Was ist mit Engineering-Teams, die keine KI-App-Builder nutzen? Sprint-Planung passt für sie möglicherweise weiterhin gut. Die Musterverschiebung wird durch Build-Zyklus-Kompression getrieben. Ohne diese Kompression hat sich die Rechnung nicht geändert, und Sprints ergeben weiterhin Sinn.

F4: Wie messe ich Produktivität ohne Velocity? Ausgelieferte Features pro Woche. Kundenzufriedenheitswerte. Umsatzwirkung ausgelieferter Features. Zykluszeit von der Idee bis zur Auslieferung. Das sind echte Produktivitätsmetriken; Velocity war ein Proxy, der nicht mehr nötig ist.

F5: Braucht das speziell KI-App-Builder? Größtenteils ja. Die Kompression, die Sprint-Planung zerbricht, wird von KI-App-Buildern getrieben. Teams, die im traditionellen Engineering-Tempo ausliefern, sehen nicht denselben Vorteil davon, Sprint-Zeremonien zu überspringen.

F6: Was ist mit compliance-reguliertem Bereichen (Gesundheitswesen, Finanzen)? Oft weiterhin traditionelle Sprint-Planung nötig für Audit und Risikomanagement. Das neue Muster funktioniert für die nicht-regulierten Schichten; regulierte Schichten behalten mehr Struktur.

F7: Ist das nur umbenanntes "Kanban"? Es gibt Überschneidungen, aber es ist nicht identisch. Kanban ist kontinuierlicher Flow ohne Iterationsgrenzen. "Beschreiben und Launchen" fügt explizite PRDs als Arbeitseinheit hinzu und betont den Geschwindigkeitsvorteil von KI-App-Buildern. Im Geiste näher an Kanban als an Scrum, aber streng genommen keins von beiden.

Fazit

• Sprint-Planung entstand, als Build-Zyklen Wochen dauerten. KI-App-Builder haben diese Zyklen auf Stunden oder Tage komprimiert. Der Schätzaufwand übersteigt jetzt den Wert, den er schafft.
• "Beschreiben und Launchen" ist das aufkommende Muster. Ein knappes PRD schreiben; das Feature ausliefern; messen; iterieren. Weniger Zeremonie, mehr Shipping. Kontinuierlich statt in Zweiwochenzyklen.
• PRD-Schreiben wird zum zentralen PM-Skill. Knappe PRDs shippen schnell; lose PRDs erfordern Iteration, die den Geschwindigkeitsgewinn zunichtemacht. Die Disziplin verschiebt sich von Schätzung zu Spezifikation.
• Sprint-Planung passt weiterhin in bestimmten Fällen — große koordinierte Teams, Legacy-Stacks, regulierte Umgebungen. Für die meisten Produktteams, die KI-gebaute Apps ausliefern, passt das neue Muster besser.

Ein Squad auswählen. "Beschreiben und Launchen" einen Monat lang pilotieren. Messen, was ausgeliefert wurde und was die Kunden tatsächlich bekommen haben. Wenn das Muster funktioniert, ausweiten. Die Methodik, die zu langsamen Build-Zyklen passte, muss nicht für immer die Methodik bleiben. Produktteams im Zeitalter der KI-App-Builder können mehr ausliefern, schneller lernen und weniger Zeit mit Zeremonien verschwenden, die für eine andere operative Realität entworfen wurden. Der strukturelle Wandel ist real; die Teams, die ihn früh aufnehmen, bekommen den kumulierenden Vorteil.