Agile für AI

Context

Sprint Planning, Montag morgens. Dein Team schaetzt Stories für den nächsten Sprint. “AI-Zusammenfassung optimieren” steht im Backlog. Der ML-Engineer sagt: “Kann ich nicht schätzen. Vielleicht dauert es einen Tag, vielleicht zwei Wochen. Haengt davon ab, ob der neue Prompt-Ansatz funktioniert.” Der Scrum Master will Story Points. Der Engineer weigert sich.

Klassisches Agile nimmt an, dass Arbeit schaetzbar ist und Fortschritt ungefaehr linear verlaeuft. AI-Entwicklung bricht beide Annahmen. Experimente haben unvorhersehbare Ergebnisse. Qualität kann ploetzlich stagnieren oder zurueckfallen. “Definition of Done” ist bei probabilistischen Systemen nicht binaer.

Das heisst nicht, dass Agile für AI nutzlos ist — es heisst, dass es angepasst werden muss.

Concept

Warum klassisches Agile nicht direkt funktioniert

Agile-Annahme	AI-Realität
Stories sind schaetzbar	AI-Experimente haben unvorhersehbare Ergebnisse
Fortschritt ist inkrementell	AI-Qualität kann stagnieren oder ploetzlich zurueckfallen
Definition of Done ist klar	”Gut genug” ist subjektiv und verschiebt sich
Sprints produzieren shippable Increments	AI-Prototypen können beweisen, dass ein Ansatz nicht machbar ist
Velocity stabilisiert sich	AI-Entwicklungsgeschwindigkeit ist inhaerent variabel

Der Dual-Track-Ansatz

Track 1: Exploration (Forschung/Experimente)

Timeboxed Experiments: “Können wir Qualität X mit Ansatz Y in Z Wochen erreichen?”
Outcome: Machbarkeitsassessment, nicht shippable Feature
Nicht in Story Points schaetzbar — stattdessen Timebox-Budgets
Kill-Kriterien vorab definieren: Wann wird ein Ansatz aufgegeben?

Track 2: Production (Bauen/Shippen)

Hier funktioniert klassisches Agile: Integration, UI, Infrastruktur, Deployment
Schaetzbar, inkrementell, sprintfaehig
Standard Velocity Tracking

Beide Tracks parallel laufen lassen ist der Schluessel. Waehrend Track 1 exploriert, ob ein neues Modell die Qualität verbessert, baut Track 2 die Produktionsinfrastruktur für den aktuellen Ansatz.

Sprint-Zeremonien angepasst

Sprint Planning:

AI-Experimente und Produktionsarbeit im Backlog trennen
Experimente bekommen Timeboxes, nicht Story Points: “2 Tage für Ansatz A, 3 Tage für Ansatz B”
Regel: Nicht mehr als 30% Sprint-Kapazitaet für Experimente (ausser in der fruehen Exploration)

Daily Standup:

“Experiment Status” zum Standup-Format hinzufuegen
Experimente, die nach ihrer Timebox keine Ergebnisse zeigen, eskalieren — nicht still verlaengern

Sprint Review:

Experimente mit Daten demonstrieren, nicht mit Meinungen: “Ansatz A erreicht 82% Accuracy auf dem Eval Set, Ansatz B 71%. Ansatz A addiert 200ms Latency. Empfehlung: Ansatz A mit Optimierung.”

Retrospektive:

Hinzufuegen: “Was haben wir gelernt, das wir nicht erwartet haben?”
Kill-Entscheidungen reviewen: Haben wir Ansaetze zu frueh oder zu spaet aufgegeben?

Schaetzungsstrategien

Für Exploration/Experiment-Arbeit:

NICHT in Story Points schätzen — das erzeugt falsche Praezision
Timeboxes nutzen: “Wir investieren 3 Tage in Ansatz X”
Klare Erfolgs-/Misserfolgs-Kriterien vorher definieren: “Wenn Accuracy nach 3 Tagen unter 75%, pivoten wir”
Budget: 20-30% der Teamkapazitaet für Experimente

Für Production/Integration-Arbeit:

Standard Story Points funktionieren
“Eval Infrastructure” Stories explizit einplanen — wird chronisch unterschaetzt
“Prompt Engineering” Stories explizit einplanen — ist echte Arbeit, nicht “nur Text tweaken”

Das Experiment-Spike-Pattern

Frage definieren: “Kann Modell X mehr als 85% Accuracy bei unserer Zusammenfassungsaufgabe erreichen?”
Timebox setzen: 2-5 Tage
Eval definieren: Bestehendes Eval-Dataset oder minimales neues erstellen
Experiment durchführen: Prototyp, Evaluierung, Dokumentation
Zurueckberichten: Metriken, Learnings, Empfehlung (Weitermachen/Pivoten/Aufgeben)
Decision Gate: PM + Tech Lead entscheiden nächsten Schritt

Framework

Wie AI-Entwicklung strukturieren — nach Reifegrad:

Reifegrad	Exploration	Production	Timebox-Regel
Frueh (erstes AI-Feature)	60%	40% (Infrastruktur)	Experiment max. 1 Woche
Mittel (AI-Feature validiert)	30%	70%	Experiment max. 5 Tage
Reif (AI-Feature in Produktion)	20%	80% (Optimierung)	Experiment max. 3 Tage

Immer: Experiment-Arbeit von Produktionsarbeit im Planning trennen. Kill-Kriterien vor Start definieren. Timeboxen, nie Open-ended Exploration.

Scenario

Du bist PM eines AI-Produktteams. Euer AI-Feature (Dokumentenzusammenfassung) ist seit 3 Monaten in Produktion. Die Accuracy liegt bei 79% — euer Ziel ist 85%.

Sprint-Situation:

2-Wochen-Sprint, Team von 4 Engineers + 1 ML-Engineer
Backlog: 3 Bug Fixes (Production), 1 neues Feature (User Feedback UI), 2 Improvement-Ideen (neuer Prompt-Ansatz, alternatives Chunking)
Der ML-Engineer will beide Improvement-Ideen im nächsten Sprint ausprobieren
Der Engineering Lead sagt: “Wir müssen die Bugs fixen und das Feature-UI bauen. Kein Platz für Experimente.”
Der Scrum Master fragt: “Wie viele Story Points sind die Improvements?”

Decide

Wie wuerdest Du entscheiden?

Die beste Entscheidung: Dual-Track anwenden. Bugs und Feature-UI auf Track 2 (Production). Ein Experiment auf Track 1 (Exploration) — nicht beide.

Konkrete Sprint-Planung:

70% Production: 3 Bug Fixes + User Feedback UI (4 Engineers)
30% Exploration: 1 Experiment, timeboxed auf 3 Tage (ML-Engineer)
Welches Experiment zuerst? Neuer Prompt-Ansatz — guenstigerer Aufwand, schnelleres Feedback. Alternatives Chunking ist aufwaendiger und kommt im nächsten Sprint
Kill-Kriterium: Wenn der neue Prompt nach 3 Tagen nicht mindestens 82% Accuracy erreicht (Halbweg zum Ziel), pivoten

Zum Scrum Master: “Experiments bekommen keine Story Points. Der ML-Engineer hat ein 3-Tage-Timebox-Budget. Ergebnis kann sein: ‘funktioniert’, ‘funktioniert nicht’ oder ‘braucht mehr Daten’. Alles davon ist ein valides Ergebnis.”

Was viele falsch machen: Entweder alle Experimente auf einmal starten (Kapazitaet ueberlastet) oder Experimente komplett aufschieben bis “wir Zeit haben” (kommt nie).

Reflect

Agile ist nicht kaputt für AI — es braucht den Dual-Track: Exploration timeboxed, Production wie gewohnt.

AI-Experimente in Story Points zu schätzen erzeugt falsche Praezision und Frustration
Die Zwei-Wochen-Regel: Wenn zwei Wochen Experimentation nicht 70% der Zielqualitaet erreichen, muss der Ansatz hinterfragt werden
“Wir haben bewiesen, dass es nicht funktioniert” ist ein valides und wertvolles Sprint-Ergebnis

Quellen: Spotify Engineering Blog — ML Delivery Framework, Google AI Development Stage-Gate Process (Engineering Talks), Practitioner Pattern “Two-Week Rule”