AI-assisted Sprint Planning: Wie man die Vorbereitung beschleunigt, ohne Verantwortung zu verlieren

Dies ist der zweite Artikel aus der Serie darüber, wie AI die klassischen Meetings eines cross-funktionalen Entwicklungsteams verändert. Im ersten Artikel habe ich Backlog Refinement analysiert und bin zur wichtigsten Erkenntnis gekommen: AI beschleunigt nicht die Vereinbarung des Teams selbst, sondern die Vorbereitung des Materials dafür. Jetzt ist es logisch, zum nächsten Schritt überzugehen — Sprint Planning — und zu schauen, wie man die Vorbereitung darauf beschleunigen kann, ohne die Verantwortung des Teams für Ziel, Umfang und Realismus des Sprints zu verlieren.

Auf den ersten Blick scheint es, dass Planning nach einem guten Refinement fast zu einer technischen Formalität werden müsste. Die Backlog-Elemente sind bereits verfeinert, Akzeptanzkriterien skizziert, Risiken notiert, offene Fragen teilweise geklärt, Varianten des technischen Ansatzes vorbereitet. Es bleibt nur noch, Aufgaben für den Sprint auszuwählen und sie auf die Personen zu verteilen.

Aber genau das ist die Falle.

Sprint Planning in Scrum ist kein Meeting zum Verteilen von Aufgaben. Es ist ein Event, bei dem das Team drei wichtigere Fragen beantwortet: Warum ist dieser Sprint wertvoll, was kann im Sprint tatsächlich erledigt werden und wie wird die ausgewählte Arbeit ausgeführt. Und wenn man AI durch diese Brille betrachtet, wird das Wesentliche sichtbar: AI kann dem Team tatsächlich helfen, schneller Planvarianten zusammenzustellen, Abhängigkeiten hervorzuheben, eine Dekomposition vorzuschlagen und Fragen vorzubereiten. Aber sie kann keine Verantwortung für das Sprint Goal übernehmen und den Plan nicht aus sich selbst heraus realistisch machen.

„AI hilft, einen Plan zusammenzustellen, der einem realistischen ähnelt. Realistisch macht ihn nur das Team.“

Genau darin besteht meiner Meinung nach die wichtigste Verschiebung. AI beschleunigt die Vorbereitung auf das Sprint Planning, ersetzt aber nicht das Sprint Planning selbst als Teamvereinbarung über Ziel, Umfang und Art der Lieferung.

Warum Sprint Planning nicht einfach „Aufgaben für den Sprint sammeln“ ist

Im Scrum Guide 2020 wird Sprint Planning als das Event beschrieben, das den Sprint einleitet. Sein Ergebnis entsteht durch die gemeinsame Arbeit des gesamten Entwicklungsteams.

Sprint Planning ist um drei Themen herum aufgebaut

• Warum ist dieser Sprint wertvoll?
• Was kann in diesem Sprint erledigt werden?
• Wie wird die ausgewählte Arbeit ausgeführt?

Das ist eine wichtige Reihenfolge. Zuerst keine Aufgabenliste, sondern Wert. Nicht „was wir schaffen abzuschließen“, sondern „welche Veränderung wir bis zum Ende des Sprints erreichen wollen“. Genau deshalb ist das Sprint Goal keine dekorative Zeile in Jira und keine schöne Kurzzusammenfassung der ausgewählten Aufgaben. Es ist das eine Ziel des Sprints, also ein gemeinsames Ziel, das dem Team Fokus gibt und es ermöglicht, Entscheidungen zu treffen, wenn innerhalb des Sprints neue Fakten auftauchen.

Das Sprint Backlog besteht dabei aus drei Teilen: dem Sprint Goal als „Warum“, den ausgewählten Backlog-Elementen als „Was“ und einem actionable plan als „Wie“. Und besonders wichtig ist, dass das Sprint Backlog ein Plan ist, der von Entwicklern und für Entwickler erstellt wird. Der Product Owner hilft, die Diskussion vorzubereiten und die ausgewählte Arbeit mit dem Product Goal zu verbinden, der Scrum Master hilft, dass das Event nützlich und produktiv ist, aber der Ausführungsplan und die Verantwortung für den Realismus des ingenieurtechnischen Teils bleiben innerhalb des Entwicklungsteams.

Daraus folgt eine einfache, aber sehr wichtige Schlussfolgerung für das Gespräch über AI: Das Werkzeug kann eine Formulierung des Sprint Goals, eine Liste vorläufiger Backlog-Elemente, Abhängigkeiten, Risiken und eine Dekomposition vorschlagen. Aber es kann nicht Träger der Teamverpflichtung sein. Es kann nicht für das Team sagen: „Wir sind wirklich bereit, das zu übernehmen“.

Was AI im Planning tatsächlich verändert

Ich benenne sofort die Grenze der Belege. Heute gibt es wenig solide Forschungsbasis speziell zu AI-assisted Sprint Planning in realen Scrum-Teams. Deutlich mehr Arbeiten gibt es zu angrenzenden Themen: Requirements Engineering, Qualität von User Stories, Aufwandsschätzung, Testgenerierung, menschliche Entscheidungsfindung gemeinsam mit AI und Risikomanagement von AI. Daher ist es korrekter, nicht von „AI plant den Sprint“ zu sprechen, sondern von „AI beschleunigt das Zusammenstellen eines zu diskutierenden Entwurfsplans und hilft dem Team, einen Teil der Lücken früher zu sehen“. Das ist ein wichtiger Unterschied.

Vor dem Aufkommen von AI war die Vorbereitung auf Sprint Planning oft ziemlich manuell. Der Product Owner sah sich im Voraus die Prioritäten an und versuchte, einen vorläufigen Arbeitsumfang zusammenzustellen. Der Analyst prüfte, wie bereit die Backlog-Elemente für die Diskussion waren. Die Entwickler erinnerten sich an technische Einschränkungen und ähnliche Aufgaben. QA brachte Testrisiken ein. Der Scrum Master achtete darauf, dass das Meeting nicht zu einem chaotischen Streit über Details wurde, die früher hätten geklärt werden müssen.

Mit KI kann diese Vorbereitungsschicht deutlich schneller werden – vorausgesetzt, das Team hat einen hochwertigen Eingangskontext und einen klaren Prozess zur Überprüfung des Ergebnisses. Das Modell kann helfen, mehrere Varianten des Sprint Goals zu formulieren, Backlog-Elemente um das Ziel zu gruppieren, Schwachstellen in den Akzeptanzkriterien hervorzuheben, eine Liste von Abhängigkeiten vorzuschlagen, ähnliche Aufgaben in der Historie zu finden, Risiken zu skizzieren und Fragen für QA, Backend, Frontend und Design vorzubereiten. Aber das ist kein Beweis dafür, dass das finale Planning immer schneller oder präziser wird: Ein Teil des Gewinns kann für die menschliche Prüfung, die Überprüfung der Quellen und die Korrektur von Fehlern im Entwurf draufgehen.

Das ist besonders nützlich, wenn das Team zum Planning kommt, nachdem es ein KI-gestütztes Refinement durchlaufen hat. Im vorherigen Artikel habe ich gezeigt, dass KI hilft, eine rohe Anfrage schneller in ein reiferes Backlog-Element zu verwandeln. Aber jetzt stellt sich die nächste Frage: Wenn die Backlog-Elemente besser aussehen, bedeutet das, dass auch der Plan besser geworden ist?

Nicht unbedingt.

KI kann die Planungsartefakte ordentlicher machen. Sie kann das Gefühl erzeugen, dass alles schon zusammenhängt: hier das Sprint Goal, hier der Arbeitsumfang, hier die Risiken, hier die Abhängigkeiten, hier die Notizen zum Testen. Aber das ist noch kein Plan. Das ist ein Planentwurf. Und der Wert von Sprint Planning liegt genau darin, dass das Team diesen Entwurf an der Realität prüft.

KI hilft, schneller Varianten für Sprint Goal, Arbeitsumfang, Abhängigkeiten und Risiken zusammenzustellen, ersetzt aber nicht die teamseitige Prüfung der Realisierbarkeit des Plans.

Wir setzen denselben Fall fort: B2B-LMS und E-Mail-Erinnerungen

Um nicht abstrakt zu bleiben, setze ich den Fall aus dem ersten Artikel fort.

Es gibt eine B2B-LMS-Plattform für betriebliche Weiterbildung. Große Kunden weisen ihren Mitarbeitenden Pflichtkurse zu Compliance, Sicherheit und internen Richtlinien zu. Das Business möchte automatische E-Mail-Erinnerungen an Mitarbeitende hinzufügen, die einen Pflichtkurs bis zur Frist nicht abgeschlossen haben.

Beim Refinement hat das Team bereits herausgefunden, dass die Aufgabe nur einfach erscheint. Tatsächlich muss man sich verständigen:

• wen man als für die Erinnerung berechtigt betrachtet;
• ob nur Pflichtkurse berücksichtigt werden;
• welche Status berücksichtigt werden: not_started, in_progress, expired;
• wie man archived und deaktivierte Nutzer ausschließt;
• wo die Zeitzone gespeichert ist;
• wie die Spracheinstellung und der Sprach-Fallback funktionieren;
• wie man sich bei einem erneuten Lauf des Scheduler-Jobs vor Duplikaten schützt;
• ob ein Verlaufsprotokoll / Audit-Log benötigt wird;
• was das Kundensupport-Team sehen können muss;
• wo der minimale Arbeitsumfang der ersten Version endet.

Nach einem guten Refinement kann das Team zum Sprint Planning bereits mit einer starken Vorlage kommen. Zum Beispiel hat KI geholfen, einen Entwurf der User Story, Akzeptanzkriterien, eine Liste von Randfällen, Varianten des technischen Ansatzes und offene Fragen zusammenzustellen. Aber beim Planning muss eine andere Art von Entscheidung getroffen werden: was genau das Team in den nächsten Sprint aufnimmt und mit welchem Ziel.

Ein schlechtes Sprint Goal für diesen Fall könnte so aussehen:

„Scheduler, E-Mail-Erinnerungen und Verlaufsprotokoll bauen.“

Formal verständlich, aber das ist einfach eine Liste von Komponenten. Es erklärt nicht, warum der Sprint wertvoll ist, welches minimale Ergebnis entstehen soll und welche Kompromisse zulässig sind.

Eine stärkere Formulierung:

„Das System sendet eine korrekte Erinnerung an aktive Mitarbeitende mit einem nicht abgeschlossenen Pflichtkurs vor der Frist und speichert eine überprüfbare Versandhistorie.“

Diese Formulierung ist besser, weil sie bereits Wert und Grenzen enthält. Wir versprechen kein vollwertiges Kundenpanel. Wir versprechen keine komplexe Erinnerungslogik. Wir lösen nicht sofort alle Streitfragen rund um expired. Wir bauen keine erweiterte Analytik. Aber wir versprechen ein minimal wertvolles Ergebnis: Der richtige Mitarbeitende erhält eine korrekte Erinnerung, und das Team kann prüfen, wem, wann und warum die E-Mail geschickt wurde.

Wie das Planning ohne KI aussehen würde

Ohne KI beginnt ein solches Meeting oft mit dem Wiederherstellen des Kontexts. Der Product Owner erinnert an die Geschäftsanfrage. Die Analystin fasst zusammen, was beim Refinement geklärt werden konnte. Das Backend klärt, wie der Benachrichtigungsdienst funktioniert. Das Frontend fragt, ob ein Einstellungsbildschirm nötig ist oder Backend-Logik ausreicht. QA beginnt, Fragen zu Fristen, Zeitzonen, Duplikaten und Status herauszuziehen. Der Designer versucht zu verstehen, ob im ersten Arbeitsumfang überhaupt UI enthalten ist.

Die Hälfte des Meetings geht nicht für die Wahl eines realistischen Plans drauf, sondern dafür, den Stoff im Kopf des Teams erneut hochzuholen. Irgendwann entsteht die Versuchung, einfach „alles Wichtige mitzunehmen“: Berechtigungsprüfung, Scheduler, E-Mail-Vorlage, Deduplizierung / Beseitigung von Duplikaten, Verlaufsprotokoll, Spracheinstellung-Fallback, Zeitzone, Sichtbarkeit der Informationen für das Kundensupport-Team, Behandlung von expired, Kundeneinstellungen und noch ein paar Randfälle.

Ein solcher Arbeitsumfang kann auf der Ebene des gesunden Menschenverstands vernünftig erscheinen: alles hängt ja zusammen. Aber genau hier beginnt das Planning aufzublähen. Das Team spricht scheinbar über ein ganzheitliches Ergebnis, sammelt aber tatsächlich mehrere unabhängige Unsicherheitsrichtungen. Irgendwo ist die Produktsemantik unklar, irgendwo die technische Umsetzung, irgendwo das Testing, irgendwo die UI, irgendwo der Support.

Infolgedessen kann am Ende des Meetings ein Sprint Backlog entstehen, der vollständig aussieht, aber fragil bleibt. Er baut auf der Hoffnung auf, dass alle strittigen Punkte im Laufe des Sprints geklärt werden. Manchmal ist das so. Aber oft bekommt das Team genau so unfertige Arbeit übertragen, eine versteckte Ausweitung des Arbeitsumfangs und ein unangenehmes Gefühl: „Wir haben doch scheinbar alles besprochen“.

Wie sich das Planning mit AI verändert

Mit AI kann dasselbe Meeting auf einer anderen Ebene beginnen.

Vor dem Planning hilft AI dem Product Owner, mehrere Varianten des Sprint Goal vorzubereiten: eine enge erste Version, einen breiteren kundenseitigen Arbeitsumfang, einen technisch sicheren Arbeitsumfang, einen erweiterten ambitionierten Umfang. Der Analyst bittet AI, die Backlog-Elemente mit jeder Zielvariante zu verknüpfen und zu zeigen, welche davon das Ziel nicht direkt unterstützen. Das Backend lässt durch AI die Beschreibung der Benachrichtigungsarchitektur laufen und bittet darum, die Risiken der Aufgaben des Planers, der Deduplizierung und der Idempotenz hervorzuheben. Frontend und Designer prüfen, ob die UI im ersten Sprint nötig ist oder ob man sich auf eine minimale Anzeige der Historie beschränken kann. QA bittet AI, eine Liste negativer Szenarien, Grenzszenarien und zeitgebundener Szenarien vorzubereiten.

Das Team kommt zum Planning nicht mit einem leeren Blatt, sondern mit einer Reihe von Varianten:

• minimaler Arbeitsumfang: Pflichtkurse, not_started / in_progress, Ausschluss archivierter und deaktivierter Nutzer, eine Erinnerung, Beseitigung von Duplikaten, Verlaufsjournal;
• erweiterter Arbeitsumfang: plus Sprach-Fallback-Einstellung und eine sorgfältigere Zeitzonen-Politik;
• erweiterter ambitionierter Umfang: plus Sichtbarkeit für das Kundensupport-Team;
• außerhalb des Arbeitsumfangs: expired, komplexe Wiederholungsregeln, erweiterte Analytik, individuelle Zeitpläne pro Kunde.

Das spart deutlich kognitive Arbeit. Jetzt verbringt das Team nicht den Großteil des Meetings damit, die Varianten erstmals zu formulieren. Es diskutiert, welche der Varianten realistisch ist, welche das Sprint Goal besser unterstützt und welche Risiken man nicht implizit lassen darf.

Aber genau hier entsteht eine neue Falle. Ein von AI zusammengestellter Plan kann so ordentlich aussehen, dass das Team beginnt, ihn nicht zu prüfen, sondern zu bearbeiten. Nicht zu fragen „Können wir das wirklich?“, sondern nur die Formulierungen zu verbessern. Nicht über die verfügbare Kapazität des Teams zu streiten, sondern der schönen Dekomposition zu vertrauen. Nicht die Abhängigkeiten zu prüfen, sondern anzunehmen, dass sie, wenn sie in der Tabelle stehen, bereits berücksichtigt sind.

Und dann hilft AI dem Planning nicht. Es macht einen überoptimistischen Plan nur überzeugender.

Die Hauptfalle: falsche Realistik des Plans

Im Refinement war das Hauptrisiko die falsche Klarheit: Die Aufgabe wirkt verständlich, weil AI sie schön formatiert hat. Im Sprint Planning ist das Risiko ein anderes — falsche Realistik.

Falsche Realistik entsteht, wenn ein Plan zusammenhängend, vollständig und logisch aussieht, aber nicht auf die realen Einschränkungen des Teams geprüft wurde. Er hat ein Sprint Goal, eine Aufgabenliste, Schätzungen, Abhängigkeiten und Risiken. Aber niemand hat wirklich geprüft, ob die verfügbare Kapazität des Teams ausreicht, ob es unfertige Arbeit aus dem letzten Sprint gibt, ob QA überlastet ist, ob der nötige Experte verfügbar ist, ob man die Definition of Done wirklich erreichen kann und ob der schwierigste Teil nicht hinter Worten wie „integrieren“, „Unterstützung hinzufügen“ oder „Grenzfälle berücksichtigen“ versteckt ist.

Dieses Risiko passt gut zu mehreren bekannten Problemen.

Das erste ist der Planungsfehler. Teams neigen ohnehin dazu, die Komplexität zukünftiger Arbeit zu unterschätzen, besonders wenn sie den Plan „von innen“ betrachten und sich auf das gewünschte Szenario konzentrieren. AI kann helfen, wenn es historische Daten, ähnliche Aufgaben, frühere Verzögerungen und typische Ursachen für die Übertragung unfertiger Arbeit hervorhebt. Aber es kann den Planungsfehler auch verstärken, wenn es eine glatte, überzeugende Geschichte erzeugt: „Alles wirkt zusammenhängend, also ist alles realistisch“.

Das zweite ist die Automatisierungsverzerrung. Wenn das System einen ordentlichen Plan vorschlägt, fällt es dem Menschen leichter, vom Modus der aktiven Prüfung in den Modus der passiven Zustimmung zu wechseln. Das Team sucht nicht mehr aktiv nach Widersprüchen, weil „AI alles zusammengestellt hat“. Das ist besonders beim Planning gefährlich, wo die Qualität der Entscheidung nicht von der Vollständigkeit des Textes abhängt, sondern von der Ehrlichkeit der Diskussion über Einschränkungen.

Das dritte ist die Halluzination des Modells oder Konfabulation / überzeugendes Erfinden. AI kann überzeugend eine Abhängigkeit erfinden, die es nicht gibt. Oder auf eine „ähnliche Aufgabe“ verweisen, die tatsächlich nur oberflächlich ähnlich war. Oder eine falsche Schlussfolgerung über Status, Zeitzone, Sprach-Fallback-Einstellung oder architektonische Einschränkung ziehen. Das Problem ist nicht, dass solche Fehler immer grob sind. Im Gegenteil, die gefährlichsten Fehler wirken plausibel.

Die vierte ist die Scheingenauigkeit. Wenn die KI eine schöne Schätzung, einen sauberen Bereich oder eine selbstsichere Abfolge von Schritten liefert, kann bei der Mannschaft ein Gefühl von Genauigkeit entstehen. Aber die Genauigkeit des Plannings entsteht nicht aus einer guten Tabelle. Untersuchungen zur Agile-Aufwandsschätzung zeigen, dass die Qualität der Schätzungen von vielen Faktoren abhängt: der Erfahrung der Mannschaft, der bisherigen Erfahrung, der Größe der Aufgaben, der Qualität der Informationen, der Schätzungspraxis, dem Projektmanagement und geschäftlichen Einflüssen. Deshalb ist es gefährlich zu schreiben oder zu denken, dass die KI „die Schätzungen“ von sich aus „verbessert“. Eine ehrlichere Formulierung: Die KI kann helfen, fehlende Informationen, ähnliche Fälle und instabile Annahmen aufzudecken, aber die Schätzung muss trotzdem von der Mannschaft geprüft werden.

Deshalb beginnt ein reifer Einsatz von KI im Sprint Planning nicht mit der Frage „Welchen Plan hat sie uns zusammengestellt?“, sondern mit der Frage „Was an diesem Plan könnte unwahr, unvollständig oder zu glatt sein?“. Eine gute Mannschaft verbessert nicht einfach den KI-Entwurf, sondern versucht gezielt, ihn zu widerlegen: Sie prüft Quellen, Annahmen, Abhängigkeiten, die verfügbare Kapazität der Mannschaft, die Definition of Done und die Stellen, an denen das Modell selbstsicher mehr verallgemeinert haben könnte, als die Fakten zulassen.

Was sich nach Rollen ändert

Product Owner

Der Product Owner erhält mit KI schneller Varianten des Sprint Goals und des Arbeitsumfangs. Er kann das Modell bitten, mehrere Szenarien zu zeigen: minimal, sicher, ambitioniert, stretch. Er kann schneller sehen, welche Backlog-Elemente das Ziel tatsächlich stützen und welche einfach „auch nützlich“ sind.

Aber die Verantwortung des Product Owners verschwindet nicht. Im Gegenteil, sie wird sichtbarer. Wenn die KI vorschlägt, alles in den Sprint zu nehmen, was zusammenhängend aussieht, muss der Product Owner die Wertfrage hochhalten: Welches minimale Ergebnis wird vom Nutzer oder Stakeholder wirklich gebraucht? Was kann jetzt unterlassen werden? Was zerstört das Sprint Goal, und was ist einfach nice to have?

Business-Analyst

Für den Analysten ist die KI als Werkzeug zur Prüfung der Kohärenz nützlich. Sie hilft, schnell Lücken in den Akzeptanzkriterien, Widersprüche zwischen Backlog-Elementen, implizite Annahmen und Fragen zu finden, die im Planning aufgebracht werden sollten.

Aber der Analyst bleibt der Mensch, der eine formal schöne Anforderung von einer tatsächlich geprüften unterscheidet. Im LMS-Fall muss gerade der Analyst bemerken, dass „unvollständiger Kurs“ kein offensichtlicher Begriff ist. Es sind konkrete Status, Ausnahmen, Fristen, Kundenregeln und Daten im System.

Backend-Entwickler

Das Backend erhält von der KI einen schnellen ersten Durchgang durch technische Risiken: Aufgaben des Planers, Idempotenz, Deduplizierungsschlüssel, Audit-Log, Logik der Wiederholungsversuche, Integration mit dem Benachrichtigungsdienst. Das beschleunigt die Vorbereitung.

Aber die KI kennt nicht die gesamte reale Architektur so, wie die Mannschaft sie kennt. Sie kann ein vernünftiges Schema vorschlagen, das Legacy-Einschränkungen, eine instabile Queue, Besonderheiten der Daten oder Absprachen zwischen Diensten nicht berücksichtigt. Deshalb darf das Backend die technische Zerlegung der KI nicht „annehmen“. Es muss sie kritisieren.

Frontend-Entwickler

Das Frontend kann schneller prüfen, ob im ersten Arbeitsumfang eine UI nötig ist, welche Zustände gezeigt werden müssen, wie der Nutzer die Versandhistorie sieht, ob eine Verwaltung der Einstellungen nötig ist oder ob eine reine Lesesichtbarkeit ausreicht.

Aber das Planning muss ehrlich beantworten: Wird die UI für das Sprint Goal wirklich gebraucht, oder ist das schon eine Erweiterung? Wenn das Ziel ist, eine Erinnerung korrekt zu versenden und eine prüfbare Historie zu speichern, ist möglicherweise im ersten Sprint keine vollwertige Client-Oberfläche nötig. Die KI kann helfen, Varianten zu formulieren, aber die Mannschaft muss den Kompromiss annehmen.

Quality Engineer / QA-Engineer

Das QA profitiert möglicherweise stärker von der KI, als es scheint. Das Modell generiert schnell Negativszenarien, Grenzszenarien, zeitgebundene Szenarien, Prüfungen der Zeitzone, des sprachlichen Fallbacks, archivierter und deaktivierter Nutzer, wiederholter Läufe der Planer-Aufgabe und der Beseitigung von Duplikaten.

Aber gerade das QA muss die Mannschaft vor Scheinabdeckung schützen. Eine lange Liste von Testideen bedeutet noch nicht, dass der Plan testbar ist. Der Plan ist nur dann testbar, wenn die Akzeptanzkriterien eindeutig sind, die Daten verfügbar sind, die Beobachtbarkeit klar ist und die Mannschaft versteht, wie sie die Erfüllung der Definition of Done nachweisen kann.

UX/UI-Designer

Der Designer stellt mit KI schneller Varianten des UI-Ansatzes zusammen: Erinnerungseinstellungen, Versandhistorie, Fehlerzustände, Hinweise für das Team zur Kundenbetreuung. Aber im Planning besteht seine Aufgabe nicht darin, den Arbeitsumfang mit schönen Interface-Möglichkeiten zu erweitern, sondern zu helfen, das Notwendige vom Wünschenswerten zu trennen.

In unserem Fall kann ein vollständiges Dashboard nützlich, aber für das erste Sprint Goal nicht zwingend sein. Wenn der Designer hilft, den Nutzerpfad zu verengen, ohne Wert zu verlieren, erhöht er die Realistik des Plans.

Scrum Master

Der Scrum Master wird im KI-gestützten Planning nicht zum „Organisator des Meetings“, sondern zum Verteidiger der Qualität der Verpflichtung der Mannschaft. Seine Aufgabe ist es, darauf zu achten, dass der KI-Entwurf nicht von sich aus zur Autorität wird.

Gute Fragen des Scrum Masters klingen hier so:

• Verstehen wir wirklich, warum dieser Sprint wertvoll ist?
• Betrachten die Entwickler dieses Sprint Backlog als ihren Plan?
• Was im KI-Entwurf haben wir mit Fakten geprüft?
• Wo wirkt der Plan zu glatt?
• Was entfernen wir zuerst, wenn neue Informationen auftauchen?
• Ist das Sprint Goal zu einer Aufgabenliste geworden?

Vergleich: Sprint Planning ohne KI und mit KI

Planungsbereich	Ohne KI	Was sich mit KI ändert
Sprint Goal	Wird in einer lebendigen Diskussion formuliert, manchmal erst nach der Auswahl der Aufgaben	KI schlägt schnell mehrere Varianten des Ziels vor
Auswahl des Arbeitsumfangs	Das Team diskutiert die Backlog-Elemente der Reihe nach und streitet oft über die Grenzen	KI erstellt eine kurze Liste, alternative Varianten des Arbeitsumfangs und Vorschläge außerhalb des Umfangs
Verfügbare Kapazität des Teams	Wird manuell nach Personen, Urlaub, Support und Übertrag unfertiger Arbeit berechnet	KI kann historische Signale und kalendarische Einschränkungen zusammentragen
Abhängigkeiten	Tauchten durch das Gedächtnis und die Erfahrung des Teams auf	KI zieht vorläufige Abhängigkeiten schneller aus Text und Historie heraus
Dekomposition	Die Entwickler zerlegen die Arbeit selbst	KI schlägt eine Dekomposition schneller und detaillierter vor
Testen	QA hebt kritische Szenarien manuell hervor	KI generiert vorläufige Varianten von Negativ- und Grenzszenarien
Risikomanagement	Risiken werden oft nur fragmentarisch angesprochen	KI erstellt schnell eine Risikoliste und ein Annahmenregister
Team-Commitment	Entsteht aus der Zustimmung des Teams nach der Diskussion	KI erzeugt einen polierten Plan, der leichter anzunehmen ist
Dokumentation	Wird oft nach dem Meeting manuell nachgetragen	KI hält Entscheidungen, Annahmen und Folgeaktionen schnell fest

Neue Risiken und was manuell zu prüfen ist

Planungsbereich	Neues Risiko	Was manuell zu prüfen ist
Sprint Goal	Das Sprint Goal wird zu einer schönen kurzen Zusammenfassung des Arbeitsumfangs	Enthält das Ziel ein „Warum“ und nicht nur ein „Was wir tun“
Auswahl des Arbeitsumfangs	Falsche Vollständigkeit und Überverdichtung des Arbeitsumfangs	Ist jedes Element wirklich für das Sprint Goal nötig? Was kann zuerst entfernt werden?
Verfügbare Kapazität des Teams	Reale Ablenkungen, Bugs, Support und Meetings werden übersehen	Sind Urlaub, Supportlast, unfertige Arbeit, Pflichtmeetings und das Warten auf externe Abhängigkeiten berücksichtigt
Abhängigkeiten	Das Modell kann eine nicht existierende Abhängigkeit erfinden oder eine organisatorische übersehen	Alle externen Abhängigkeiten sind von Menschen bestätigt und haben Verantwortliche
Dekomposition	Das Team übernimmt passiv die fremde Zerlegungslogik	Die Zerlegung spiegelt die Architektur, die Risiken und die Definition of Done des Teams wider
Testen	Pseudoabdeckung: viele Tests, aber nicht die Fehlermodi	Gibt es überprüfbare Abnahmekriterien, Observability und Daten für Tests
Risikomanagement	Die Liste wirkt vollständig und schließt das Thema ab	Welche Risiken sind nicht durch Fakten belegt? Welche lassen sich schon jetzt reduzieren?
Team-Commitment	Verwässerung von Ownership / Verantwortung: „Der Plan ist schon zusammengestellt“	Die Entwickler haben den Sprint Backlog ausdrücklich als ihren Plan bestätigt
Dokumentation	Ins Protokoll gelangen nicht die Vereinbarungen, sondern die überzeugenden Formulierungen des Modells	Alle wichtigen Entscheidungen, Fakten und offenen Fragen sind von den Teilnehmenden bestätigt

Das Wichtigste an dieser Tabelle ist nicht, dass KI „das Planning besser macht“. Der genauere Gedanke: KI beschleunigt fast überall das Zusammenstellen von Entwürfen, Listen, Alternativen und Protokollen. Aber fast nirgends ersetzt sie den letzten menschlichen Prüfzyklus auf Faktizität, Realismus und Ownership / Verantwortung.

Governance und Datenhygiene: Was man dem Modell nicht gedankenlos überlassen darf

Beim Planning entsteht oft die Versuchung, alles in die KI zu laden: Aufgaben in Jira, Diskussionsstränge in Slack, Kundenanfragen, Support-Logs, Teile der Dokumentation, den Teamkalender, die Historie von Vorfällen, die Korrespondenz mit Stakeholdern. Aus Sicht der Planning-Qualität ist das verständlich: Je mehr Kontext, desto besser der Entwurf.

Aber aus Sicht der Governance ist das gefährlich.

Wenn ein Team KI zur Vorbereitung des Sprint Planning nutzt, muss es sich vorab verständigen, welche Daten an das Modell übergeben werden dürfen und welche nicht, wer das Ergebnis prüft und wie strittige Stellen festgehalten werden. Hier funktioniert ein einfacher Governance-Ansatz gut: Prüfungen ausdrücklich Verantwortlichen zuweisen, Fakten von Annahmen trennen, Unbekanntes festhalten, wichtige manuelle Übersteuerungen des Teams über KI-Empfehlungen bewahren und Quellen für zentrale Aussagen prüfen. In Prompts / Anfragen an das Modell sollte man nicht gedankenlos einfügen:

• echte Kundennamen;
• E-Mail-Adressen von Nutzern und Mitarbeitenden;
• Produktivdaten;
• Details zu Sicherheitsvorfällen;
• Zugangsdaten, Tokens, API-Schlüssel;
• vollständige Audit-Logs;
• rechtliche Dokumente und Vertragsbedingungen;
• HR-Informationen;
• kommerziell sensible Details, die für das Planning nicht nötig sind.

Sicherer ist es, mit minimiertem und anonymisiertem Kontext zu arbeiten: echte Identifikatoren durch anonymisierte Platzhalter ersetzen, Redaktion mit Entfernung sensibler Daten / Anonymisierung nutzen, aggregierte historische Muster statt Rohdatenauszüge übergeben, Fakten von Vermutungen trennen und festhalten, welche Prompts / Anfragen an das Modell und welche Antworten des Modells tatsächlich bei der Vorbereitung des Planning verwendet wurden.

Das ist keine Bürokratie. Es ist der Weg, KI-gestütztes Planning nicht in einen Kanal für Datenlecks zu verwandeln und dem Modell nicht mehr Kontext zu geben, als für eine konkrete Entscheidung nötig ist.

Checkliste: Ein von KI zusammengestellter Sprint Plan kann diskutiert werden, wenn …

Diese Checkliste ist kein offizielles Scrum-Artefakt. Sie ist ein praktischer Filter, der dem Team hilft, den AI-Entwurf nicht mit einem echten Plan zu verwechseln.

Ein von AI zusammengestellter Sprint Plan kann diskutiert werden, wenn:

• Das Sprint Goal als Wert oder veränderter Zustand für den Nutzer / Stakeholder formuliert ist und nicht als Aufgabenliste.
• Das Team für jedes ausgewählte Backlog-Element erklären kann, wie es das Sprint Goal unterstützt.
• Die verfügbare Kapazität des Teams nicht abstrakt berücksichtigt wurde, sondern unter Berücksichtigung von Urlaub, Support, Bugfixes, Übertrag unvollendeter Arbeit, Onboarding und Pflichtmeetings.
• Unvollendete Arbeit aus dem vergangenen Sprint explizit geklärt ist: was übertragen wird, was gestrichen wird, was neu geschätzt werden muss.
• Externe Abhängigkeiten explizit benannt sind, jede hat einen Verantwortlichen und einen klaren Status.
• Das Team für den gewählten Arbeitsumfang einen Weg zur Definition of Done sieht und nicht nur zum Zustand „Code fast fertig“.
• Der Plan ist testbar: Es gibt Akzeptanzkriterien, Negativszenarien, Grenzszenarien, Observability und klare Daten zur Prüfung.
• Das Team den minimalen wertvollen Arbeitsumfang des Sprints in einem Satz benennen kann.
• Das Team im Voraus versteht, was zuerst aus dem Arbeitsumfang entfernt werden kann, falls neue Informationen auftauchen.
• Wesentliche faktische Aussagen aus dem AI-Entwurf wurden manuell geprüft: Status, Abhängigkeiten, historische Daten, architektonische Einschränkungen, Deadline-Regeln, Lokalisierung, Deduplizierung.
• Jemand aus dem Teilnehmerkreis gezielt versucht hat, den AI-Entwurf zu widerlegen, und nicht nur zu verbessern.
• Das Team gesondert geprüft hat, wo der Plan zu glatt, zu präzise oder verdächtig „selbstverständlich“ ist.
• Die Entwickler explizit bestätigt haben, dass das Sprint Backlog ihr Plan ist und das Sprint Goal eine Verpflichtung des Teams für den Sprint.
• Das Ergebnis des Planning so festgehalten ist, dass klar ist: was entschieden, was angenommen, was unbekannt geblieben und was außerhalb des Arbeitsumfangs gestellt wurde.

In der Praxis kann diese Checkliste nicht als formale Kontrollbarriere genutzt werden, sondern als kurze Denkdisziplin am Ende des Planning. Besonders nützlich sind zwei Fragen: „Was in diesem AI-Entwurf könnte unwahr sein?“ und „Was entfernen wir zuerst, wenn die Realität komplizierter wird?“.

Was ich dem Team empfehlen würde

Erstens: AI vor dem Sprint Planning nicht dafür nutzen, dass „sie den Sprint geplant hat“, sondern damit sie Material für eine gute menschliche Diskussion vorbereitet. Sie soll Varianten, Abhängigkeiten, Annahmen, Risiken, Grenzfälle, alternative Varianten des Arbeitsumfangs und Fragen sammeln. Aber die Entscheidung muss beim Team bleiben.

Zweitens: immer den Planentwurf von der Teamverpflichtung trennen. Der AI-Entwurf kann eine hervorragende Vorlage sein, aber das Sprint Backlog wird erst dann echt, wenn die Entwickler es als ihren Plan verstehen.

Drittens: von AI generierte Schätzungen nicht als objektiver annehmen, nur weil sie strukturell aussehen. Replikationen und Übersichten zu automatisierter Bewertung / Aufwandsschätzung mit AI-Unterstützung geben ausreichend Anlass zur Vorsicht: Ein komplexes Modell wird nicht besser als ein einfaches Basismodell, nur wegen seiner Komplexität. Bei Schätzungen ist nicht nur der Fehler gefährlich, sondern auch übermäßige Zuversicht. Besser AI zur Identifikation von Unsicherheiten nutzen als zur Erzeugung einer Illusion von Präzision.

Viertens: explizit außerhalb des Arbeitsumfangs festhalten. In guten AI-assisted Planning-Sessions entsteht Wert oft nicht nur dadurch, was das Team gewählt hat, sondern auch dadurch, was es bewusst nicht genommen hat. Im LMS-Fall kann das expired, ein vollwertiges Dashboard für das Kundensupport-Team, eine komplexe Segmentierung der Erinnerungsperiodizität und erweiterte Analytik sein.

Fünftens: Verantwortliche für die Prüfung benennen. Den Geschäftssinn prüft der Product Owner, die Kohärenz der Anforderungen der Analyst, die architektonische Umsetzbarkeit die Entwickler, die Testbarkeit das QA, die Grenzen der User Experience der Designer, die Qualität der Teamvereinbarung der Scrum Master. AI kann einen gemeinsamen Entwurf vorbereiten, aber die Prüfung nicht verantworten.

Fazit

Wenn AI im Backlog Refinement hilft, Material für die Diskussion schneller zu sammeln und zu formulieren, so hilft sie im Sprint Planning, Planvarianten schneller zu sammeln. Sie kann ein Sprint Goal vorschlagen, Backlog-Elemente gruppieren, Abhängigkeiten hervorheben, eine Dekomposition skizzieren, Testszenarien vorbereiten, Annahmen auflisten und sogar das Ergebnis des Meetings ansprechend festhalten.

Aber das macht den Plan nicht realistisch.

Ein realistischer Sprint Plan entsteht erst dann, wenn das Team ehrlich Wert, Arbeitsumfang, verfügbare Kapazität des Teams, Abhängigkeiten, Definition of Done, Testbarkeit und die eigene Bereitschaft geprüft hat, dies in Arbeit zu nehmen. AI kann diese Prüfung beschleunigen, aber nicht ersetzen. Sie kann helfen, mehr Varianten zu sehen, aber nicht die Teamverpflichtung für die Menschen wählen.

Deshalb würde ich den Haupteffekt von AI im Sprint Planning so formulieren: Sie senkt die Kosten der Vorbereitung von Planvarianten, erhöht aber den Preis der menschlichen Prüfung. Je einfacher es geworden ist, einen schönen Plan zu erstellen, desto wichtiger ist es geworden zu verstehen, ob er ein echter Teamplan ist.

In einem reifen Team verwandelt KI das Sprint Planning nicht in eine automatische Generierung des Sprint Backlogs. Sie verwandelt es in ein sachlicheres Gespräch über Ziel, Einschränkungen und Kompromisse. Und genau das ist vielleicht die nützlichste Form der Automatisierung: die Menschen nicht aus dem Planning zu entfernen, sondern ihre Aufmerksamkeit für jene Entscheidungen freizugeben, die das Werkzeug nicht für sie treffen kann.

Quellen und Orientierungspunkte

• Scrum Guide 2020 — Sprint Planning, Sprint Goal, Sprint Backlog, Verantwortungsbereiche.
• NIST-Framework zum Management von KI-Risiken 1.0 — Steuerung / Regulierung, Rechenschaft / Verantwortlichkeit, Konfiguration der Mensch-KI-Interaktion.
• NIST-Profil für generative KI — Konfabulation / zuversichtliches Erfinden, übermäßige Abhängigkeit, Privatsphäre und Risikomanagement.
• ChatGPT as a tool for User Story Quality Evaluation — ein Beispiel für eine moderate Evidenzbasis für Aufgaben zur Qualität von User Stories.
• Large Language Models for Software Engineering: Survey and Open Problems — Überblick über LLMs in der Softwareentwicklung / Software-Engineering.
• Aufwandsschätzung in der agilen Softwareentwicklung: eine systematische Literaturübersicht — Qualitätsfaktoren der agilen Schätzung.
• Reasons and Approaches for Accurate Effort Estimations in Agile Iterative Development — Informationsqualität, Team, Schätzungspraxis, Projektmanagement, Geschäftswirkung.
• GPT2SP replication report — Grenzen der KI-Schätzung in Story Points und Vergleich mit einfachen Basismodellen / Orientierungspunkten.
• Zu einer verlässlichen iterativen agilen Planung durch Prognose von Dokumentationsänderungen der Arbeitselemente — Zusammenhang zwischen Dokumentationsänderungen und der Fragilität des Planning.
• The Planning Fallacy — klassische Arbeit über die Unterschätzung von Fristen.
• Automation Bias in Intelligent Time Critical Decision Support Systems — Automatisierungsverzerrung, Auslassungsfehler und Handlungsfehler.
• Generalization bias in large language model summarization — Risiko übermäßiger Verallgemeinerungen in von großen Sprachmodellen erstellten Zusammenfassungen.
• OWASP Top 10 für LLM-Anwendungen — sensible Informationen, übermäßige Abhängigkeit, Risiken von Prompts und Sicherheit.