Agentic AI im Scrum-Team: Brauchen wir eine Definition of Done für KI-generierte Arbeit?

Wenn KI-Agenten Sprint-Aufgaben übernehmen, verändert sich die Teamdynamik. Was das für Scrum Master, Qualitätssicherung und agile Zusammenarbeit bedeutet.

Stell dir folgende Situation vor: Montagmorgen, Sprint Planning. Dein Team sitzt zusammen, der Product Owner priorisiert das Backlog, die Entwickler schätzen den Aufwand. Alles wie immer. Nur dass einer der “Entwickler” kein Mensch ist. Er hat kein Kaffeetasse auf dem Tisch, keinen Slack-Status und keinen schlechten Tag. Aber er wird in den nächsten zwei Wochen Code schreiben, Tests ausführen und Pull Requests erstellen. Willkommen in der Realität von 2026.

Was bis vor kurzem nach Science-Fiction klang, passiert gerade in Entwicklungsteams weltweit. Nicht als Experiment, nicht als Demo, sondern im produktiven Sprint. KI-Agenten übernehmen Aufgaben, die bisher Junior Developers, QA-Engineers oder Data Analysts erledigten. Und sie tun das nicht, weil jemand ihnen einen Prompt gibt und auf eine Antwort wartet. Sie tun es autonom.

Agentic AI verändert Scrum-Teams: KI-Agenten übernehmen Sprint-Aufgaben. Wie Scrum Master hybride Teams führen und eine Definition of Done für KI-Arbeit gestalten.

Vom Chatbot zum Teamkollegen: Was Agentic AI von bisheriger KI unterscheidet

Der Unterschied klingt subtil, verändert aber alles. Generative KI, wie wir sie seit ChatGPT kennen, reagiert. Du stellst eine Frage, du bekommst eine Antwort. Du gibst einen Auftrag, du erhältst ein Ergebnis. Die Interaktion ist transaktional: Mensch fragt, Maschine antwortet, fertig.

Agentic AI funktioniert anders. Ein KI-Agent plant, entscheidet und handelt in mehreren Schritten. Er zerlegt ein komplexes Ziel in Teilaufgaben, wählt die passenden Werkzeuge, führt die Arbeit aus, prüft das Ergebnis und passt seinen Ansatz an, wenn etwas nicht funktioniert. Dabei greift er auf externe Systeme zu: Datenbanken, APIs, Entwicklungsumgebungen, Projektmanagement-Tools. Er wartet nicht auf deinen nächsten Prompt. Er arbeitet.

Deloitte bringt es auf den Punkt: Organisationen beginnen, KI-Agenten als “siliziumbasierte Belegschaft” zu betrachten, die menschliche Teams ergänzt. Das ist kein Marketing-Slogan. Es beschreibt eine Verschiebung in der Art, wie Unternehmen über Arbeit und Arbeitskraft nachdenken.

Die Zahlen belegen diese Verschiebung. Gartner verzeichnet zwischen dem ersten Quartal 2024 und dem zweiten Quartal 2025 einen Anstieg von 1’445 Prozent bei Anfragen zu Multi-Agent-Systemen. Bis Ende 2026 sollen laut Gartner rund 40 Prozent aller Enterprise-Anwendungen KI-Agenten einbetten. Gleichzeitig zeigt Deloittes Emerging Technology Trends Study, wie gross die Lücke zwischen Ambition und Umsetzung ist: 30 Prozent der befragten Organisationen explorieren Agentic AI, 38 Prozent pilotieren. Aber nur 11 Prozent setzen solche Systeme produktiv ein.

Was bedeutet das konkret für ein Scrum-Team?

Es bedeutet, dass einzelne, spezialisierte Agenten bestimmte Rollen im Team übernehmen können. Nicht die Rolle des Architekten, der Designentscheidungen mit Weitblick trifft. Nicht die Rolle des Product Owners, der versteht, was Kunden brauchen. Sondern die klar umrissenen, wiederholbaren Aufgaben, die in jedem Sprint anfallen.

Erste Frameworks machen diese Vision greifbar. BMAD (Breakthrough Method for Agile AI Driven Development) hat auf GitHub über 38’000 Stars gesammelt. Es definiert spezialisierte KI-Agenten für verschiedene Rollen: ein Business-Analyst-Agent erstellt Product Requirements, ein Architect-Agent entwirft die Systemarchitektur, ein Scrum-Master-Agent zerlegt Anforderungen in User Stories. Das AI-Scrum-Framework von Michael Bleterman geht noch weiter und lässt KI-Agenten tatsächlich in Sprint-Zyklen arbeiten, mit Backlog, Sprint-Dateien und rollenbasierten Aufgaben.

Die ersten Erfahrungsberichte aus diesen Frameworks zeigen ein gemischtes Bild. Parallele Ausführung durch mehrere Agenten reduziert die Durchlaufzeit spürbar. Ein dedizierter QA-Agent, dessen einzige Aufgabe darin besteht, Fehler zu finden, verändert die Qualitätsdynamik im Team. Gleichzeitig kämpfen Agenten mit Aufgaben, die ein menschlicher Entwickler in 90 Sekunden erledigt: Umgebungskonfiguration, Paketinstallationen, Pfadauflösung. Was für Menschen trivial ist, kostet einen Agenten zehn oder mehr Versuche.

Die Verschiebung des Engpasses

Hier wird es für Scrum Master besonders interessant. Wenn KI-Agenten die Entwicklungskapazität eines Teams signifikant erhöhen, verschiebt sich der Engpass. Nicht mehr das Wie ist die Herausforderung, sondern das Was. Wenn ein Feature in Tagen statt Monaten fertig wird, liegt die Begrenzung nicht mehr bei der Implementierung, sondern bei der Entscheidung, was überhaupt gebaut werden soll.

Andrew Ng nennt das den “Product Management Bottleneck”: Die technische Umsetzung wird exponentiell schneller, aber der menschliche Prozess der Priorisierung, Validierung und strategischen Ausrichtung bleibt gleich langsam. Scrum.org formuliert es noch direkter: Wenn ein Team ein funktionsfähiges Produkt in zehn Tagen bauen kann, ist die Frage nicht mehr, wie man es baut.

Für agile Teams verändert das die Gewichtung der Scrum-Events. Sprint Planning wird kritischer, weil die Auswahl der richtigen Arbeit wichtiger wird als die Kapazitätsplanung. Sprint Reviews gewinnen an Bedeutung, weil mehr Output auch mehr Feedback erfordert. Und Retrospektiven stehen vor einer neuen Frage: Wie bewerten wir die Zusammenarbeit zwischen menschlichen und nicht-menschlichen Teammitgliedern?

Die Entwicklung von “KI schreibt mir eine User Story, wenn ich sie darum bitte” zu “KI liefert getesteten Code innerhalb des Sprints” vollzieht sich gerade. Nicht überall, nicht in jedem Team, nicht ohne Reibung. Aber sie vollzieht sich. Und sie wirft eine Frage auf, die bisher niemand beantworten musste: Wenn ein KI-Agent Arbeit abliefert, nach welchen Kriterien akzeptieren wir sie?

Drei Entwickler, eine QA-Ingenieurin, ein UX-Designer und zwei KI-Agenten. So könnte die Teamzusammenstellung in deinem nächsten Sprint aussehen. Keine hypothetische Zukunftsvision, sondern ein Setup, das Entwicklungsteams bereits heute testen. Die Frage ist nicht mehr ob KI-Agenten Teil von Scrum-Teams werden. Die Frage ist, was mit der Teamdynamik passiert, wenn sie es tun.

Neue Rollen im Sprint: Wenn 20 Prozent des Teams nicht menschlich sind

Beginnen wir mit dem, was KI-Agenten im Sprint konkret tun können. Nicht theoretisch, sondern auf Basis der Erfahrungen, die Teams gerade sammeln.

Der Agent als Junior Developer

Ein Code-Agent erhält eine User Story mit Akzeptanzkriterien. Er analysiert die bestehende Codebasis, versteht die Architektur, schreibt die Implementierung, erstellt Unit Tests und öffnet einen Pull Request. Das klingt nach dem kompletten Workflow eines Junior Developers. Und genau das ist es.

Der Unterschied: Der Agent arbeitet parallel zu den menschlichen Entwicklern, ohne auf deren Verfügbarkeit zu warten. Er braucht kein Onboarding für eine neue Technologie, er vergisst keine Coding Standards, und er beschwert sich nicht über langweilige Aufgaben. Gleichzeitig hat er blinde Flecken, die ein erfahrener Junior Developer nicht hätte. Er versteht den geschäftlichen Kontext nicht, er erkennt nicht, wenn eine technische Anforderung keinen Sinn ergibt, und er fragt nicht nach, wenn die User Story lückenhaft ist. Er liefert genau das, was man ihm aufträgt. Nicht mehr, nicht weniger.

Der Agent als QA-Engineer

Hier zeigen die bisherigen Erfahrungsberichte den grössten Hebel. Ein QA-Agent, dessen einzige Aufgabe darin besteht, Code zu brechen, verändert die Qualitätsdynamik im Team grundlegend. Er generiert Testfälle aus Anforderungen, führt Regressionstests durch, analysiert Testabdeckung und meldet Defekte zurück in den Sprint. Und er tut das kontinuierlich, nicht nur am Ende des Sprints, wenn die Zeit knapp wird.

Im AI-Scrum-Framework hat sich gezeigt: Der QA-Agent fängt Regressionen ab, die bei reinem “Vibe Coding” durchrutschen würden. Menschliche QA-Engineers können sich auf explorative Tests konzentrieren, auf Usability-Bewertungen und auf die Fragen, die kein Automat stellen kann. Fühlt sich das richtig an? Versteht der Nutzer, was hier passiert? Gibt es einen Randfall, den niemand bedacht hat?

Der Agent als Sprint-Analyst

Ein dritter Einsatzbereich gewinnt an Bedeutung: die Analyse von Sprint-Daten in Echtzeit. Agenten können Velocity-Trends berechnen, Blocker identifizieren, bevor sie im Daily Standup zur Sprache kommen, und Muster in der Teamkommunikation erkennen. Sie fassen Meeting-Transkripte zusammen, extrahieren Action Items und erstellen Sprint-Reports, die sonst Stunden manueller Arbeit kosten.

Sentiment-Analyse ist ein besonders heikles Feld. Agenten können den Ton in Slack-Nachrichten und Standup-Notizen auswerten, um sinkende Motivation oder Spannungen im Team frühzeitig zu erkennen. Das klingt nützlich. Es ist aber auch ein Bereich, in dem Transparenz und Einverständnis des Teams unverzichtbar sind. Niemand will von einer Maschine überwacht werden, die seine Frustration in einem Diagramm abbildet.

Was sich wirklich verändert

Die einzelnen Anwendungsfälle sind beeindruckend. Aber die eigentliche Veränderung liegt tiefer. Sie betrifft die Struktur der Zusammenarbeit im Team.

Bisher war Softwareentwicklung ein Prozess mit klaren menschlichen Rollen und Verantwortlichkeiten. Der Scrum Guide definiert drei Accountabilities: Product Owner, Scrum Master, Developers. Alle drei sind als menschliche Rollen gedacht. Was passiert, wenn Teile der Developer-Arbeit an Agenten delegiert werden?

Erstens verschiebt sich die Arbeitsteilung. Menschliche Entwickler verbringen weniger Zeit mit Implementierung und mehr Zeit mit Review, Architekturentscheidungen und Kontextarbeit. Sie werden zu Prüfern und Kuratoren von KI-generiertem Output. Das erfordert andere Fähigkeiten als das Schreiben von Code. Code lesen und bewerten ist anspruchsvoller als Code schreiben, besonders wenn der Code von einem System stammt, das anders denkt als man selbst.

Zweitens verändert sich die Kommunikation. In einem rein menschlichen Team funktioniert Kommunikation über Kontext, Tonfall und geteilte Erfahrung. Ein erfahrener Entwickler hört im Standup, dass ein Kollege bei einer Aufgabe “noch dran ist”, und weiss aus dem Tonfall, ob das bedeutet “fast fertig” oder “ich stecke fest”. KI-Agenten kommunizieren über strukturierte Logs, Status-Updates und definierte Schnittstellen. Der Scrum Master muss zwei unterschiedliche Kommunikationskanäle koordinieren: menschliche Interaktion und maschinelle Berichterstattung.

Drittens entsteht ein Verantwortungsproblem. Wenn ein Mensch fehlerhaften Code liefert, gibt es eine klare Zuordnung. Die Person lernt daraus, das Team bespricht den Fehler in der Retro, der Prozess wird angepasst. Wenn ein Agent fehlerhaften Code liefert, ist die Zuordnung unklar. Liegt es am Prompt? An der Konfiguration? An den Trainingsdaten des zugrunde liegenden Modells? An der User Story, die zu vage formuliert war? Die Fehlerkette ist länger, und die Verantwortung verteilt sich über mehrere menschliche und technische Schichten.

Vom Individual Contributor zum virtuellen Teammanager

Michael Bleterman, der das AI-Scrum-Framework entwickelt hat, beschreibt die Rollenverschiebung so: Der Mensch ist nicht mehr der “Individual Contributor mit KI-Superkräften”, sondern der “Scrum Master eines virtuellen Teams”. Er gibt die strategische Richtung vor, prüft Ergebnisse auf Sprint-Ebene, justiert Leitplanken und speist die Erkenntnisse aus Retrospektiven in den nächsten Zyklus ein.

Das ist ein Paradigmenwechsel. Nicht weil die Technologie so neu wäre, sondern weil es die Art verändert, wie wir über Teamarbeit in Scrum nachdenken. Der Scrum Guide sagt, ein Scrum-Team sei eine “zusammenhängende Einheit von Fachleuten”. Sind KI-Agenten Fachleute? Sie besitzen Fachwissen, sie liefern Ergebnisse, sie können ihre Leistung über Sprints hinweg verbessern, weil ihre Erfahrungen in Vektordatenbanken persistiert werden. Aber sie haben kein Commitment zum Sprint-Ziel. Sie haben keine Meinung im Planning Poker. Sie sagen nicht “das schaffen wir nicht” oder “das sollten wir anders lösen”.

Diese Lücke zwischen Leistungsfähigkeit und Teamzugehörigkeit ist das, was Scrum Master jetzt navigieren müssen. Nicht irgendwann. Jetzt.

Dave West, CEO von Scrum.org, sagt es ohne Umschweife: KI-Kompetenzen sind für Scrum Master nicht mehr optional. Im Februar 2026 hat Scrum.org den Kurs “Professional Scrum Master - AI Essentials” lanciert, inklusive Zertifizierung. Das ist kein Trend-Seminar. Es ist ein Signal, dass die Organisation hinter dem Scrum Guide die Rolle des Scrum Masters offiziell neu definiert.

Die neue Rolle des Scrum Masters: Facilitator für Mensch und Maschine

Die Diskussion darüber, ob KI den Scrum Master ersetzen wird, verfehlt den Kern. Die richtige Frage lautet: Welche Teile der Rolle verschwinden, und welche werden wichtiger?

Was Agenten übernehmen

Sei ehrlich: Wie viel deiner Arbeitszeit als Scrum Master fliesst in administrative Tätigkeiten? Jira-Boards aktualisieren. Sprint-Reports zusammenstellen. Velocity berechnen. Standup-Ergebnisse dokumentieren. Meeting-Einladungen verschicken. Blocker in Confluence protokollieren.

Genau diese Aufgaben erledigen KI-Agenten bereits. Auf dem AWS Marketplace gibt es ein Produkt namens “Agent Scrum”, das autonome Agenten für jede Phase des Scrum-Prozesses anbietet: ein Standup-Agent erfasst Updates, ein Backlog-Agent optimiert Prioritäten, ein Planning-Agent balanciert Workloads, ein Retrospective-Agent extrahiert Erkenntnisse und analysiert die Stimmung im Team. Der Anbieter verspricht eine Reduktion des manuellen Facilitation-Aufwands um über 30 Prozent.

Dreissig Prozent. Das ist fast ein Drittel der operativen Arbeit, die viele Scrum Master täglich leisten.

Für Scrum Master, die ihre Rolle primär als administrative Koordination verstehen, ist das eine existenzielle Nachricht. In der Scrum.org-Community formuliert es ein Beitrag auf den Punkt: KI setzt jene Scrum Master unter Druck, die ihre Aufgabe darin sehen, Scrum-Events zu facilitieren, Jira-Boards zu pflegen, Tickets zu verschieben und Notizen zu machen. Diese Tätigkeiten lassen sich automatisieren. Teilweise schon heute, vollständig in naher Zukunft.

Was Agenten nicht können

Jetzt die andere Seite. Und sie ist entscheidend.

KI kann keine organisationale Politik navigieren. Sie erkennt nicht, dass der Stakeholder im Sprint Review gelangweilt nickt, weil er das Projekt intern bereits abgeschrieben hat. Sie merkt nicht, dass zwei Teammitglieder seit der letzten Retro nicht mehr miteinander sprechen. Sie versteht nicht, dass der Product Owner unter Druck steht, weil sein Vorgesetzter ein Feature will, das dem Sprint-Ziel widerspricht.

KI kann keine Verhaltensänderungen coachen. Sie kann einem Entwickler nicht beibringen, wie er seine Bedenken in einer Gruppe äussert, ohne defensiv zu wirken. Sie kann einem Product Owner nicht helfen, Nein zu sagen. Sie kann ein Team nicht durch den schwierigen Moment begleiten, in dem alte Gewohnheiten aufbrechen und neue Arbeitsweisen sich noch fremd anfühlen.

KI kann keine Machtdynamiken erkennen. Wer dominiert die Diskussion im Planning? Wer schweigt, obwohl er eine abweichende Meinung hat? Wer übernimmt immer die gleichen Aufgaben, weil niemand ihn herausfordert? Diese Beobachtungen erfordern emotionale Intelligenz, Kontextwissen und die Fähigkeit, das Ungesagte zu lesen. Kein Sprachmodell der Welt kann das, egal wie viele Parameter es hat.

Die Scrum.org-Community bringt es auf eine nützliche Unterscheidung: KI ist reaktiv. Sie wird aufgerufen und reagiert. Scrum Master sind proaktiv. Sie erkennen Probleme, bevor jemand sie artikuliert. Sie schaffen Bedingungen, unter denen ein Team besser zusammenarbeitet, ohne dass das Team es bewusst merkt. Das ist eine zutiefst menschliche Fähigkeit.

Die Synthese: Mehr Zeit für das, was zählt

Hier liegt die eigentliche Chance. Wenn Agenten die administrative Last übernehmen, gewinnt der Scrum Master Zeit für die Arbeit, die den grössten Unterschied macht: Coaching, Teamentwicklung und systemische Verbesserung.

Statt 20 Minuten damit zu verbringen, Sprint-Metriken aus Jira zu exportieren und in eine Präsentation zu packen, kann der Scrum Master diese 20 Minuten nutzen, um mit einem Teammitglied zu sprechen, das seit zwei Sprints ungewöhnlich still ist. Statt den Standup-Bericht zu dokumentieren, kann er beobachten, wie das Team kommuniziert, und Muster erkennen, die auf tiefere Probleme hinweisen.

Das PSM-AI-Essentials-Programm von Scrum.org adressiert genau diesen Übergang. Es vermittelt nicht nur Prompt Engineering und KI-Grundlagen, sondern stellt die Frage, wie Scrum Master ihre Teams befähigen, KI-Tools effektiv und verantwortungsvoll einzusetzen. Der Kurs positioniert den Scrum Master als Katalysator für den KI-Wandel in der Organisation, nicht als Bediener von KI-Tools.

Neue Kompetenzen, neue Fragen

Was bedeutet das konkret für deinen Arbeitsalltag? Drei Kompetenzfelder gewinnen an Gewicht:

KI-Output bewerten können. Wenn ein Agent einen Sprint-Report erstellt, musst du beurteilen können, ob die Daten stimmen, ob die Schlussfolgerungen valide sind und ob relevante Informationen fehlen. Das erfordert ein Grundverständnis davon, wie KI-Systeme zu ihren Ergebnissen kommen und wo ihre systematischen Schwächen liegen. Halluzinationen in einem Sprint-Report können Entscheidungen in die falsche Richtung lenken.

Hybride Facilitation gestalten können. Dein Daily Standup hat jetzt zwei Informationsquellen: die menschlichen Updates und die maschinellen Status-Reports. Wie integrierst du beides, ohne dass das Meeting doppelt so lang wird? Wie stellst du sicher, dass menschliche Teammitglieder sich nicht von den scheinbar perfekten KI-Berichten einschüchtern lassen? Wie bewahrst du den sozialen Charakter des Standups, wenn ein Teil der “Teilnehmer” keine sozialen Bedürfnisse hat?

Ethische Leitplanken setzen können. Sentiment-Analyse klingt nützlich, kann aber schnell in Überwachung kippen. Automatisierte Performance-Metriken können Druck erzeugen statt Transparenz schaffen. Der Scrum Master muss entscheiden, wo die Grenze verläuft, und diese Grenze im Team verhandeln. Das ist keine technische Frage. Es ist eine Frage der Teamkultur und des Vertrauens.

Die IAPP (International Association of Privacy Professionals) warnt in ihrer Analyse zu Agentic AI vor einem Risiko, das selten diskutiert wird: Skill Atrophy. Wenn Teams sich zu stark auf KI-Agenten verlassen, können menschliche Kompetenzen verkümmern. Das betrifft nicht nur technische Fähigkeiten, sondern auch die Fähigkeit, eigenständig zu denken, Probleme zu analysieren und kreative Lösungen zu finden. Die IAPP spricht sogar von negativen psychologischen Effekten auf das Selbstwertgefühl der Betroffenen.

Hier schliesst sich der Kreis zur Rolle des Scrum Masters. Denn genau davor zu schützen, gehört zu seinen Kernaufgaben: dafür zu sorgen, dass das Team wächst, lernt und sich entwickelt. Auch dann, wenn eine Maschine die Arbeit schneller erledigen könnte.

Ein Entwickler liefert Code. Der Code kompiliert, die Tests laufen durch, der Review ist abgeschlossen, die Dokumentation steht. Laut Definition of Done ist das Increment fertig. Jetzt liefert ein KI-Agent Code. Der Code kompiliert, die Tests laufen durch, ein automatisierter Review findet keine Fehler, die Dokumentation wurde mitgeneriert. Ist das Increment fertig?

Die Antwort lautet: Wir wissen es nicht. Denn unsere bisherigen Qualitätsstandards wurden für menschliche Arbeit entworfen. Und menschliche Arbeit funktioniert fundamental anders als maschinelle.

Definition of Done für KI-generierte Arbeit: Ein neuer Standard muss her

Die Definition of Done ist eines der wirkungsvollsten Instrumente in Scrum. Sie schafft ein gemeinsames Verständnis davon, wann Arbeit tatsächlich abgeschlossen ist. Kein “eigentlich fertig”, kein “fehlt nur noch der Test”, kein “funktioniert auf meinem Rechner”. Entweder die DoD ist erfüllt oder sie ist es nicht.

Dieses Instrument stösst an seine Grenzen, wenn ein Teil der Arbeit von KI-Agenten stammt. Nicht weil die Qualität zwangsläufig schlechter wäre. Sondern weil die Risiken anders gelagert sind.

Warum bestehende Kriterien nicht reichen

Wenn ein menschlicher Entwickler Code schreibt, kann man ihn fragen: Warum hast du dich für diesen Ansatz entschieden? Welche Alternativen hast du verworfen? Wo siehst du Risiken? Der Entwickler kann seine Entscheidungen erklären, weil er sie bewusst getroffen hat.

Ein KI-Agent kann das nicht. Er generiert Output auf Basis statistischer Muster. Er hat keine Intention, keine Abwägung, kein Verständnis für Konsequenzen. Sein Code kann funktional korrekt sein und trotzdem Probleme verursachen, die erst Wochen später sichtbar werden: eine Architekturentscheidung, die nicht zum Gesamtsystem passt. Eine Abhängigkeit, die niemand im Team kennt. Ein Sicherheitsmuster, das veraltet ist, weil die Trainingsdaten es als Standard gelernt haben.

Forrester Research prognostiziert, dass KI-Vertrauen 2026 zur grössten organisationalen Herausforderung wird. Vertrauen entsteht nicht durch Hoffnung. Es entsteht durch überprüfbare Standards. Genau das leistet eine erweiterte Definition of Done.

Sechs Kriterien für KI-generierte Arbeit

Was sollte eine DoD enthalten, die auch für KI-generierte Artefakte gilt? Sechs Kriterien haben sich aus der aktuellen Diskussion und den ersten Praxiserfahrungen herauskristallisiert:

1. Nachvollziehbarkeit (Audit Trail)

Jedes KI-generierte Artefakt muss dokumentieren, welcher Agent es erstellt hat, welches Modell zugrunde lag, welcher Prompt oder welche Konfiguration verwendet wurde und wann die Erstellung stattfand. Das klingt nach Bürokratie. Es ist aber die Grundlage für jede Form von Fehleranalyse. Wenn ein Bug in KI-generiertem Code auftaucht, muss das Team die Entstehung zurückverfolgen können. Ohne Audit Trail ist jede Retrospektive zu diesem Thema Spekulation.

Singapurs Governance-Framework für Agentic AI, das im Januar 2026 beim World Economic Forum vorgestellt wurde, fordert genau diese Nachvollziehbarkeit. Nicht als Nice-to-have, sondern als Voraussetzung für den produktiven Einsatz.

2. Human Review

Kein KI-generiertes Artefakt verlässt den Sprint ohne menschliche Prüfung und explizite Freigabe. Das gilt für Code, für Testfälle, für Dokumentation, für Sprint-Analysen. Jedes Stück Arbeit braucht einen menschlichen Namen, der dafür einsteht.

Das ist der einfachste und zugleich wichtigste Punkt. Er stellt sicher, dass die Verantwortung bei einem Menschen liegt, nicht bei einem System. Der EU AI Act verlangt für Hochrisiko-KI-Systeme, dass qualifiziertes Personal jede Entscheidung übersteuern kann. Auch wenn Scrum-Artefakte nicht direkt unter diese Kategorie fallen, etabliert das Prinzip einen Standard, den Teams ernst nehmen sollten.

3. Bias-Prüfung

KI-Modelle reproduzieren systematische Verzerrungen aus ihren Trainingsdaten. Ein Agent, der Testfälle generiert, könnte bestimmte Nutzergruppen systematisch unterrepräsentieren. Ein Agent, der Sprint-Daten analysiert, könnte die Leistung einzelner Teammitglieder verzerrt darstellen, weil sein Modell bestimmte Arbeitsmuster bevorzugt.

Die Bias-Prüfung fragt: Gibt es Hinweise darauf, dass der Output systematisch in eine Richtung verzerrt ist? Das erfordert kein Data-Science-Studium. Es erfordert die Bereitschaft, KI-Ergebnisse kritisch zu hinterfragen, statt sie als objektive Wahrheit zu akzeptieren.

4. Regulatorische Compliance

In der Schweiz gilt das neue Datenschutzgesetz (nDSG). Der EU AI Act tritt schrittweise in Kraft. Ab August 2026 gelten verschärfte Regeln für KI-Systeme, die als hochriskant eingestuft werden. Organisationen, die KI-Agenten in ihren Entwicklungsprozessen einsetzen, müssen prüfen, ob diese Systeme unter regulatorische Anforderungen fallen.

Für ein Scrum-Team bedeutet das: Die DoD sollte einen Compliance-Check enthalten. Verarbeitet der Agent personenbezogene Daten? Trifft er Entscheidungen, die unter den EU AI Act fallen? Sind die Anforderungen des nDSG an automatisierte Einzelentscheidungen erfüllt? Diese Fragen müssen beantwortet sein, bevor ein Increment als “Done” gilt.

5. Reproduzierbarkeit

Menschlicher Code ist deterministisch: Gleicher Input, gleicher Output. KI-generierter Code ist es häufig nicht. Dasselbe Modell kann bei identischem Prompt unterschiedliche Ergebnisse liefern. Das macht Qualitätssicherung schwieriger.

Die DoD sollte festlegen, dass KI-generierte Artefakte unter kontrollierten Bedingungen reproduzierbar sein müssen. In der Praxis heisst das: Modellversion, Temperature-Setting, System-Prompt und Input-Daten werden versioniert, damit das Team den Output bei Bedarf nachvollziehen und reproduzieren kann.

6. Architekturkonformität

Ein KI-Agent kennt die Architekturprinzipien deines Systems nur, wenn man sie ihm explizit mitgibt. Er hält sich nicht an ungeschriebene Konventionen. Er respektiert keine informellen Absprachen darüber, welche Libraries verwendet werden sollen und welche nicht. Er erzeugt Code, der isoliert korrekt funktioniert, aber im Gesamtkontext Probleme verursachen kann.

Die DoD sollte verlangen, dass jedes KI-generierte Artefakt gegen die bestehenden Architekturrichtlinien und Coding Standards geprüft wird. Nicht durch einen weiteren Agenten, sondern durch einen Menschen, der das Gesamtsystem versteht.

Von der Checkliste zur Teamvereinbarung

Diese sechs Kriterien wirken auf den ersten Blick wie zusätzlicher Aufwand. Sechs neue Checkboxen auf einer ohnehin langen Liste. Aber das greift zu kurz.

Die erweiterte DoD ist keine bürokratische Hürde. Sie ist eine Teamvereinbarung über den Umgang mit einer neuen Art von Arbeit. Sie zwingt das Team, sich explizit mit Fragen auseinanderzusetzen, die sonst im Alltag untergehen: Wie viel Vertrauen schenken wir KI-generiertem Output? Wer trägt die Verantwortung? Welche Risiken akzeptieren wir, welche nicht?

IBM und Morning Consult berichten, dass 99 Prozent der befragten Enterprise-KI-Entwickler KI-Agenten explorieren oder entwickeln. Gleichzeitig zeigt IBMs Cost of a Data Breach Report, dass Organisationen ohne KI-Governance-Richtlinien im Durchschnitt 670’000 US-Dollar mehr pro Sicherheitsvorfall bezahlen. Die DoD ist der Ort, an dem Governance für das Scrum-Team konkret wird. Nicht in einem Policy-Dokument, das niemand liest, sondern in der täglichen Arbeit.

Und sie beginnt mit einer einfachen Frage im nächsten Sprint Planning: Gelten unsere aktuellen Done-Kriterien auch für die Arbeit, die ein KI-Agent liefert? Wenn das Team zögert, ist es Zeit für ein Update.

Im Dezember 2025 veröffentlichte die OWASP Foundation eine Liste, die es vorher nicht gab: die Top 10 Sicherheitsrisiken für Agentic Applications. Nicht für KI allgemein. Nicht für Chatbots. Speziell für autonome KI-Systeme, die eigenständig handeln. Die Einleitung der Autoren ist unmissverständlich: “Das sind keine theoretischen Risiken. Es sind die gelebten Erfahrungen der ersten Generation von Agentic-AI-Anwendern.”

Willkommen in der Realität hinter dem Hype.

Risiken und Governance: Was schiefgehen kann, wenn Agenten autonom handeln

Die Begeisterung für KI-Agenten in Scrum-Teams ist nachvollziehbar. Schnellere Sprints, weniger Routinearbeit, höhere Testabdeckung. Aber jede neue Fähigkeit bringt neue Fehlerquellen mit sich. Und bei autonomen Systemen sind diese Fehlerquellen anders als alles, womit Scrum-Teams bisher umgehen mussten.

Die Zahlen, die man kennen sollte

80 Prozent der Organisationen, die KI-Agenten einsetzen, haben bereits riskantes Verhalten dieser Systeme erlebt. Dazu gehören unautorisierte Datenzugriffe, unbeabsichtigte Änderungen an Systemen und die Weitergabe sensibler Informationen über Systemgrenzen hinweg. Gleichzeitig haben nur 20 Prozent dieser Organisationen angemessene Sicherheitsmassnahmen implementiert.

Das Missverhältnis ist frappierend. Vier von fünf Unternehmen erleben Probleme. Eines von fünf ist darauf vorbereitet.

IBM beziffert die Konsequenzen: Organisationen ohne KI-Governance-Richtlinien zahlen pro Sicherheitsvorfall durchschnittlich 670’000 US-Dollar mehr als solche mit klaren Regeln. Und 63 Prozent der betroffenen Organisationen haben überhaupt keine Governance-Richtlinien für KI.

Risiko Nr. 1: Goal Hijacking

Die OWASP listet “Agent Goal Hijacking” als das grösste Risiko für Agentic Applications. Der Angriff funktioniert so: Ein Dritter bettet schädliche Anweisungen in Daten ein, die der Agent verarbeitet. Der Agent kann nicht zuverlässig unterscheiden, ob eine Anweisung von seinem konfigurierten Auftrag stammt oder von einem manipulierten Dokument, einer kompromittierten API-Antwort oder einer präparierten Webseite.

Forscher der Cornell University haben demonstriert, dass Angreifer schädliche Instruktionen in Webinhalte verstecken können, die ein Agent im Rahmen seiner Aufgabe abruft. Der Agent führt die manipulierten Anweisungen aus, ohne dass der Nutzer es bemerkt. Im schlimmsten Fall exfiltriert er interne Daten.

Für ein Scrum-Team bedeutet das: Ein Code-Agent, der externe Dokumentation oder Stack-Overflow-Antworten in seinen Workflow einbezieht, ist potenziell angreifbar. Nicht durch einen Fehler im Agent selbst, sondern durch die Daten, mit denen er arbeitet.

Risiko Nr. 2: Kaskadenfehler

McKinsey beschreibt ein Risiko, das in Multi-Agent-Systemen besonders relevant wird: Chained Vulnerabilities. Ein Fehler in einem Agenten pflanzt sich über Aufgaben hinweg zu anderen Agenten fort und verstärkt sich dabei.

Stell dir vor: Ein Code-Agent generiert eine Funktion mit einem subtilen Logikfehler. Der QA-Agent testet die Funktion, erkennt den Fehler aber nicht, weil seine Testfälle auf dem gleichen fehlerhaften Verständnis der Anforderung basieren. Ein Dokumentations-Agent beschreibt die Funktion korrekt auf Basis des fehlerhaften Codes. Der Sprint-Analyse-Agent meldet grüne Ampeln auf allen Metriken. Vier Agenten, vier Bestätigungen, ein Fehler, den keiner von ihnen erkannt hat.

In einem menschlichen Team würde spätestens im Code Review jemand stutzen. “Warte mal, macht das wirklich Sinn?” Diese intuitive Plausibilitätsprüfung fehlt in einer Agentenkette. Jeder Agent vertraut dem Output des vorherigen, weil er keine Skepsis kennt.

Risiko Nr. 3: Schleichende Privilegien-Ausweitung

Agenten brauchen Zugang zu Systemen, um ihre Aufgaben zu erfüllen. Ein Code-Agent braucht Zugriff auf das Repository. Ein QA-Agent braucht Zugriff auf die Testumgebung. Ein Analyse-Agent braucht Zugriff auf Jira, Confluence und möglicherweise Slack.

Die OWASP warnt vor “Identity and Privilege Abuse”: Agenten akkumulieren über die Zeit Zugriffsrechte, die über ihre ursprüngliche Aufgabe hinausgehen. Sie beschreiben das als “Privilege Creep”, vergleichbar mit einem Mitarbeiter, der bei jedem Projekt neue Systemzugänge erhält, aber nie welche abgeben muss.

PwC empfiehlt deshalb das Prinzip der minimalen Berechtigung: Ein Agent erhält nur die Zugriffsrechte, die er für seine spezifische Aufgabe braucht. Nicht mehr. Und diese Rechte werden regelmässig überprüft und zurückgesetzt. Für Scrum-Teams bedeutet das einen zusätzlichen Aufwand bei der Konfiguration und Wartung von Agenten, der in der Sprint-Planung berücksichtigt werden muss.

Die Verantwortungsfrage

Alle drei Risiken führen zu einer Frage, die bisher nicht beantwortet ist: Wer haftet, wenn ein KI-Agent im Sprint Schaden verursacht?

Der Product Owner hat das Sprint-Ziel definiert. Der Scrum Master hat den Sprint facilitiert. Das Entwicklungsteam hat den Agenten konfiguriert und integriert. Der Anbieter des KI-Modells hat das Basismodell trainiert. Der Cloud-Provider stellt die Infrastruktur bereit. Die Verantwortungskette ist lang, und die Zuordnung ist in den meisten Organisationen ungeklärt.

Singapurs IMDA-Framework, vorgestellt beim World Economic Forum im Januar 2026, adressiert genau dieses Problem. Es empfiehlt vier Massnahmen: Risiken vor dem Einsatz bewerten und begrenzen. Menschliche Verantwortlichkeiten für die Überwachung von Agenten klar zuweisen. Technische Kontrollmechanismen implementieren. Und Endnutzer befähigen, Risiken eigenständig zu managen.

Das Framework von Davis Wright Tremaine, einer der führenden Kanzleien im KI-Recht, formuliert es noch konkreter: Organisationen sollten vor dem Deployment festlegen, welche Handlungen ein Agent autonom ausführen darf und welche eine menschliche Freigabe erfordern. Sie nennen das den “Action Space” des Agenten. Je enger dieser Handlungsraum definiert ist, desto geringer das Risiko.

Was das für den Sprint bedeutet

Governance klingt nach Konzernpolitik und Compliance-Abteilungen. Weit weg vom Alltag eines Scrum-Teams. Aber die Konsequenzen sind unmittelbar.

Wenn ein Agent im Sprint einen Datenbankzugriff ausführt, der nicht autorisiert war, steht nicht die Compliance-Abteilung vor dem Problem. Es steht das Team vor dem Problem. Wenn ein Agent Code deployed, der eine Sicherheitslücke enthält, wird nicht der Modell-Anbieter zur Verantwortung gezogen. Es wird das Team zur Verantwortung gezogen.

Governance im Scrum-Kontext heisst deshalb: klare Regeln darüber, was Agenten tun dürfen und was nicht. Definiert vom Team, für das Team, im Rahmen der Sprint-Vereinbarungen. Nicht als externes Regelwerk, das von oben kommt, sondern als bewusste Entscheidung der Menschen, die mit diesen Systemen arbeiten.

Die Retrospektive wird dabei zum zentralen Event. Nicht nur für die Frage “Wie haben wir zusammengearbeitet?”, sondern für die Frage “Wie haben unsere Agenten gearbeitet, und was müssen wir ändern?” Welche Zugriffe hatten sie? Welche Entscheidungen haben sie getroffen? Gab es Situationen, in denen ein Mensch hätte eingreifen müssen? Und wenn ja: Hat der Prozess das ermöglicht?

Wer diese Fragen nicht stellt, verliert die Kontrolle. Nicht plötzlich, nicht dramatisch. Sondern schleichend, Sprint für Sprint, bis niemand mehr genau weiss, was die Agenten eigentlich tun.

Genug Analyse. Du weisst jetzt, was Agentic AI im Scrum-Kontext bedeutet, welche Rollen sich verschieben, warum die Definition of Done ein Update braucht und welche Risiken lauern. Die Frage ist: Was tust du am Montag damit?

Konkret starten: Fünf Schritte für Scrum Master, die nicht warten wollen

Die grösste Gefahr ist nicht, dass du zu früh startest. Die grösste Gefahr ist, dass du wartest, bis jemand anders die Regeln für dein Team festlegt. Ein Compliance-Beauftragter, der Scrum nicht versteht. Ein Management, das “KI-Transformation” als Top-Down-Initiative ausrollt. Oder ein enthusiastischer Entwickler, der einen Agenten in den Sprint einbaut, ohne das Team zu informieren.

Scrum Master, die jetzt handeln, gestalten den Rahmen. Alle anderen passen sich später an.

Schritt 1: Bestandsaufnahme der repetitiven Arbeit

Nimm dir 30 Minuten und notiere jede Aufgabe, die in deinem letzten Sprint repetitiv war. Standup-Zusammenfassungen. Velocity-Berechnungen. Sprint-Report-Erstellung. Testdaten-Generierung. Backlog-Pflege. Status-Updates in Confluence.

Bewerte jede Aufgabe nach zwei Kriterien: Wie viel Zeit kostet sie? und Wie hoch ist das Risiko, wenn ein Agent sie fehlerhaft ausführt? Aufgaben mit hohem Zeitaufwand und niedrigem Risiko sind deine Einstiegspunkte. Sprint-Berichte zusammenfassen: niedriges Risiko. Produktionscode deployen: hohes Risiko. Die Unterscheidung klingt trivial, wird aber in der Praxis erstaunlich selten gemacht.

Schritt 2: Die Definition of Done erweitern

Bring das Thema in die nächste Retrospektive. Nicht als Vortrag, sondern als Frage: “Wenn ein KI-Agent einen Teil unserer Sprint-Arbeit übernehmen würde, würden unsere aktuellen Done-Kriterien ausreichen?”

Lass das Team diskutieren. Die sechs Kriterien aus dem vorherigen Abschnitt (Nachvollziehbarkeit, Human Review, Bias-Prüfung, Compliance, Reproduzierbarkeit, Architekturkonformität) sind ein Startpunkt, kein fertiges Regelwerk. Jedes Team hat andere Risiken, andere regulatorische Anforderungen und eine andere Fehlertoleranz. Die DoD muss zum Team passen, nicht zu einem Blogpost.

Schritt 3: Governance im Team verankern

Governance klingt schwer. In der Praxis beginnt sie mit drei Fragen, die das Team gemeinsam beantwortet:

Wer prüft KI-generierten Output? Jedes Artefakt braucht einen verantwortlichen Menschen. Keine diffuse Teamverantwortung, sondern einen Namen. Maria prüft den generierten Code. Thomas prüft die Testfälle. Lisa prüft die Sprint-Analyse. Klare Zuordnung, klare Verantwortung.

Wer gibt Agenten Zugang zu Systemen? Definiert gemeinsam, welche Systeme ein Agent nutzen darf und welche nicht. Schreibt es auf. Prüft es jede zweite Sprint-Retro. Das Prinzip der minimalen Berechtigung funktioniert nur, wenn jemand die Berechtigungen regelmässig kontrolliert.

Was passiert bei einem Fehler? Definiert einen Eskalationspfad, bevor der erste Fehler passiert. Wer wird informiert? Wer entscheidet, ob der Agent weiterlaufen darf? Wer kommuniziert an Stakeholder? Die Antworten auf diese Fragen in einer ruhigen Retro zu klären, ist um ein Vielfaches einfacher als im Moment, in dem ein Agent gerade Produktionsdaten in ein falsches System kopiert hat.

Schritt 4: Klein anfangen, bewusst lernen

Starte nicht mit einem Agenten, der Code für das Produktionssystem schreibt. Starte mit einem Agenten, der Standup-Notizen zusammenfasst. Oder der Testdaten generiert. Oder der Sprint-Metriken aufbereitet.

Beobachte über zwei bis drei Sprints: Wie verändert sich die Teamdynamik? Vertrauen die Teammitglieder dem Output? Wo entstehen Reibungspunkte? Wo spart der Agent tatsächlich Zeit, und wo erzeugt seine Integration neuen Aufwand? Dokumentiere die Erkenntnisse und besprich sie in der Retrospektive.

Die erfolgreichsten Organisationen behandeln KI-Agenten nicht als Technologie-Rollout, sondern als Lernprozess. McKinsey berichtet, dass Unternehmen, die Agenten als reine Produktivitäts-Add-ons betrachten, konsistent an der Skalierung scheitern. Erfolg entsteht dort, wo Teams Prozesse für Agenten neu denken, statt Agenten auf bestehende Prozesse zu stülpen.

Schritt 5: Kompetenz aufbauen, kontinuierlich

Scrum.org bietet mit dem PSM-AI Essentials eine erste strukturierte Weiterbildung. Das ist ein Anfang, kein Abschluss. Die relevanten Kompetenzen entwickeln sich schneller als jedes Curriculum sie abbilden kann.

Drei Fähigkeiten verdienen besondere Aufmerksamkeit:

Prompt Engineering ist die Fähigkeit, KI-Agenten präzise Anweisungen zu geben. Vage Prompts erzeugen vage Ergebnisse. Spezifische Prompts mit klarem Kontext, expliziten Einschränkungen und definierten Erfolgskriterien erzeugen brauchbare Ergebnisse. Das ist erlernbar und wird mit jeder Interaktion besser.

Kritische Bewertung von KI-Output ist die Fähigkeit, Ergebnisse nicht für bare Münze zu nehmen. Stimmen die Zahlen im Sprint-Report? Macht der generierte Code architektonisch Sinn? Fehlt etwas in den Testfällen? Diese Fähigkeit erfordert Fachwissen im jeweiligen Bereich und die Bereitschaft, dem Agenten zu misstrauen, auch wenn sein Output überzeugend aussieht.

Systemisches Denken ist die Fähigkeit, die Wechselwirkungen zwischen menschlichen und maschinellen Teammitgliedern zu verstehen. Wo verstärken sich Effekte? Wo entstehen blinde Flecken? Wo verkümmern menschliche Kompetenzen, weil der Agent die Arbeit übernimmt? Diese Perspektive war für Scrum Master schon immer zentral. Sie gewinnt mit KI-Agenten im Team eine zusätzliche Dimension.

Abschliessende Gedanken

Ich gebe zu: Als ich vor zwei Jahren zum ersten Mal von “KI-Agenten im Scrum-Team” gelesen habe, war mein erster Gedanke ein recht uncharmantes “Ja, klar.” Irgendwo zwischen Hype-Müdigkeit und dem sechsten LinkedIn-Post über die “Revolution der Arbeitswelt” an diesem Morgen.

Mittlerweile hat sich meine Haltung verschoben. Nicht weil ich den Hype glaube, sondern weil ich die Praxis sehe. Ich sehe Frameworks, die funktionieren. Ich sehe Erfahrungsberichte, die ehrlich sind über das, was klappt und was nicht. Ich sehe, dass Scrum.org eine Zertifizierung lanciert, und Scrum.org macht das nicht, weil gerade ein Trendbegriff auf LinkedIn gut performt.

Was ich auch sehe: viel Unsicherheit. Scrum Master, die nicht wissen, wo sie anfangen sollen. Teams, die KI-Tools nutzen, ohne über Qualitätsstandards nachzudenken. Organisationen, die “Agentic AI” auf Roadmaps schreiben, aber keine Antwort auf die Frage haben, wer die Verantwortung trägt, wenn ein Agent Mist baut.

Und genau da liegt unsere Aufgabe als Scrum Master. Nicht als KI-Experten, die jedes Framework kennen. Nicht als Technologie-Evangelisten, die ihr Team zum Experimentieren drängen. Sondern als die Leute, die unbequeme Fragen stellen. Haben wir Kriterien für diese Art von Arbeit? Wer prüft das? Was passiert, wenn es schiefgeht?

Das ist nicht sexy. Das wird keinen viralen Post auf LinkedIn erzeugen. Aber es ist das, was Teams brauchen, wenn sich die Spielregeln ändern. Jemanden, der in der Begeisterung über die neuen Möglichkeiten fragt: “Moment, haben wir eigentlich eine Definition of Done dafür?”

Ich bin überzeugt, dass KI-Agenten Teil unserer Teams werden. Nicht überall, nicht sofort, nicht ohne Rückschläge. Aber die Richtung ist klar. Und ich bin ebenso überzeugt, dass die Scrum Master, die diesen Wandel aktiv gestalten, in zwei Jahren diejenigen sein werden, die man um Rat fragt.

Die anderen werden sich fragen, wann genau ihnen die Kontrolle über ihre Sprints entglitten ist.

Also: Nächste Retro, eine Frage auf den Tisch. Du weisst, welche.