Daily Scrum und KI: Warum das Standup kein Status-Bot werden darf

Dies ist der dritte Artikel aus der Serie darüber, wie KI die klassischen Meetings eines cross-funktionalen Entwicklungsteams verändert. Im ersten Artikel habe ich Backlog Refinement untersucht und gezeigt, dass KI die Vorbereitung von Material beschleunigt, aber die Teamprüfung des Sinns nicht ersetzt. Im zweiten Artikel ging es um Sprint Planning: KI kann einen Entwurf des Plans erstellen, aber keine Teamverpflichtung übernehmen. Nun ist es logisch, zum Daily Scrum überzugehen und zu betrachten, warum der gefährlichste Fehler hier darin besteht, die lebendige Synchronisation in einen automatischen Status-Bot zu verwandeln.

Das Daily Scrum scheint ein idealer Kandidat für Automatisierung zu sein. Commits gibt es in Git, Aufgaben gibt es in Jira, Pull Requests gibt es in GitHub oder GitLab, Incidents gibt es im Monitoring, die Korrespondenz gibt es in Slack oder Teams. KI kann schnell eine kurze Zusammenfassung erstellen: wer gestern was gemacht hat, was sich bei den Aufgaben geändert hat, wo Blocker hängen, welche PRs lange ohne Review sind, welche Tickets sich nicht bewegt haben, welche Bugs in der Nähe des aktuellen Arbeitsumfangs aufgetreten sind.

Auf den ersten Blick sieht das wie ein fast offensichtlicher Gewinn aus. Weniger sich wiederholender Status. Weniger synchrone Meetings. Weniger manuelles Nacherzählen. Besonders in verteilten Teams, in denen Menschen in verschiedenen Zeitzonen arbeiten und nicht jeden Tag einen gemeinsamen Slot damit verbringen wollen, durchzusprechen, was ohnehin in den Tools sichtbar ist.

Aber hier gibt es eine wichtige Falle.

Das Daily Scrum existiert nicht für die Berichterstattung. Seine Aufgabe ist es, den Entwicklern zu helfen, den Fortschritt zum Sprint Goal zu prüfen, das Sprint Backlog anzupassen und die nächste Arbeit zu koordinieren. Wenn KI das Daily Scrum in einen automatischen Bericht über die gestrige Aktivität verwandelt, kann das Team einen akkurateren Status erhalten, aber das Wichtigste verlieren: das lebendige Erkennen von Problemen, shared awareness und die Verantwortung für den nächsten Schritt.

„KI kann einen Teil des Status-Lärms entfernen, aber das Daily Scrum ist nicht wegen des Status wertvoll, sondern wegen der Anpassung des Plans.“

Wozu das Daily Scrum dient

Im Scrum Guide 2020 wird das Daily Scrum recht streng beschrieben: Es ist ein 15-minütiges Event für die Entwickler, dessen Ziel es ist, den Fortschritt zum Sprint Goal zu prüfen und bei Bedarf das Sprint Backlog anzupassen, indem der Plan für die nächste Arbeit geändert wird. Es ist kein Bericht an den Product Owner. Keine morgendliche Kontrolle durch den Scrum Master. Keine reihum aufgezählten Aufgaben. Und kein tägliches Beschäftigungsprotokoll.

Als zusätzliche Orientierung ist auch der Scrum Guide Expanded v2026.1nützlich, aber genau als Companion-Quelle, nicht als neue kanonische Version des Scrum Guide. Für diesen Artikel ist er als praktischer Rahmen wichtig: Das Daily Scrum wird dort als gemeinsame Aktualisierung eines actionable plan beschrieben, und die Flow-Logik ist sehr präzise formuliert — auf feststeckende Arbeit schauen, nicht auf „unbeschäftigte“ Menschen. Bei einem AI-assisted Daily ist das entscheidend: KI sollte Risiken, Impediments und feststeckende Elemente des Sprint Backlog hervorheben und nicht Menschen in Zeilen eines täglichen Berichts verwandeln.

Der Sinn des Daily Scrum entsteht dort, wo das Team sich jeden Tag eine praktische Frage stellt: Was haben wir seit dem letzten Mal gelernt und wie verändert das unseren Plan für die nächsten vierundzwanzig Stunden? Wenn die Antwort lautet „es verändert nichts“, kann das Meeting sehr kurz sein. Wenn die Antwort lautet „wir haben ein Risiko für das Sprintziel“, wird das Daily Scrum zum Ort schneller Koordination: wer sich nach dem Meeting mit wem synchronisiert, welcher Blocker eskaliert wird, was aus dem Arbeitsumfang entfernt werden muss, welche Abhängigkeit geprüft werden muss, welche Aufgabe besser nicht begonnen wird.

Deshalb würde ich den Zweck des Daily Scrum über fünf Funktionen beschreiben:

• Synchronisation des Teams rund um das Sprint Goal;
• schnelles Erkennen von Problemen und Blockern;
• Koordination der nächsten Arbeit;
• Aufrechterhaltung von shared awareness über den Zustand des Sprints;
• Anpassung des Plans, nicht nur Informationsaustausch.

Das ist ein wichtiger Rahmen für das Gespräch über KI. Wenn ein Tool dem Team hilft, diese Funktionen besser zu erfüllen, ist es nützlich. Wenn es einfach den Statusbericht schöner macht, kann es bequem sein, verbessert aber nicht unbedingt die Delivery.

Was üblicherweise schiefgeht

Das Problem des Daily Scrum liegt selten darin, dass die Leute die „drei Fragen“ nicht kennen. Das Problem liegt darin, dass das Event mit der Zeit in ein gewohntes Managementmuster degeneriert: Jeder berichtet der Reihe nach, was er gemacht hat, was er machen wird und ob es Blocker gibt. Manchmal ist das als minimale Disziplin nützlich, aber sehr oft ersetzt ein solches Format unbemerkt die Teamkoordination durch individuelle Berichterstattung. Scrum.org behandelt genau dieses Anti-Pattern im Material Daily Scrum is not a status meeting: Wenn die Entwickler an jemand anderen berichten, hört das Event auf, ein Mechanismus für self-management und Plananpassung zu sein.

Dann beginnt das Meeting gegen sein eigenes Ziel zu arbeiten. Die Entwickler sprechen in Richtung des Scrum Masters oder des Managers, nicht miteinander. Blocker werden zu spät oder zu milde benannt. Abhängigkeiten werden nicht besprochen, weil „das ist ja schon ein Detail“. Die Leute zählen Aktivitäten auf, sagen aber nicht, ob sie dem Sprint Goal näher gekommen sind. Das Team erfährt erst am Ende des Sprints, dass der Plan auseinandergelaufen ist, wenn es schon schwierig ist, etwas ohne Qualitätsverlust anzupassen.

Im AI-assisted-Kontext kann sich dieses Problem verstärken. Wenn das Modell jeden Tag eine kurze Zusammenfassung zu Jira, Git und Slack generiert, gewöhnt sich das Team schnell an den Gedanken, dass „der Status schon erfasst ist“. Dann wird der Daily Scrum noch formeller: Die Leute schauen auf die AI-Kurzzusammenfassung, bestätigen sie, fügen manchmal ein paar Sätze hinzu und gehen auseinander.

Sieht effizient aus. Aber die Frage ist nicht, ob der Status erfasst wurde. Die Frage ist, ob das Team seinen Plan geändert hat, wenn sich die Realität geändert hat.

Wo AI tatsächlich hilft

AI hat im Daily Scrum einen durchaus praktischen Nutzungsbereich. Er kann die routinemäßige Statuskommunikation reduzieren und Signale an die Oberfläche bringen, die Menschen im täglichen Strom leicht übersehen. Das ist besonders wertvoll in Teams mit vielen Quellen: Issue Tracker, Pull Requests, CI/CD, Incident Management, Produktanalytik, Support-Tickets, Kalender, Dokumentation, Korrespondenz.

Aber hier ist es wichtig, nicht zu viel zu versprechen. Selbst der aktuelle DORA State of AI-assisted Software Development 2025 beschreibt AI eher als Verstärker bestehender organisatorischer Praktiken denn als eigenständige Garantie für besseres Delivery. Für den Daily Scrum bedeutet das eine einfache Sache: Wenn das Team bereits in der Lage ist, Sprint Goal, Risiken und Plananpassung zu besprechen, kann AI den Einstieg ins Gespräch reicher machen. Wenn der Daily längst zu einem Statusritual geworden ist, macht AI dieses Statusritual einfach schneller und schöner.

Ein guter AI-Assistent kann vor dem Daily Scrum nicht „wer womit beschäftigt war“ sammeln, sondern nützlichen Kontext für die Koordination:

• welche Aufgaben sich länger als erwartet nicht bewegt haben;
• welche Pull Requests Review benötigen oder andere Änderungen blockieren;
• welche Tests oder Builds instabil geworden sind;
• welche Blocker in Chats erwähnt wurden, aber nicht in Jira gelandet sind;
• welche Elemente des Sprint Backlogs das Sprint Goal nicht mehr direkt unterstützen;
• wo neue Abhängigkeiten, Risiken oder konkurrierende Änderungen aufgetaucht sind;
• welche Entscheidungen gestern asynchron getroffen wurden und für das ganze Team sichtbar sein sollten;
• was ein kurzes Follow-up nach dem Daily erfordert und nicht eine Diskussion mit allen.

In einem solchen Modus ersetzt AI den Daily Scrum nicht. Er senkt die Kosten der Vorbereitung darauf. Das Team kommt nicht mit leerem Gedächtnis und nicht mit individuellen Nacherzählungen, sondern mit einem bereits gesammelten Bild der Signale. Das ermöglicht, weniger Zeit für die Wiederherstellung von Fakten und mehr für die Frage „was tun wir jetzt?“ aufzuwenden.

Das setzt die Logik der vorherigen Artikel der Serie fort. Im Refinement half AI, Material für die Diskussion zu sammeln. Im Planning – Varianten des Plans. Im Daily Scrum kann er Signale über den Verlauf des Sprints sammeln. Aber in allen drei Fällen verschwindet der menschliche Teil nicht: Das Team muss prüfen, was wichtig ist, was sich geändert hat und welche Entscheidungen getroffen werden müssen.

Warum AI den Standup nicht in einen Status-Bot verwandeln sollte

Die gefährlichste Version eines AI-assisted Daily Scrum sieht sehr technologisch aus: Jeden Morgen veröffentlicht ein Bot eine kurze Zusammenfassung zu jedem Teilnehmer, eine Liste der gestrigen Commits, den Status der Tickets, offene PRs, wahrscheinliche Blocker und eine Prognose zur Erledigung des Arbeitsumfangs. Manchmal bittet der Bot jeden noch, seinen Status zu bestätigen oder zu korrigieren.

Aus Sicht der Managementkontrolle ist das bequem. Aus Sicht von Scrum kann es eine Degradierung sein.

Erstens bringt ein solches Format den Daily Scrum leicht zur individuellen Berichterstattung zurück. Die Leute beginnen nicht darüber nachzudenken, wie das Team sich dem Sprint Goal nähert, sondern darüber, ob AI ihre persönliche Aktivität korrekt beschrieben hat. Die Aufmerksamkeit verschiebt sich von der Koordination auf reputationsbezogene Verteidigung: „Der Bot hat mein Review nicht berücksichtigt“, „Ich hatte keine Commits, aber ich habe einen Incident bearbeitet“, „Jira spiegelt die tatsächliche Arbeit nicht wider“.

Zweitens kann eine AI-Kurzzusammenfassung ein falsches Gefühl von Shared Awareness erzeugen. Es scheint, dass alle alles wissen, wenn die Kurzzusammenfassung veröffentlicht ist. Aber Shared Awareness ist nicht das Vorhandensein von Text im Kanal. Es ist das gemeinsame Verständnis dessen, was wichtig ist, wo das Risiko liegt, wer sich mit wem synchronisieren muss und wie sich der Plan ändert.

Drittens kann ein automatischer Status schwache Signale verbergen. Echte Probleme zeigen sich oft nicht in den formalen Feldern von Jira, sondern in der Intonation, im Zweifel, in einer unbestimmten Formulierung, in einem kurzen „ich glaube, wir gehen in die falsche Richtung“, in der Spannung zwischen Aufgaben, im Schweigen einer Person, die normalerweise schnell Risiken anspricht. AI kann helfen, einen Teil solcher Signale im Text zu finden, aber er sollte nicht der einzige Mechanismus zur Problemerkennung werden.

Viertens kann das Team beginnen, Eigentum / Verantwortung an das Tool zu delegieren. Wenn der Bot sagt, dass alles in Ordnung ist, dann ist alles in Ordnung. Wenn der Bot keinen Blocker markiert hat, dann gibt es keinen Blocker. Wenn der Bot die Erledigung des Arbeitsumfangs prognostiziert, dann kann man unangenehme Kompromisse nicht diskutieren. Das ist keine Automatisierung des Daily Scrum, sondern eine Verlagerung der Verantwortung an einen Ort, an dem es keine Verantwortung geben kann.

„AI-generated Status kann ein nützlicher Input sein. Er sollte nicht zum Ersatz für das gemeinsame Nachdenken des Teams werden.“

Setzen wir den Fall fort: B2B LMS und E-Mail-Erinnerungen

Nehmen wir denselben Fall aus den ersten beiden Artikeln: B2B-LMS-Plattform, Pflichtkurse, E-Mail-Erinnerungen an Mitarbeitende, die einen Pflichtkurs nicht bis zur Deadline abgeschlossen haben. Beim Planning wählte das Team ein enges Sprint Goal: Das System sendet eine korrekte Erinnerung an aktive Mitarbeitende mit unvollständigem Pflichtkurs vor der Deadline und speichert eine überprüfbare Versandhistorie.

Ohne AI Daily Scrum kann ein solcher Sprint schnell zu einer Sammlung individueller Statusmeldungen werden. Das Backend sagt, es baue den Scheduler. Ein anderes Backend sagt, es schaue sich die Deduplizierung / Beseitigung von Duplikaten an. QA sagt, es bereite Szenarien zur Zeitzone vor. Das Frontend sagt, es warte auf die API des Historienjournals. Der Product Owner hört zu. Der Scrum Master hält das Timing. Formal ist alles gut.

Aber das Team kann das Wesentliche übersehen: Der Scheduler ist fast fertig, aber die Deduplizierung hängt davon ab, welcher Schlüssel im Historienjournal stehen wird; QA kann die Testdaten nicht vorbereiten, solange nicht entschieden ist, wo die Zeitzone gespeichert wird; das Frontend wartet auf die API, aber für das Sprint Goal ist eine vollständige UI möglicherweise gar nicht nötig; der Product Owner hat noch nicht bestätigt, wie man expiredinterpretieren soll, obwohl das Team dies als außerhalb des Arbeitsumfangs betrachtet.

AI kann hier helfen. Vor dem Daily sammelt es Signale: PR zum Scheduler ist offen, aber ohne Review; im Chat wurde gestern das Risiko von Duplikaten diskutiert; das Ticket zum Historienjournal wurde nicht aktualisiert; QA hat einen Kommentar zur Zeitzone hinterlassen; im Backlog Item ist eine neue Klärung vom Kundensupport-Team aufgetaucht. Das ist ein guter Input.

Aber der Wert entsteht erst im Meeting, wenn das Team den nächsten Schritt macht: entscheiden, wer direkt nach dem Daily prüft, den Deduplizierungsschlüssel zu verifizieren, wer die Zeitzonen-Policy bestätigt, was im Rahmen des Sprint Goal als ausreichend für das Historienjournal gilt und ob heute die Arbeit an der UI gestoppt werden soll, um die verfügbare Kapazität des Teams nicht zu verzetteln. AI lieferte Signale. Das Team passte den Plan an.

Anti-Patterns

Im Folgenden finden sich einige Anti-Patterns, die ich bei der Einführung von AI in den Daily Scrum besonders beobachten würde.

1. Der Bot sammelt persönliche Berichte statt Teamkontext

Wenn die AI-Zusammenfassung um Personen statt um das Sprint Goal strukturiert ist, rutscht das Team schnell in ein Statusformat. Nützlicher ist es, Signale nach Ziel, Risiken, Abhängigkeiten und Entscheidungen zu gruppieren, die Koordination erfordern.

2. Das Team bestätigt die Zusammenfassung statt den Plan anzupassen

Wenn der Daily Scrum zu „Ja, der Bot hat alles richtig geschrieben“ wird, verliert das Event seinen Sinn. Eine gute Frage ist nicht „Ist der Status korrekt?“, sondern „Was davon ändert unseren Plan für heute?“.

3. AI prognostiziert die Sprint-Erledigung, als wäre es objektive Wahrheit

Eine Prognose kann ein nützliches Signal sein, aber sie sollte das Gespräch über Risiken nicht ersetzen. Besonders wenn das Modell sich auf Velocity, die Anzahl geschlossener Tickets oder Aktivität im Repository stützt, ohne Verständnis für Komplexität, Qualität, Abhängigkeiten und Definition of Done.

4. Blocker werden nur in Systemen gesucht

Nicht alle Blocker hinterlassen eine digitale Spur. Manchmal liegt das Problem in einer unklaren Entscheidung, der Angst, eine unangenehme Frage zu stellen, einem Prioritätskonflikt, der Müdigkeit des Teams oder einer verborgenen Abhängigkeit von einer Person außerhalb des Teams. AI kann helfen, sollte aber das Aufmerksamkeitsfeld nicht auf das verengen, was sich leicht aus Tools extrahieren lässt.

5. Das Daily wird zum Kanal der Aktivitätskontrolle

Wenn AI beginnt, die „Nützlichkeit“ von Menschen anhand von Commits, Kommentaren, geschlossenen Aufgaben oder Reaktionszeiten zu messen, optimiert sich das Team schnell auf sichtbare Aktivität. Das zerstört Vertrauen und verschlechtert die Qualität der Informationen, die Menschen bereit sind, in den Daily Scrum einzubringen.

6. Eine asynchrone Zusammenfassung ersetzt das Gespräch dort, wo Koordination nötig ist

Asynchronität ist nützlich für die Weitergabe von Fakten. Aber wenn ein Risiko für das Sprint Goal besteht, ein Abhängigkeitskonflikt vorliegt oder der Plan schnell geändert werden muss, ist ein Live-Gespräch in der Regel günstiger als eine lange Kommentarkette.

Wie sich die Rollen verändern werden

AI hebt die Rollen innerhalb des Scrum Team nicht auf, aber verändert den Schwerpunkt in der täglichen Koordination. Weniger Wert liegt im manuellen Nacherzählen von Fakten. Mehr Wert liegt im Prüfen von Signalen, im Treffen von Entscheidungen und im Aufrechterhalten der Teamverantwortung.

Rolle	Risiko bei einem schlechten AI-Szenario	Reife Nutzung von AI
Entwickler	Bestätigen passiv die AI-Zusammenfassung und verlieren die Gewohnheit, das Sprint Backlog selbst anzupassen.	Nutzen AI-Signale als Input, entscheiden aber selbst, was sich im Plan ändert, wer sich mit wem synchronisiert und welche Kompromisse nötig sind.
Product Owner	Erhält einen bequemen Daily Report und beginnt, den Daily Scrum als Transparenzkanal für sich selbst zu betrachten.	Hilft, Value, Arbeitsumfang und Nicht-Umfang schnell zu klären, wenn beim Team ein Risiko für das Sprint Goal entsteht.
Scrum Master	Übergibt die Moderation an den Bot und achtet nur darauf, dass die Leute ihre Status aktualisieren.	Schützt das Daily Scrum davor, zu einer Berichterstattung zu werden, hilft dem Team, Risiken, Blocker und die Anpassung des Plans zu besprechen.
Qualitätsingenieur / QA-Ingenieur	Erhält eine lange Liste KI-generierter Checks und erzeugt den Anschein von Abdeckung.	Nutzt KI, um vorläufige Risiken zu finden, prüft aber manuell Testbarkeit, Beobachtbarkeit, Daten und reale Failure Modes.
UX/UI-Designer	Fällt aus dem Daily heraus, weil die KI-Kurzfassung sich auf Code, PRs und Entwicklungsaufgaben konzentriert.	Hebt UX-Abhängigkeiten, Entscheidungen zum Arbeitsumfang und Fragen hervor, die das Sprint Goal und den Nutzerwert beeinflussen.
Engineering Lead / Tech Lead	Beginnt, die KI-Kurzfassung als Management-Aktivitätsdashboard zu lesen.	Nutzt die Kurzfassung zur Früherkennung technischer Risiken, Review-Bottlenecks, Integrationskonflikte und versteckter Abhängigkeiten.

Praktischer Filter für ein KI-gestütztes Daily Scrum

Ich würde nicht mit der Einführung eines „KI-Standup-Bots“ beginnen. Ich würde mit einer engeren Frage beginnen: Welche Signale helfen dem Team, den Sprintplan schneller anzupassen? Danach kann KI als vorbereitende Schicht genutzt werden, nicht als Ersatz für das Event.

Eine KI-Kurzfassung vor dem Daily ist nützlich, wenn sie hilft, folgende Fragen zu beantworten:

• Hat sich das Risiko für das Erreichen des Sprint Goals verändert?
• Was ist blockiert oder wird bald blockiert sein?
• Welche Abhängigkeiten erfordern heute eine Live-Koordination?
• Welche Entscheidungen wurden asynchron getroffen und müssen für das ganze Team sichtbar werden?
• Wo gibt es eine Diskrepanz zwischen Jira-Status und dem tatsächlichen Arbeitsstand?
• Welche Follow-up-Gespräche sind nach dem Daily nötig und wer nimmt daran teil?
• Was sollte das Team aufhören zu tun, wenn das Sprint Goal gefährdet ist?

Und umgekehrt: Wenn die KI-Kurzfassung hauptsächlich die Frage beantwortet „wer womit beschäftigt war“, ist das kein Daily Scrum. Das ist Berichterstattung. Sie kann in der Organisation nötig sein, aber man sollte sie nicht mit der teamlichen Inspektion und Anpassung verwechseln.

Governance und Datenhygiene

Das Daily Scrum ist besonders datensensibel, weil eine KI-Zusammenfassung leicht beginnt, Informationen aus persönlichen Nachrichten, Kalendern, Review-Kommentaren, Produktionsvorfällen, Support-Tickets und internen Diskussionen zu sammeln. Je breiter der Zugriff, desto überzeugender die Kurzfassung. Aber desto höher das Risiko übermäßiger Beobachtung, von Kontextlecks und übermäßiger Abhängigkeit von einer selbstsicheren, aber unvollständigen Schlussfolgerung des Modells. Genau diese Risikoklassen sind gut beschrieben in NIST Generative AI Profile und in OWASP Top 10 for LLM Applications 2025.

Das Team sollte im Voraus vereinbaren, welche Quellen für KI erlaubt sind, welche Felder ausgeschlossen werden, wer die Kurzfassung sieht, wie lange sie gespeichert wird und ob sie zur Bewertung individueller Produktivität verwendet werden darf. Der letzte Punkt ist kritisch. Wenn Menschen das Gefühl bekommen, dass die KI-Kurzfassung im Daily als Proxy für Leistungskontrolle verwendet wird, beginnen sie, ihr Verhalten auf die Metriken hin zu optimieren, und bringen keine unbequemen Signale mehr ein. Das ist keine Frage eines „bequemen Standups“ mehr, sondern eine Frage der Mitarbeiterüberwachung: regulatorische Orientierungshilfen wie ICO monitoring at work impact assessment und EDPB Opinion 28/2024 sind nützlich, nicht als juristische Anleitung für den Artikel, sondern als Erinnerung an Erforderlichkeit, Verhältnismäßigkeit, Datenminimierung und Transparenz.

Praktisch bedeutet das: keine überflüssigen personenbezogenen Daten in das Modell ziehen, keine privaten Chats ohne ausdrücklichen Grund analysieren, keine Aktivitätsrankings erstellen, Delivery-Signale nicht mit Performance Management vermischen und Fakten von Annahmen trennen. KI sollte dem Team helfen, die Arbeit zu sehen, und nicht zu einem Mechanismus der Beobachtung von Menschen werden.

Praktisches Fazit

KI kann das Daily Scrum tatsächlich nützlicher machen. Sie kann einen Teil des wiederkehrenden Status entfernen, Fakten im Voraus sammeln, Blocker hervorheben, Review-Bottlenecks finden, Diskrepanzen zwischen Aufgaben und Realität bemerken, an gestrige Entscheidungen erinnern und eine kurze Liste von Themen für die Koordination vorbereiten.

Aber das funktioniert nur, wenn das Team die Grenze versteht: KI bereitet den Input vor, führt aber nicht das Daily Scrum durch. Sie hilft, Signale zu sehen, entscheidet aber nicht, was damit zu tun ist. Sie kann eine Kurzfassung vorschlagen, erzeugt aber nicht von sich aus gemeinsames Bewusstsein. Sie kann ein Risiko bemerken, übernimmt aber keine Verantwortung für die Anpassung des Plans.

Deshalb würde ich die Kernthese so formulieren: KI sollte die Kosten der Statuskommunikation senken, damit dem Team mehr Aufmerksamkeit für die Koordination bleibt. Wenn das Gegenteil geschieht und das Daily Scrum zu einem KI-generierten Status Reporting wird, verliert das Team genau das, wofür das Event existiert: lebendige Synchronisation, frühes Erkennen von Problemen, gemeinsame Verantwortung und die Fähigkeit, den Plan schnell zu ändern.

Ein reifes Team fragt nicht: „Können wir das Standup durch einen Bot ersetzen?“. Es fragt anders: „Welchen Teil des Status-Lärms kann KI entfernen, damit unser Daily Scrum ein ehrlicheres Gespräch über das Sprint Goal und den nächsten Plan wird?“. Das ist eine viel weniger effektvolle Formulierung. Dafür ist sie näher an der realen Delivery-Praxis.

Quellen und Orientierungshilfen

• Scrum Guide 2020 — Daily Scrum, Sprint Goal, Sprint Backlog, Entwickler, Inspektion und Anpassung.
• Scrum Guide Expanded v2026.1 — Companion-Quelle auf Basis des Scrum Guide 2020: praktische Rahmung des Daily Scrum, umsetzbarer Plan, Risiken / Impediments und Flow-Ansatz „idle work, not idle people“.
• Scrum.org: What is a Daily Scrum? — praktische Erläuterung des Zwecks des Daily Scrum und des Zusammenhangs mit dem Sprint Goal.
• Scrum.org: Daily Scrum is not a status meeting — warum das Daily Scrum nicht zu individueller Berichterstattung werden sollte.
• NIST-Framework zum Management von KI-Risiken 1.0 — Steuerung / Regulierung, Rechenschaft / Verantwortlichkeit, Konfiguration der Mensch-KI-Interaktion.
• NIST-Profil für generative KI — übermäßige Abhängigkeit, Konfabulation / selbstsicheres Erfinden, Privatsphäre und menschliche Kontrolle.
• OWASP Top 10 for LLM Applications 2025 — Offenlegung sensibler Informationen, misinformation, excessive agency und operationelle Risiken von LLM-Anwendungen.
• DORA State of AI-assisted Software Development 2025 — KI als Verstärker organisatorischer Praktiken, nicht als eigenständige Garantie für verbesserte Delivery.
• EDPB Opinion 28/2024 und ICO monitoring at work impact assessment — Orientierungshilfen zu personenbezogenen Daten, Minimierung, Transparenz und Überwachung von Beschäftigten.