Ein Produktteam befindet sich am sechsten Tag eines zehntägigen Sprints, und der Scrum Master sieht sich mit drei widersprüchlichen Realitäten konfrontiert. Der Product Owner möchte zusätzlichen Arbeitsumfang in den Sprint aufnehmen, da ein Stakeholder-Review ansteht. Die Entwickler benötigen Klärung zu Tickets, die während der Planung noch unproblematisch erschienen. Die Qualitätssicherung (QA) hat Nachbesserungsbedarf bei einer Story festgestellt, die bereits als „erledigt“ (Done) markiert war. Das Daily Scrum ist zu einem reinen Status-Meeting verkommen, und ein bestimmtes Hindernis wird seit drei Tagen angesprochen, ohne dass sich jemand dafür verantwortlich fühlt. Die Entscheidung, die feststeckt, lautet: Anhalten und neu planen oder den Sprint durchziehen und Überhänge (Spillover) in Kauf nehmen? Die Folgen summieren sich in Form von unnötigem Mehraufwand (Churn), unfertiger Arbeit und einer Flut von Updates, die die eigentlichen Risiken verschleiern. KI kann helfen, diese Reibungsverluste zu verringern – allerdings nur, wenn sie gezielt in Scrum-Abläufe integriert wird, eine klare „Single Source of Truth“ (eindeutige Informationsquelle) gewahrt bleibt und die menschliche Verantwortlichkeit durch eine einfache Arbeitsvereinbarung sichergestellt wird.
Bevor Sie nach Lösungen suchen, gehen Sie den Sprint wie auf einer Zeitachse durch und markieren Sie den Punkt, an dem die Probleme begannen.
Die meisten Teams suchen die Ursache in der Umsetzung, doch der erste Fehler passiert meist schon früher: wenn das Refinement übersprungen wird und Unklarheiten in die Planung übernommen werden.
Unklare Tickets verursachen versteckte Arbeit. Eine User Story wirkt klein, doch es fehlen Akzeptanzkriterien, Abhängigkeiten bleiben unerwähnt und QA-Erwartungen sind nur implizit vorhanden. Die Planung artet dann in Diskussionen aus, weil das Team unterschiedliche Interpretationen schätzt. Nicht die Länge der Meetings ist das eigentliche Problem, sondern dass dort Arbeit geleistet wird, die eigentlich schon im Backlog hätte erledigt sein müssen. Blockaden treten spät auf, weil Annahmen, externe Freigaben oder Anforderungen an die Umgebung nicht dokumentiert wurden – das Team trifft also erst mitten im Sprint auf die Realität. Unübersichtliche Status-Updates entstehen, wenn es kein zentrales Artefakt gibt, das Arbeit in Risiken übersetzt; die Beteiligten füllen diese Lücke dann durch mündliche Berichte.
Prognostizieren Sie, wo die erste vermeidbare Nacharbeit anfallen wird, wenn das Refinement ausfällt, man sich aber dennoch auf ein Sprint-Ziel festlegt. Genau hier lässt sich gezielt ansetzen.
KI ist dann hilfreich, wenn sie den Aufwand für wenig wertschöpfende Entwurfsarbeiten reduziert und die Informationsdichte erhöht – nicht, wenn sie Entscheidungen ersetzt. Ziel sind Ergebnisse, die in bestehende Scrum-Artefakte wie Product Backlog, Sprint Backlog und Impediment-Liste einfließen. Setzen Sie KI je nach Phase unterschiedlich ein: Das Refinement profitiert von Entwürfen und Risiko-Hinweisen, die vage Anforderungen in testbare Akzeptanzkriterien verwandeln. Die Planung profitiert von der Zusammenfassung von Scope-Optionen sowie Prognosen auf Basis von Kapazität und Abhängigkeiten. Das Daily Scrum profitiert von prägnanten Zusammenfassungen, die Änderungen (Deltas) hervorheben, statt vollständige Transkripte zu liefern. Die Umsetzung profitiert von Risikowarnungen, wenn Arbeitselemente zu lange liegen bleiben oder zwischen Status-Phasen hin- und herwechseln. Das Review profitiert von schlüssigen Release-Notes, die aus abgeschlossenen Stories generiert werden. Die Retrospektive profitiert von der thematischen Gruppierung von Beobachtungen, sodass sich das Team auf die Auswahl von Maßnahmen konzentrieren kann, statt Kommentare zu sortieren.
Ordnen Sie jeder Zeremonie den KI-Anwendungsfall zu, der genau jene Reibungspunkte beseitigt, die im Sprint-Verlauf aufgefallen sind.
Betrachten Sie die Ergebnisse der KI als Vorschläge, die den Austausch beschleunigen, nicht als verbindliche Zusagen.
Das Vertrauen geht am schnellsten verloren, wenn man der KI erlaubt, Inhalte zu erstellen, die zwar offiziell wirken, aber fehlerhaft, sensibel oder nicht nachvollziehbar sind. Legen Sie vorab drei Leitplanken fest. „Prüfung vor Übernahme“ bedeutet, dass ein Mensch den KI-Entwurf prüft und bearbeitet, bevor dieser Teil des Backlogs, eines Stakeholder-Updates oder eines Entscheidungsprotokolls wird. „Quelle der Wahrheit“ bedeutet, dass die KI niemals zum maßgeblichen System der Datenspeicherung (System of Record) wird. Maßgeblich bleiben weiterhin Ihre Tools und Artefakte, wie etwa die Beschreibung des Backlog-Items, die Abnahmekriterien und das Sprint-Ziel. „Menschliche Verantwortung“ bedeutet, dass jedes KI-gestützte Ergebnis einen Verantwortlichen hat, der dafür geradesteht – genau wie bei jedem anderen Arbeitsergebnis.
Wählen Sie die Strenge der Leitplanken abhängig davon, wie autonom die KI agieren soll, wie sensibel die Daten sind und ob eine lückenlose Nachvollziehbarkeit (Audit Trail) erforderlich ist.