KI und Scrum Events: Was sich bei den Meetings des Entwicklungsteams wirklich ändert

Dies ist der abschließende Artikel der Serie darüber, wie KI die klassischen Meetings eines cross-funktionalen Entwicklungsteams verändert. In den vorherigen Teilen habe ich separat betrachtet Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective. Wenn man sie zusammenfasst, fällt das Gesamtfazit recht nüchtern aus: KI macht die Vorbereitung auf Scrum Events billiger und reicher, nimmt dem Team aber nicht die Verantwortung für Inspektion, Anpassung, Gespräch und reale Veränderungen.

Als ich diese Serie begann, war es leicht, in eines von zwei extremen Szenarien abzurutschen. Erstens: KI wird bald fast alle Team-Meetings ersetzen, weil das Modell bereits zusammenfassen, Aufgaben schreiben, Pläne generieren, Status sammeln, Demos vorbereiten und Action Items vorschlagen kann. Zweitens: Scrum Events sind von Natur aus so menschlich, dass KI dort kaum gebraucht wird.

Nach fünf separaten Analysen scheinen mir beide Szenarien zu flach.

KI verändert tatsächlich die Meetings des Teams. Aber nicht so, wie es in Werbeversprechen üblicherweise klingt. Sie verändert nicht den Kern der Scrum Events, sondern die Schicht um sie herum: Vorbereitung, Recherche, Zusammenfassung, erste Strukturierung, Erkennung von Signalen, Festhalten von Entscheidungen und Follow-up. Und je billiger diese Schicht wird, desto sichtbarer wird das, was sich nicht ohne Bedeutungsverlust automatisieren lässt: Team-Urteil, Verantwortung, Streit über Wert, Realitätsprüfung, psychologische Sicherheit und die Fähigkeit, Plan, Backlog oder Arbeitsweise zu ändern.

„KI macht die Vorbereitung billiger, aber macht die menschliche Verantwortung sichtbarer.“

Das ist die Hauptantwort auf die Frage der Serie. KI schafft die klassischen Meetings eines cross-funktionalen Entwicklungsteams nicht ab. Sie verändert ihre Aufmerksamkeitsökonomie. Routinemäßiges Sammeln von Fakten wird billiger. Das Erstellen sorgfältiger Entwürfe wird billiger. Statuskommunikation wird billiger. Aber der reale Wert der Scrum-Ereignisse entsteht weiterhin dort, wo das Team auf Fakten schaut, über Bedeutung streitet, einen Kompromiss eingeht und weitere Handlungen ändert.

Zunächst ist es nützlich, zum Zweck der Meetings zurückzukehren

Im Scrum Guide 2020 werden die Scrum-Ereignisse nicht als eine Reihe von Ritualen beschrieben, sondern als eingebaute Möglichkeiten für Transparenz, Inspektion und Anpassung. Sprint Planning initiiert den Sprint und hilft dem Team, sich über Wert, Arbeitsumfang und Vorgehensweise zu einigen. Daily Scrum brauchen die Entwickler, um den Fortschritt zum Sprint Goal zu prüfen und das Sprint Backlog anzupassen. Sprint Review dient der Inspektion des Ergebnisses und der weiteren Anpassung des Product Backlog. Sprint Retrospective dient der Verbesserung von Qualität und Effektivität der Teamarbeit.

Backlog Refinement steht gesondert: Es ist kein offizielles Scrum-Ereignis im Scrum Guide 2020, sondern eine laufende Aktivität zur Verfeinerung des Product Backlog. Aber im realen Leben eines cross-funktionalen Teams funktioniert Refinement oft als wichtiges regelmäßiges Meeting oder als Reihe von Arbeitssitzungen. Deshalb habe ich es in dieser Serie neben den klassischen Ereignissen betrachtet: Genau dort trifft das Team zum ersten Mal auf ein großes Volumen manueller intellektueller Vorbereitung, die KI am frühesten beschleunigt.

Dieser Rahmen ist wichtig, weil er vor der falschen Frage schützt. Die schlechte Frage lautet: „Welches Meeting kann KI ersetzen?“. Die genauere Frage lautet: „Welchen Teil der manuellen Vorbereitung kann KI übernehmen, damit das Meeting selbst zu einer ehrlicheren Inspektion und Anpassung wird?“.

Als zusätzliche Orientierung habe ich in den letzten Artikeln der Serie Scrum Guide Expanded v2026.1. verwendet. Man sollte ihn gerade als Companion-Quelle auf Basis des Scrum Guide 2020 lesen, nicht als neue kanonische Version des Scrum Guide. Für das Thema KI ist dort die Formulierung des Modells als supervised decision-making partner nützlich: KI kann Transparenz, Inspektion und Anpassung verstärken, ersetzt aber nicht die menschliche Rechenschaftspflicht und sollte empirische Prozesssteuerung nicht aufheben. Für den abschließenden Artikel ist das fast eine ideale Grenze.

Was sich in allen fünf Teilen wiederholt

Im Artikel über Backlog Refinement war das Hauptfazit: KI beschleunigt nicht die Vereinbarung des Teams selbst, sondern die Vorbereitung des Materials dafür. Sie hilft, Kontext, einen Entwurf der User Story, Akzeptanzkriterien, Risiken, offene Fragen und erste Lösungsvarianten zu sammeln. Aber sie erzeugt auch das Risiko falscher Klarheit: Die Aufgabe wirkt verständlich, weil sie gut formatiert ist.

Im Artikel über Sprint Planning zeigte sich ein ähnliches Muster auf einer anderen Ebene. KI hilft, schneller Varianten für Sprint Goal, Arbeitsumfang, Abhängigkeiten, Dekomposition und Risiken zu sammeln. Aber es entsteht falsche Realistik: Der Plan wirkt zusammenhängend, vollständig und machbar, obwohl das Team ihn noch nicht an Capacity, Definition of Done, Testbarkeit und realen Einschränkungen geprüft hat.

Im Daily Scrum KI bereitet nicht mehr die zukünftige Arbeit vor, sondern sammelt Signale über den Verlauf des Sprints. Es kann Blocker, Review-Engpässe, instabile Tests, Abweichungen zwischen Jira-Status und Realität, Abhängigkeiten und asynchron getroffene Entscheidungen hervorheben. Aber wenn der Fokus vom Sprint Goal auf „wer womit beschäftigt war“ abdriftet, wird der Daily Scrum zu AI-generiertem Status Reporting.

Im Sprint Review ist AI als vorbereitende Schicht für das Sprint-Ergebnis, Metriken, Release Notes, Feedback und offene Produktfragen nützlich. Aber genau dort ist auch das Risiko von Demo-Theater besonders sichtbar: Das Modell macht den Überblick schön, das Team zeigt eine polierte Geschichte, die Stakeholder nicken, und das Product Backlog ändert sich nicht.

In der Sprint Retrospective kann AI harte Belege in das Gespräch bringen: wiederkehrende Impediments, Warten auf Review, nicht erledigte Action Items, Abweichungen von der Definition of Done, wiederkehrende Muster. Aber eine Verbesserung entsteht nicht aus einer Liste von Empfehlungen. Sie entsteht erst, wenn das Team das Problem anerkennt, eine Änderung wählt, einen Owner benennt und sie bis zum nächsten Sprint durchzieht.

Legt man diese Befunde nebeneinander, entsteht ein gemeinsames Muster: AI macht fast überall den Einstieg in die Besprechung reicher. Und fast überall erzeugt sie die Versuchung, einen reichen Einstieg mit einer bereits getroffenen Entscheidung zu verwechseln.

Karte der Veränderungen nach Scrum Events

Besprechung / Praxis	Was AI verbilligt	Was bei den Menschen bleibt	Hauptrisiko
Backlog Refinement	Kontextsammlung, Entwurf der Aufgabenstellung, Akzeptanzkriterien, Randfälle, offene Fragen.	Prüfung des Sinns, der Domänenregeln, der technischen Einschränkungen und der Bereitschaft, die Aufgabe zu diskutieren.	Falsche Klarheit: Die Aufgabe wirkt fertig, weil sie gut geschrieben ist.
Sprint Planning	Varianten des Sprint Goal, Scope, Abhängigkeiten, Risiken, Dekomposition, Testszenarien.	Die Teamentscheidung über Ziel, Umfang, Realismus, Definition of Done und die Verpflichtung für den Sprint.	Falscher Realismus: Der Plan wirkt machbar, weil er glatt zusammengestellt ist.
Daily Scrum	Vorläufige Signale zum Sprint-Verlauf, zu Blockern, PRs, Tests, Entscheidungen und Abhängigkeiten.	Shared Awareness, Anpassung des Sprint Backlog und die Entscheidung, was sich an der nächsten Arbeit ändert.	Status-Bot: Die Besprechung wird zu einem Bericht über Menschen statt zu einem Gespräch über das Sprint Goal.
Sprint Review	Release Notes, ein Bild des Ergebnisses, Produktmetriken, Feedback und offene Fragen.	Ehrliche Inspektion des Inkrements, Gespräch mit den Stakeholdern und Anpassung des Product Backlog.	Demo-Theater: schön gezeigt, aber keine Produktentscheidungen getroffen.
Sprint Retrospective	Fakten über den Prozess, wiederkehrende Muster, alte Action Items, Belege für das Gespräch.	Psychologische Sicherheit, Anerkennung des Problems, Wahl der Verbesserung und Follow-through.	Eine Liste von AI-Empfehlungen statt einer Verhaltensänderung des Teams.

Diese Tabelle sagt nicht, dass AI „Scrum verbessert“. Das wäre eine zu starke Aussage. Eine direkte unabhängige Evidenzbasis speziell zu AI-gestützten Scrum Events ist bisher dünn, und in einzelnen Research Briefs der Serie habe ich diese Lücke bewusst vermerkt. Eine sorgfältigere Formulierung ist eine andere: AI kann eine reife Praxis der Inspektion und Anpassung verstärken, aber genauso leicht ein altes Anti-Pattern verstärken, wenn es im Team bereits lebte.

Das passt gut zum vorsichtigen Rahmen von DORA State of AI-assisted Software Development 2025: AI ist nicht als eigenständige Garantie für besseres Delivery zu betrachten, sondern als Verstärker des bestehenden organisationalen Systems. Wenn das Team in der Lage ist, über Wert, Risiken, Qualität und Prozess zu sprechen, macht AI den Einstieg reicher. Wenn das Team es gewohnt ist, Inspektion durch Status zu ersetzen, macht AI den Status schneller und schöner.

Durchgängiger Fall: B2B-LMS und E-Mail-Erinnerungen

In allen Artikeln der Serie habe ich ein Beispiel beibehalten: eine B2B-LMS-Plattform, bei der große Kunden ihren Mitarbeitenden Pflichtkurse zuweisen und das Team E-Mail-Erinnerungen für diejenigen hinzufügt, die einen Pflichtkurs nicht bis zur Deadline abgeschlossen haben. Dieser Fall zeigt gut, dass AI nicht eine einzelne konkrete Besprechung verändert, sondern die gesamte Kette der Aufmerksamkeit des Teams.

Beim Refinement hilft AI, den Kundenkontext, ähnliche Anfragen, Zuweisungsstatus, die Architektur der Benachrichtigungen, Fragen zu Zeitzonen, Deduplizierung, Spracheinstellung und Verlaufsprotokoll zusammenzutragen. Das Team kommt schneller zu einem sinnvollen Backlog Item. Aber es muss trotzdem entscheiden, was als nicht abgeschlossener Kurs gilt, wie mit expiredumzugehen ist, wo die Grenzen der ersten Version liegen und welche Daten nicht an das Modell gehen dürfen.

Beim Planning hilft AI, mehrere Varianten von Sprint Goal und Arbeitsumfang zusammenzustellen: minimal, erweitert, ambitioniert, außerhalb des Umfangs. Das Team sieht Kompromisse schneller. Aber es muss trotzdem ehrlich beantworten, was wirklich in den Sprint passt, was das Sprint Goal unterstützt, was zuerst entfernt werden kann und wo Risiken bezüglich der Definition of Done verborgen sind.

Beim Daily Scrum hebt AI Signale hervor: Ein PR zum Scheduler ist ohne Review geöffnet, QA wartet auf Testdaten, im Chat wurde ein Risiko von Duplikaten diskutiert, es gibt eine Unklarheit zur Zeitzone, der Support hat eine neue Kundenfrage gebracht. Das ist ein guter Einstieg. Aber das Team entscheidet selbst, wen es nach dem Daily synchronisieren muss, welches Risiko eskaliert wird und wie der nächste Plan angepasst wird.

Beim Sprint Review sammelt die KI das Ergebnis und Feedback: wer Erinnerungen erhalten hat, wie die Open/Click-Rates waren, welche Tickets im Support eingegangen sind, was die Pilotkunden gesagt haben, welche Backlog Items mit diesem Sprint Goal zusammenhängen. Aber Produktwert entsteht erst, wenn das Scrum Team und die Stakeholder entscheiden, was als Nächstes zu tun ist: Eligibility klären, Backlog ändern, Diagnostik für den Support hinzufügen oder die Priorität überdenken expired.

In der Sprint Retrospective hilft die KI zu erkennen, dass das Team wieder zu spät Testdaten erhalten hat, dass Reviews an ähnlichen Stellen hängen blieben, dass das Definition of Done zwischen den Rollen implizit auseinanderlief und dass ein Action Item aus dem letzten Sprint nicht erledigt wurde. Aber Verbesserung beginnt erst, wenn das Team ein konkretes Experiment für den nächsten Sprint auswählt: zum Beispiel vorab einen Owner für die Testdaten festlegen, die PR-Größe reduzieren oder das DoD für Aufgaben mit E-Mail-Versand präzisieren.

Derselbe Fall zeigt das Wesentliche: Die KI kann einen Faden von Fakten durch den gesamten Sprint ziehen. Aber sie kann nicht die Entscheidungen ersetzen, die diese Fakten nützlich machen.

Fünf Anti-Patterns, die die KI beschleunigt

Das Unangenehmste an der KI ist nicht, dass sie manchmal Fehler macht. Fehler lassen sich abfangen. Das Unangenehmste ist, dass sie einen schlechten Prozess sehr überzeugend machen kann.

Falsche Klarheit. Im Refinement sieht das Team eine saubere User Story, detaillierte Acceptance Criteria und eine Liste von Edge Cases. Es scheint, die Aufgabe sei klar. Aber wenn die Fakten nicht zu den Quellen zurückverfolgt werden und offene Fragen unter glattem Text verborgen sind, hat das Team einfach schneller die Illusion von Bereitschaft erzeugt.

Falsche Realitätsnähe. Im Planning stellt das Modell einen schönen Sprint Plan zusammen: Ziel, Scope, Abhängigkeiten, Risks, Steps, Estimates. Aber wenn die Entwickler Capacity, DoD, unfertige Arbeit und reale Einschränkungen nicht geprüft haben, ist das kein Plan. Das ist gut formatierte Hoffnung.

Status-Bot. Im Daily Scrum schreibt die KI jeden Tag, wer was gemacht hat, was sich in Jira geändert hat und welche PRs offen sind. Das ist praktisch. Aber wenn das Team aufgehört hat, über das Sprint Goal und die nächste Anpassung des Plans zu sprechen, ist das Daily Scrum zur Berichterstattung geworden.

Demo-Theater. Im Sprint Review bereitet die KI Slides, Release Notes und eine Zusammenfassung des Feedbacks vor. Alles sieht professionell aus. Aber wenn die Stakeholder nicht diskutieren, das Product Backlog sich nicht ändert und unbequeme Signale gemittelt werden, hat das Team eine Präsentation abgehalten, kein Review.

Retro ohne Veränderung. In der Retrospective schlägt die KI Root Causes und Action Items vor. Aber wenn die Menschen nicht bereit sind, ehrlich zu sprechen, wenn es keinen Owner, keine Wirkungsprüfung und keinen Platz im nächsten Sprint Backlog gibt, ist das keine Improvement. Das ist ein Verbesserungsprotokoll ohne Verbesserung.

Alle fünf Anti-Patterns haben dieselbe Natur: Die KI senkt die Kosten der Form, aber die Form beginnt, Inhalt vorzutäuschen. Genau deshalb wurden in den Artikeln der Serie so oft die Quellen zu Overreliance, Confabulation, Misinformation, Information Integrity, Privacy und Human Oversight wiederholt: NIST AI Risk Management Framework 1.0, NIST Generative AI Profile und OWASP Top 10 for LLM Applications 2025 beschreiben diese Risikoklassen auf der Ebene von KI-Systemen gut. Im Scrum-Team zeigen sie sich sehr konkret: als zu starkes Vertrauen in einen schönen Entwurf.

Was im Team stärker werden muss

Wenn die KI die Vorbereitung beschleunigt, könnte das Team fälschlich annehmen, es brauche weniger Disziplin. In der Praxis ist es umgekehrt. Je schneller Entwürfe entstehen, desto wichtiger wird die Disziplin der Prüfung.

Ich würde fünf Teamfähigkeiten hervorheben, die wichtiger statt weniger wichtig werden.

Erstens: Fakten von Annahmen trennen. In jedem KI-Input muss sichtbar sein, was aus Quellen stammt, was eine Interpretation des Modells ist und was eine Arbeitshypothese ist. Das ist besonders wichtig in Refinement, Planning und Review, wo ein Fehler leicht zu einem Backlog Item oder einer Produktentscheidung wird.

Zweitens: nicht nur Vollständigkeit prüfen, sondern auch plausible Glätte. Ein guter Reviewer eines KI-Entwurfs fragt nicht „Was fehlt noch?“, sondern „Was hier könnte unwahr sein?“, „Welche Abhängigkeit könnte aus der Zusammenfassung verschwunden sein?“, „Welches unangenehme Signal hat das Modell gemittelt?“.

Drittens: KI-Signale nicht als Bewertung von Menschen verwenden. Daily Scrum und Retrospective sind besonders empfindlich gegenüber dieser Grenze. Wenn das Modell Jira, Git, PR Comments und Chats liest, ist der Übergang von Arbeitsanalyse zu verdecktem Monitoring sehr leicht. Das zerstört Vertrauen und macht das Gespräch vorsichtiger. Praktisch bedeutet das: work and system analysieren, not people.

Viertens: Owner für die Prüfung benennen. Den Geschäftssinn prüft der Product Owner. Die Kohärenz der Anforderungen — der Analyst. Architekturrestriktionen — die Entwickler. Testability und Failure Modes — QA. UX-Grenzen — der Designer. Die Qualität des Meetings und der Teamvereinbarung — der Scrum Master. Die KI kann einen gemeinsamen Entwurf vorbereiten, aber sie kann nicht der Owner der Prüfung sein.

Fünftens: Entscheidungen bis zur Veränderung der Arbeit bringen. Wenn sich als Ergebnis des Sprint Review das Product Backlog nicht geändert hat und als Ergebnis der Sprint Retrospective kein überprüfbares Next-Sprint-Experiment entstanden ist, hat die KI vielleicht beim Dokument geholfen, aber nicht unbedingt bei Scrum.

Wohin mit der freigewordenen Zeit

Eine der wichtigsten Fragen dieser Serie ist eigentlich nicht technisch. Wenn KI dem Team Zeit bei der Vorbereitung spart, wohin geht diese Zeit?

Schlechte Antwort: sie sofort mit noch mehr Aufgaben zuzuschütten. Dann erhöht KI einfach die Durchsatzdichte und maskiert die Überlastung. Das Team bereitet Aufgaben schneller vor, baut Pläne schneller zusammen, schreibt Statusberichte schneller und veröffentlicht Protokolle schneller, wird aber nicht aufmerksamer für die Qualität von Entscheidungen.

Reifere Antwort: einen Teil der freigewordenen Zeit in das investieren, was früher ständig gegen die Dringlichkeit verloren hat. Den strittigen Kundenkontext prüfen. Die Definition of Done klären. Testdaten vervollständigen. Ein wiederkehrendes Review-Problem aufarbeiten. Die Dokumentation verbessern. Technische Schulden abbauen. Vor einem schwierigen Planning ausschlafen, um ganz ehrlich zu sein.

KI ist nicht dann nützlich, wenn das Team einfach mehr macht. Sie ist nützlich, wenn das Team beginnt, weniger Aufmerksamkeit für das Nacherzählen des Offensichtlichen und mehr Aufmerksamkeit für Entscheidungen aufzuwenden, die früher wegen des Lärms aufgeschoben wurden.

Ein praktischer Weg, KI in Scrum-Events einzuführen

Wenn das Team mich fragen würde, womit man anfangen soll, würde ich nicht mit einer großen „AI-Transformation of Scrum“ beginnen. Ich würde mit einer kleinen Vorbereitungskarte für die Events anfangen.

Bevor man KI in jedes Meeting einführt, sollte man sieben Fragen beantworten:

• welcher Input der Inspektion und Anpassung in diesem Meeting wirklich hilft;
• welche Quellen genutzt werden dürfen und welche nicht;
• wie Fakten, Hypothesen und Interpretationen des Modells getrennt werden;
• wer Business, Architektur, Testing, UX, Daten und Risiken prüft;
• welches Anti-Pattern dieses Meetings KI verstärken kann;
• was als Human Override über einer KI-Empfehlung gelten wird;
• woran das Team erkennt, dass das Event nützlicher und nicht einfach kürzer geworden ist.

Die letzte Frage ist besonders wichtig. Eine kürzere Meetingdauer allein beweist keine Verbesserung. Der Daily Scrum kann kürzer und schlechter werden, wenn das Team aufgehört hat, den Plan anzupassen. Das Sprint Review kann schöner und schwächer werden, wenn das Feedback verschwunden ist. Die Retrospective kann ordentlicher und nutzloser werden, wenn niemand die Action Items umsetzt.

Deshalb würde ich nicht darauf schauen, „wie viele Minuten gespart wurden“, sondern auf lebendigere Anzeichen: Das Team sieht Risiken früher, streitet weniger über Fakten, trennt Unbekanntes besser, ändert das Product Backlog nach dem Review häufiger, passt das Sprint Backlog innerhalb des Sprints ehrlicher an, wählt nach der Retrospective weniger, aber konkretere Improvement Experiments.

Was sich also wirklich ändert

KI verändert die klassischen Scrum-Meetings als Verstärker der vorbereitenden und analytischen Ebene. Sie sammelt schneller Material für das Refinement, Planvarianten für das Planning, Signale für den Daily Scrum, Ergebnis und Feedback für das Sprint Review, Fakten und Muster für die Retrospective.

Aber sie ändert nicht das Grundprinzip: Scrum-Events existieren nicht, um Dokumente, Statusberichte, Demos und Protokolle zu produzieren. Sie existieren für Inspektion und Anpassung. Wenn KI dem Team hilft, die Realität besser zu sehen und schneller zu einer bewussten Entscheidung zu kommen, ist sie nützlich. Wenn KI ein altes Ritual reibungsloser macht, bekommt das Team keine Verbesserung von Scrum, sondern eine beschleunigte Version des alten Problems.

Deshalb ist mein Fazit: KI in Scrum-Events einzuführen lohnt sich nicht als Ersatz für Meetings, sondern als Vorbereitungsebene unter menschlicher Inspektion. KI soll Fakten sammeln, Varianten vorschlagen, Risiken hervorheben, an Entscheidungen erinnern und helfen, Follow-up festzuhalten. Aber das Team sollte sich das bewahren, wofür Scrum überhaupt existiert: Transparenz, Prüfung, Anpassung, Verantwortung und die Fähigkeit, die weitere Arbeit ehrlich zu verändern.

Ein reifes Team fragt nicht: „Welche Meetings können wir jetzt weglassen?“. Es fragt anders: „Welchen Teil des Lärms kann KI übernehmen, damit uns mehr Aufmerksamkeit für Sinn, Wert, Qualität und Verhaltensänderung bleibt?“. Das ist eine weniger effektvolle Frage. Dafür ist sie viel näher an der realen Arbeit eines cross-funktionalen Entwicklungsteams.

Quellen und Orientierung

• Backlog Refinement und KI: was sich wirklich ändert — der erste Artikel der Serie: KI beschleunigt die Vorbereitung von Material für die Diskussion, erzeugt aber das Risiko falscher Klarheit.
• KI-gestütztes Sprint Planning: wie man die Vorbereitung beschleunigt, ohne Verantwortung zu verlieren — der zweite Artikel der Serie: KI beschleunigt Planvarianten, macht den Plan aber ohne Prüfung durch das Team nicht realistisch.
• Daily Scrum und KI: warum der Standup kein Status-Bot werden darf — der dritte Artikel der Serie: KI ist nützlich für Signale, aber gefährlich als Generator täglicher Berichterstattung.
• Sprint Review und KI: warum eine Demo das Gespräch über Wert nicht ersetzt — der vierte Artikel der Serie: KI hilft, Ergebnis und Feedback zu sammeln, ersetzt aber nicht die Anpassung des Product Backlog.
• Sprint Retrospective und KI: warum Verbesserungen nicht an ein Modell delegiert werden dürfen — der fünfte Artikel der Serie: KI bringt Evidence, schafft aber kein Psychological Safety und kein Follow-through.
• Scrum Guide 2020 — der kanonische Rahmen für Scrum-Events, Transparency, Inspection, Adaptation, Sprint Goal, Product Goal, Sprint Backlog, Product Backlog und Accountabilities.
• Scrum Guide Expanded v2026.1 — eine Companion-Quelle auf Basis des Scrum Guide 2020; nützlich für den praktischen Rahmen von KI als supervised decision-making partner, ersetzt aber nicht den Scrum Guide.
• NIST AI Risk Management Framework 1.0 — Risikomanagement für KI, Accountability, Governance und Konfiguration der Mensch-KI-Interaktion.
• NIST Generative AI Profile — Konfabulation, Overreliance, Informationsintegrität, Privacy und menschliche Aufsicht für generative KI.
• OWASP Top 10 for LLM Applications 2025 — Offenlegung sensibler Informationen, Fehlinformationen, excessive agency und operationelle Risiken von LLM-Anwendungen.
• DORA State of AI-assisted Software Development 2025 — vorsichtiger Rahmen: KI verstärkt bestehende organisatorische Praktiken, garantiert aber nicht per se eine Verbesserung der Delivery.
• Lehtinen, Itkonen & Lassenius: Recurring opinions or productive improvements? — empirische Untersuchung von Retrospektiven, Participant Bias, Hard Evidence und wiederkehrenden Themen.
• Amy Edmondson: Psychological Safety and Learning Behavior in Work Teams — klassische Quelle zu Psychological Safety als Bedingung für Team Learning.
• EDPB Opinion 28/2024 und ICO monitoring at work guidance impact assessment — Orientierungshilfen zu personenbezogenen Daten, Transparenz, Verhältnismäßigkeit und Grenzen von Workplace Monitoring.