Agile Praxis im KI-Zeitalter: Was sich für Scrum und Kanban wirklich ändert
Wie sich Sprint Planning, Refinement, Retros, Definition of Done und WIP-Limits ändern, wenn KI-gestützte Entwicklung zum Standard wird – und wo neue Engpässe entstehen.
KI macht Agilität nicht überflüssig, zwingt die Praktiken aber zur Anpassung. Die spannende Frage ist selten „ersetzt KI Scrum?“, sondern: Wo verschieben sich Engpässe, welche Rituale bleiben wertvoll, welche brauchen ein Update? Ein Durchgang durch die Kernelemente aus PO- und Team-Perspektive.
Sprint Planning: Schätzungen unter neuen Vorzeichen
Story-Point-Schätzungen basieren häufig noch auf mentalen Modellen aus einer Zeit ohne KI. Teams unterschätzen konsistent, was tatsächlich möglich ist – oder überschätzen es, wenn sie unkritisch auf KI-Output zählen. Beide Fehler sind teuer, nur anders.
Hilfreich ist, die Schätzung zu zerlegen: Wie viel Aufwand steckt im Verstehen, wie viel in der Umsetzung, wie viel im Review, wie viel in Tests und Integration? KI verschiebt vor allem den Umsetzungsanteil; die anderen bleiben oder wachsen. Velocity als eine Zahl verliert diese Differenzierung – ein Blick auf Durchlaufzeit pro Story-Klasse ist ehrlicher.
Für Planning heißt das: weniger Vertrauen in „so viel schaffen wir immer“, mehr in „so lange dauert Verstehen, Bauen und Review für Storys dieser Art“.
Refinement: KI hilft strukturieren, nicht verstehen
Ein Assistent strukturiert Stories vor, schlägt Akzeptanzkriterien vor, wirft offene Fragen auf. Das spart Zeit im Vor-Refinement. Nicht ersetzbar ist die eigentliche Klärung: gemeinsames Verstehen im Team, Edge-Cases herausarbeiten, technische Optionen mit fachlicher Priorität abgleichen.
Refinements werden dadurch kürzer, dichter, inhaltlich fokussierter. Vorbereitung wird wichtiger, weil weniger im Meeting selbst „erdacht“ wird. Und der PO verschiebt sich Richtung Kurator – jemand, der KI-Vorschläge einordnet, ergänzt und den Fokus auf die wichtigen Fragen lenkt.
Retrospektiven: Neue Reflexionsfragen
Retros bekommen neue Themen. Wo hat KI in diesem Sprint wirklich geholfen? Wo hat sie Zeit gekostet, weil ein plausibler, aber falscher Vorschlag mühsam wieder aus dem Code gezogen wurde? Wo entstand Reibung, weil Team-Mitglieder unterschiedlich intensiv mit KI arbeiten und Erwartungen kollidieren?
Teamdynamik ist ein unterschätztes Thema. Wenn eine Person mit KI-Unterstützung sichtbar mehr Storys durchdrückt, während andere klassischer arbeiten, entstehen Wahrnehmungslücken – „warum ist das bei mir langsamer?“, „warum wird über meine Qualität mehr diskutiert als über die Menge der anderen?“. Das offen anzusprechen ist Retro-Arbeit im besten Sinne.
Eine nützliche Standardfrage: Haben wir in diesem Sprint blind KI-Vorschläge übernommen, die uns später beißen könnten? Klingt harmlos, verhindert viele stille Baustellen.
Definition of Done: KI-spezifische Prüfpunkte
Wenn KI Code produziert, muss die Definition of Done konsequent bleiben: Qualität zählt, nicht Herkunft. Punkte, die früher „selbstverständlich“ waren, brauchen jetzt oft explizite Formulierung. Wurde der generierte Code verstanden? Sind Tests aussagekräftig oder nur syntaktisch grün? Wurden Sicherheitsaspekte, Rate-Limits und Fehlerpfade beachtet, die ein Modell gern ignoriert?
Manche Teams ergänzen ihre DoD um einen Punkt wie „KI-generierter Code wurde mindestens einmal durch eine Person gelesen und in seinen Konsequenzen bewertet“. Klingt banal, verhindert aber die Kategorie Fehler, die entsteht, wenn Vorschläge durchgewinkt werden, weil „es ja compiliert“.
Kanban und WIP: Engpässe wandern
Der wichtigste strukturelle Effekt: Schnellere Entwicklung verschiebt den Engpass, häufig Richtung Review, QA, Freigaben oder Deployment. Ein Team, das ohne Anpassung schneller entwickelt, produziert vor allem mehr Tickets im Review-Status – nicht mehr Wert im Produkt.
Für Kanban heißt das: WIP-Limits gehören neu justiert. Wo früher „In Umsetzung“ der Flaschenhals war, ist es heute oft „In Review“ oder „Auf Freigabe wartend“. Wer diese Spalten nicht aktiv managt, verlagert Wartezeit an eine andere Stelle im Wertstrom.
Auch QA verändert sich. Wird Code schneller produziert als klassisch geprüft werden kann, muss QA früher einsteigen. Testautomatisierung wird kritischer, exploratives Testen bleibt wichtig, aber wird gezielter eingesetzt. Sonst hat man ein Team, das schneller liefert – und langsamer freigibt.
Scrum Master und Coaching-Fokus
Der Fokus des Scrum Masters verschiebt sich. Klassisch: Impediments beseitigen, Prozess reflektieren, Team befähigen. Neu: gesunder Umgang mit KI-Tools. Wie verhindern wir zwei Klassen von Team-Mitgliedern – solche, die KI intensiv nutzen, und solche, die sie meiden? Wie stoppen wir „die KI hat es so vorgeschlagen“ als Ausrede für unklare Anforderungen?
Balance zwischen Geschwindigkeit und Reflexion. KI verführt zu „lass uns schnell noch was probieren“. Ohne bewusste Pausen, kritische Reviews und strukturierte Retros entsteht Aktivismus ohne Erkenntnis – der Klassiker „viel geliefert, wenig verstanden“.
Fazit
KI ersetzt agile Praxis nicht. Sie muss aber nachjustiert werden: andere Modelle im Planning, dichtere Refinements, neue Standardfragen in Retros, explizitere Definition of Done, neu ausgesteuerte WIP-Limits und andere Schwerpunkte im Scrum-Master-Handwerk. Der Engpass wandert von reiner Entwicklungsgeschwindigkeit zu Entscheidungsqualität, Review und Freigabe. Wer diese Verschiebung ignoriert, verliert die Effekte, die KI überhaupt erst möglich macht.