Scrum wurde für Menschen entwickelt. Für Teams aus fünf bis neun Personen, die gemeinsam an einem Produkt arbeiten, Entscheidungen aushandeln und in Sprints iterativ Wert liefern. Doch was passiert, wenn ein wesentlicher Teil dieser Arbeit plötzlich von KI-Systemen übernommen wird — von Copiloten, die Code generieren, von LLMs, die Anforderungen formulieren, von autonomen Agenten, die Tasks abarbeiten? Dann ist Scrum nicht obsolet. Aber es muss neu kalibriert werden. Wer das ignoriert, riskiert, agile Rituale als leere Hülle weiterzuführen — ohne die Substanz, die sie ursprünglich stark gemacht hat.
Wenn der Sprint-Rhythmus auf KI-Tempo trifft
Das klassische Scrum-Modell basiert auf einem fundamentalen Prinzip: Die Liefergeschwindigkeit ist durch menschliche Kapazität begrenzt. Zwei Wochen Sprint, acht Story Points, Yesterday's Weather — das gesamte Planungsmodell setzt voraus, dass Arbeit Zeit braucht. KI-gestützte Entwicklung bricht diese Annahme auf.
Teams, die GitHub Copilot oder ähnliche Tools produktiv einsetzen, berichten von Produktivitätssteigerungen zwischen 30 und 55 Prozent bei repetitiven Coding-Tasks — je nach Kontext und Komplexität. McKinsey beziffert in einer 2023 veröffentlichten Studie den Produktivitätsgewinn durch KI-Assistenz im Software Engineering auf bis zu 45 Prozent. Was bedeutet das für den Sprint? Wenn ein Team in zwei Wochen plötzlich doppelt so viel Code produzieren kann, kollabiert die Velocity als Planungsinstrument. Story Points, die auf historischen Schätzungen basieren, verlieren ihre Aussagekraft.
Ein konkretes Beispiel: Ein Entwicklungsteam bei einem deutschen Fintech-Unternehmen — vierzig Entwickler, skaliertes Scrum nach SAFe — stellte fest, dass ihre KI-gestützten Teams nach sechs Monaten eine Velocity hatten, die dreimal über dem historischen Durchschnitt lag. Die Konsequenz: Sprint Planning kollabierte, weil niemand mehr sinnvoll schätzen konnte. Backlog Refinement wurde zur Farce, weil die Unsicherheit nicht mehr in Arbeitsstunden, sondern in Prompt-Qualität und Modellverhalten lag.
Die Lösung des Teams war pragmatisch: Sie entkoppelten Schätzung von Kapazitätsplanung. Anstatt Story Points auf Arbeitsstunden zu mappen, begannen sie, Komplexität und Unsicherheit als separate Dimensionen zu bewerten — eine Anlehnung an das #NoEstimates-Prinzip, kombiniert mit expliziten KI-Risiko-Tags im Backlog. Teams, die in ähnlichen Kontexten arbeiten, sollten diese Entkopplung aktiv in ihr Sprint-Planning integrieren: Frage nicht mehr "Wie lange dauert das?", sondern "Wie hoch ist die Unsicherheit — und kommt sie aus dem Problem oder aus der KI-Lösung?"
Definition of Done in der KI-Ära: Wer prüft, was die Maschine gebaut hat?
Das vielleicht unterschätzte Problem liegt nicht in der Geschwindigkeit, sondern in der Qualitätssicherung. Die Definition of Done war immer ein kollektives Versprechen des Teams: Dieser Increment ist fertig, getestet, deploybar. Doch wenn wesentliche Teile des Codes von einem KI-System generiert wurden, stellen sich neue Fragen — und die meisten Scrum-Teams haben noch keine Antworten darauf.
KI-generierter Code ist nicht per se schlechter als menschlich geschriebener. Aber er trägt andere Risiken: subtile logische Fehler, Halluzinationen in Edge Cases, Sicherheitslücken, die ein erfahrener Entwickler intuitiv vermieden hätte. Eine Studie der Stanford University aus dem Jahr 2022 zeigte, dass Entwickler, die mit KI-Assistenz arbeiteten, signifikant häufiger unsicheren Code produzierten — nicht wegen mangelnder Kompetenz, sondern wegen eines Phänomens, das die Forscher als "automation bias" bezeichnen: Das Vertrauen in die KI-Ausgabe senkt die kritische Prüfbereitschaft.
Was bedeutet das für die Definition of Done? Sie muss KI-spezifische Qualitätsgates integrieren. Das ist kein theoretisches Konzept — Teams wie das Platform Engineering Team von ING Netherlands haben ihre DoD um explizite Punkte erweitert: "KI-generierte Codeabschnitte wurden einem Peer Review durch einen Senior Developer unterzogen", "Prompts und KI-Outputs sind im Commit dokumentiert", "Security Scan wurde explizit auf LLM-generierte Abschnitte angewendet."
Dieser Ansatz hat einen Nebeneffekt, der für Scrum Master und Coaches besonders relevant ist: Er macht KI-Nutzung im Team sichtbar und diskutierbar. Transparency — eines der drei Scrum-Pillar — wird dadurch nicht ausgehöhlt, sondern auf ein neues Niveau gehoben. Die DoD wird zum Spiegel, der zeigt, wie das Team tatsächlich arbeitet, nicht wie es glaubt zu arbeiten.
Sofortiger Handlungsimpuls: Organisiert in eurem nächsten Sprint Review eine explizite Retrospektive eurer Definition of Done. Fragt euch: Welche unserer Done-Kriterien setzen stillschweigend voraus, dass ein Mensch die Arbeit geleistet hat? Markiert diese Kriterien — und entscheidet bewusst, ob ihr sie anpasst, erweitert oder ersetzt.
Product Ownership neu denken: Vom Anforderungsschreiber zum Intent-Designer
Die Rolle des Product Owners steht in KI-Entwicklungskontexten vor einer fundamentalen Verschiebung — und viele POs haben das noch nicht internalisiert. Klassisch formuliert der PO User Stories, priorisiert das Backlog und ist der primäre Ansprechpartner für Stakeholder. In einer Welt, in der LLMs aus wenigen Zeilen Kontext vollständige Anforderungsdokumente, Akzeptanzkriterien und sogar initiale Designs generieren können, ändert sich die Kernaufgabe.
Die gefährliche Versuchung: POs delegieren die Anforderungsformulierung an KI-Tools und verlieren dabei das Wesentliche — den tiefes Verständnis des Problems hinter der Anforderung. Ein Prompt kann keine Stakeholder-Interviews ersetzen. Kein LLM versteht die impliziten Geschäftsregeln, die ein langjähriger PO in fünf Jahren aufgebaut hat.
Was sich hingegen verschiebt, ist die Art der Wertschöpfung. Der PO der Zukunft ist weniger Anforderungs-Autor als Intent-Designer: Er formuliert präzise, was das System erreichen soll — nicht wie es implementiert werden soll. Diese Fähigkeit, Absicht klar und kontextreich zu kommunizieren, wird zur Kernkompetenz. Denn ein gut formulierter Intent ist der Input, aus dem KI-Systeme maximalen Wert schöpfen können.
Das Team von Spotify hat dieses Prinzip — wenn auch nicht unter diesem Label — bereits gelebt: "We tell the system what we want to achieve, not how to achieve it." Im KI-Kontext bedeutet das: Der PO muss lernen, mit Prompts, mit Kontext-Dokumenten und mit KI-generierten Prototypen umzugehen, ohne dabei die strategische Perspektive an die Maschine abzugeben.
Für Agile Coaches bedeutet das konkret: Product Owner Coaching muss die Dimension "KI-Kompetenz" integrieren. Nicht als technisches Training, sondern als Reflexionsarbeit: Wo setzt du KI ein, um schneller zu werden — und wo verarmst du dabei dein Produktverständnis?
Retrospektiven als Lernorte für Mensch-KI-Kollaboration
Wenn ein Scrum-Team KI-Tools produktiv einsetzt, ohne explizit über die Zusammenarbeit zwischen Mensch und Maschine zu reflektieren, verschenkt es das stärkste Lerninstrument, das Scrum bietet: die Retrospektive. In der Praxis passiert genau das häufig. KI-Tools werden eingeführt wie neue Software-Libraries — still, ohne Team-Diskussion, ohne gemeinsame Normen.
Eine Retrospektive, die Mensch-KI-Kollaboration zum Thema macht, braucht angepasste Formate. Das klassische "Start, Stop, Continue" greift zu kurz, weil es auf individuelles Verhalten zielt. Was Teams brauchen, sind Formate, die kollektive Lernmuster sichtbar machen. Ein bewährter Ansatz aus der Praxis: das "AI Working Agreement Review" als regulärer Bestandteil der Retro, quartalsweise oder nach größeren Iterationen.
Ein Entwicklungsteam bei einem mittelgroßen deutschen SaaS-Anbieter führte nach sechs Monaten mit KI-Tools eine strukturierte "AI Retrospective" durch — vier Stunden, moderiert von einem externen Agile Coach. Das Ergebnis: Das Team identifizierte drei Muster, die die Zusammenarbeit systematisch untergruben. Erstens: Entwickler nutzten KI für Aufgaben, bei denen sie selbst lernten — und verloren dadurch Kompetenz-Aufbau. Zweitens: Niemand hatte explizit definiert, bei welchen Entscheidungen KI-Output direkt übernommen werden darf und bei welchen zwingend ein Mensch urteilen muss. Drittens: Das Fehlen gemeinsamer Prompt-Standards führte zu massiv unterschiedlicher Output-Qualität im Team.
Diese drei Erkenntnisse führten zu handhabbaren Team-Agreements, die in den normalen Scrum-Prozess integriert wurden — nicht als Bürokratie, sondern als kollektive Intelligenz des Teams über die eigene Arbeitsweise.
Sofortiger Handlungsimpuls: Plant für eure nächste Retrospektive eine explizite Sequenz von zwanzig Minuten zum Thema KI-Nutzung im Sprint. Drei Leitfragen: Wo hat KI uns schneller gemacht — und was haben wir dabei nicht gelernt? Wo hat KI-Output unsere kritische Urteilsfähigkeit reduziert? Welche impliziten Regeln für KI-Nutzung haben wir — und sollten wir sie explizit machen?
Scrum ist kein Fossil — es ist ein Framework, das auf empirischer Prozesssteuerung basiert. Genau diese Grundlage macht es anpassungsfähig für die KI-Ära. Aber die Anpassung passiert nicht von selbst. Sie erfordert Teams und Coaches, die bereit sind, ihre Annahmen offenzulegen: Was in unserem Scrum-Prozess setzt stillschweigend voraus, dass Menschen die Arbeit leisten? Was verlieren wir, wenn wir diese Annahme aufgeben — und was gewinnen wir?
Die Kernbotschaft ist klar: KI verändert nicht, ob Scrum funktioniert. KI verändert, worüber Scrum-Teams bewusst entscheiden müssen. Velocity, Definition of Done, Product Ownership, Retrospektiven — all das sind keine unveränderlichen Wahrheiten, sondern Werkzeuge. Und Werkzeuge müssen für den Kontext geschärft werden, in dem sie eingesetzt werden. Teams, die das jetzt tun, werden in zwei Jahren nicht KI integriert haben. Sie werden KI-nativ sein.
