Backlog Refinement und KI: Was sich wirklich ändert

Dies ist der erste Artikel aus einer Serie darüber, wie KI die klassischen Meetings eines cross-funktionalen Entwicklungsteams verändert. Unten beginne ich mit Backlog Refinement, und in den folgenden Materialien werde ich separat Planning, Daily, Review, Retrospective behandeln und dann alles in einem abschließenden Überblicksartikel zusammenfassen.

Ich kläre gleich den Rahmen: Im Folgenden spreche ich von Refinement als einer regelmäßigen Team-Session und Praxis der Verfeinerung von Backlog Items, nicht unbedingt als einem eigenen offiziellen Scrum-Event. Das ist wichtig für die Genauigkeit der Begriffe: im Scrum Guide 2020 (RU PDF) Refinement wird als ongoing activity beschrieben, nicht als eigenständiges Event. In der russischen Version des Scrum Guide 2020 ist dieser Gedanke direkt formuliert: Das Verfeinern des Product Backlogs ist eine fortlaufende Tätigkeit, bei der Details, Reihenfolge und Größe hinzugefügt werden.

Backlog Refinement ist einer der ersten Orte, an denen KI dem Team einen durchaus spürbaren Nutzen bringt. Sie hilft, schneller Kontext zu sammeln, einen Entwurf der Aufgabenstellung vorzubereiten, schnell einen Entwurf der Akzeptanzkriterien zu generieren, ähnliche Fälle zu finden und eine Liste offener Fragen zu formulieren. Diese These wird auch durch eher anwendungsorientierte Arbeiten gestützt: zum Beispiel in LLM-Assisted Requirements Engineering in Agile MDD wurde die Generierung von Acceptance Criteria gesondert validiert, und in der industriellen Fallstudie Acceptance Test Generation with Large Language Models bemerkten Nutzer, dass KI-Szenarien halfen, zuvor übersehene Fälle zu erkennen. Aber genau deshalb tappt man hier besonders leicht in die Falle: einen gut formatierten Entwurf mit einer wirklich verständlichen Aufgabe zu verwechseln.

Meiner Meinung nach vereinfacht KI das Refinement nicht in dem Sinne, dass das Team jetzt weniger nachdenken müsste. Sie verbilligt vielmehr die teuerste manuelle Arbeit darum herum – Suche, Zusammenfassung, Verpackung und erste Zerlegung. Das bedeutet, der Wert der eigentlichen Teamdiskussion verschwindet nicht, sondern verschiebt sich: weniger Zeit geht dafür drauf, aus dem Chaos etwas wie eine Aufgabe zu formen, und mehr dafür, zu verstehen, ob man das überhaupt in Angriff nehmen kann.

„KI beschleunigt nicht die eigentliche Einigung des Teams, sondern die Vorbereitung des Materials dafür“

Warum sich die Veränderungen gerade beim Backlog Refinement zuerst bemerkbar machen

Betrachtet man die gewohnten Team-Rituale und Meetings in der Agile-Praxis, erweist sich das Refinement als einer der Bereiche, die am empfindlichsten auf das Aufkommen von KI reagieren. Der Grund ist recht einfach: Rund um das Refinement gab es historisch viel manuelle intellektuelle Routinearbeit. Man muss verstreuten Kontext aus Dokumenten, alten Tickets, Chats und dem Gedächtnis der Menschen zusammentragen. Man muss aus einer rohen Geschäftsidee ein verständliches Backlog Item machen. Man muss das Geschäftsproblem, das Szenario, die Akzeptanzkriterien, Einschränkungen, offene Fragen, Abhängigkeiten und mögliche Randfälle formulieren.

Genau in diese Schicht passt KI besonders gut. Das deckt sich auch damit, wie heute der Einsatz von LLMs im Requirements Engineering diskutiert wird: Modelle sind stark bei der Zusammenfassung, der ersten Strukturierung von Anforderungen, der Generierung von Entwürfen und der Unterstützung analytischer Vorbereitung, aber schwächer dort, wo Domänengenauigkeit, Rückverfolgbarkeit und Verantwortung für endgültige Entscheidungen gefragt sind. In diesem Sinne wird das Refinement tatsächlich einer der ersten Prozesse, in denen der Nutzen von KI schnell spürbar wird und die Grenzen ihrer Zuverlässigkeit fast sofort. Darüber wird gut geschrieben im Überblick Challenges in applying large language models to requirements engineering tasks, und in der aktuellen systematischen Übersicht Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review, und in der eher anwendungsorientierten Arbeit LLM-Assisted Requirements Engineering in Agile MDD.

Wie das Refinement vor KI aussah

Vereinfacht gesagt war das Refinement vor KI sehr oft ein Prozess des manuellen Zusammenbaus von Verständnis. Ins Backlog gelangte nicht eine fertige Aufgabe, sondern eher eine Geschäftsabsicht: das Onboarding verbessern, Erinnerungen hinzufügen, dem Manager einen neuen Bericht geben, die Zahl überfälliger Anfragen reduzieren. Danach begann der Product Owner, ein Analyst oder jemand aus dem Lead-Kreis, den Kontext manuell zusammenzutragen: alte Kundenanfragen wurden hervorgeholt, ähnliche Features, Einschränkungen der aktuellen Architektur, geltende Status, bestehende Benachrichtigungen, UI-Patterns und alles andere, was plötzlich schon in der Diskussion auftauchen konnte.

Danach versuchten derselbe Mensch oder ein paar Leute manuell, das Gesammelte in einen ersten Entwurf zu verwandeln: das Geschäftsproblem zu formulieren, das Szenario zu beschreiben, die Abnahmekriterien zu schreiben, offene Fragen herauszustellen und mögliche Einschränkungen zu benennen. Aber selbst wenn ein solcher Entwurf bereits existierte, ging das Meeting trotzdem oft dafür drauf, den Kontext in die Köpfe des gesamten Teams zu heben. Der Product Owner erklärte erneut, was das Business will, der Analyst erzählte, was bereits herausgefunden werden konnte, die Entwickler brachten architektonische Einschränkungen ein, QA holte Grenzszenarien hervor, Designer und Frontend diskutierten, ob ein eigener Screen nötig ist und wo er überhaupt leben wird.

Derselbe Fall: ohne KI und mit KI

Um nicht auf der Ebene allgemeiner Formeln zu bleiben, nehme ich einen konkreten Fall. Das Produkt ist eine B2B-LMS-Plattform für Corporate Learning. Große Kunden weisen Mitarbeitern Pflichtkurse zu Compliance, Sicherheit und internen Richtlinien zu. Vom Business kommt die Anfrage: Es müssen automatische E-Mail-Erinnerungen an Mitarbeiter hinzugefügt werden, die einen Pflichtkurs bis zur Deadline nicht abgeschlossen haben.

Auf den ersten Blick sieht das wie eine einfache Aufgabe zum Versenden einer E-Mail aus. Aber schon in den ersten Schritten wird klar, dass es hier tatsächlich viele Verzweigungen gibt: Wen genau zählt man als denjenigen, der den Kurs nicht abgeschlossen hat, wann werden Erinnerungen versendet, wie werden Sendungen dedupliziert, wie wird das vom Kunden konfiguriert, ist ein Versandprotokoll nötig, was macht man mit Zeitzonen, welche Sprache soll die E-Mail haben und sollten archivierte und deaktivierte Benutzer ausgeschlossen werden.

Im Modus ohne KI kam das Team zu diesen Fragen hauptsächlich durch lange manuelle Vorbereitung und ein umfangreiches Gespräch im Meeting selbst. Zuerst brachte der Product Owner den Kundenkontext ein. Dann ging der Analyst manuell durch interne Materialien: Er suchte alte ähnliche Anfragen, sah sich den Benachrichtigungsservice an, prüfte aktuelle Status von Assignments, die Existenz von Scheduler-Aufgaben, Felder für Spracheinstellung und Zeitzone. Bereits in dieser Phase tauchten reale Einschränkungen auf: Im System gibt es E-Mail-Vorlagen, aber nur für transaktionale E-Mails; die Zeitzone wird auf Kundenebene gespeichert, nicht auf Benutzerebene; es gibt keine Versandprotokolle; ein eigenes Modell für Erinnerungen gibt es im Produkt ebenfalls nicht.

Danach stellte der Analyst manuell den ersten Entwurf des Anforderungsdokuments zusammen, aber er blieb trotzdem unreif. Zum Beispiel konnten darin die genauen Status, für die Erinnerungen gesendet werden sollen, die Deduplizierungslogik, der minimale Arbeitsumfang für die UI, der Sprach-Fallback oder die Grenzen der ersten Version nicht festgehalten sein. Und dann sammelte das Team im Refinement selbst die Aufgabe direkt während des Gesprächs nach. Genau dort stellte sich heraus, dass Erinnerungen nur für Pflichtkurse nötig sind, dass die Status not_started und in_progress passen, aber expired besser nicht in die erste Version aufgenommen werden sollte, dass ohne Versandjournal Support und Kundenbetreuungsteam schnell in Fragen untergehen würden und dass ohne eigenen Schutz Duplikate bei erneutem Ausführen von Scheduler-Aufgaben entstehen würden.

Im Modus mit KI sieht derselbe Fall anders aus. Der Product Owner lädt in die KI eine kurze Zusammenfassung vom Kundenbetreuungsteam, die letzten Kundenanfragen und die rohe ursprüngliche Anfrage. Die KI gruppiert schnell die Kundenprobleme, hebt wiederkehrende Erwartungen hervor und hilft, die Problemformulierung zu gestalten. Der Analyst bittet die KI, alles im Zusammenhang mit Benachrichtigungsflüssen, Assignment-Status, Scheduler-Aufgaben, Spracheinstellung, Zeitzone und ähnlichen Aufgaben in Jira hervorzuheben. Das Backend lässt im Voraus die Beschreibung der aktuellen Benachrichtigungsarchitektur durch die KI laufen und bittet um einen technischen Ansatz. Frontend und Designer prüfen schnell, wo die Einstellungen und die Versandhistorie logischerweise eingebunden werden sollten. QA stellt eine Startliste von Grenzfällen und zeitlichen Risiken zusammen.

Hier entsteht üblicherweise eine natürliche Frage: Was, wenn die KI etwas übersehen hat? Wie sehr kann man einer solchen kurzen Zusammenfassung überhaupt trauen, besonders wenn die Quellenbasis groß ist? Forschung und praktische Fälle liefern hier ein ziemlich nüchternes Bild: LLMs können tatsächlich die Generierung von User Stories, Entwürfen von Abnahmekriterien und ersten Anforderungsdokumenten beschleunigen, aber die Qualität des Ergebnisses hängt stark vom Eingabekontext, der Domäne und der anschließenden menschlichen Prüfung ab. Deshalb ist es sinnvoll, auch eher anwendungsbezogene Arbeiten im Kopf zu behalten wie AI-Generated User Stories: Are They Good Enough? und LLM-Assisted Requirements Engineering in Agile MDD: Sie zeigen gut, dass die Generierung eines starken Entwurfs und die Bereitschaft zur Entwicklung nicht dasselbe sind.

Nach meiner Erfahrung mit Cursor zweifle ich in anwendungsbezogenen Szenarien recht selten daran, dass das Modell einen brauchbaren ersten Durchlauf über einen großen Quellenbestand erstellen kann. Viel wichtiger ist etwas anderes: wie gut ich die Aufgabe formuliert, welche Einschränkungen ich vorgegeben, welche klärenden Fragen ich rechtzeitig ergänzt und wie genau ich die Prüfung des Ergebnisses organisiert habe. Wenn bei mir ein Zweifel aufkommt, versuche ich ihn nicht mit der Frage „glaube ich der KI oder nicht“ zu lösen – ich präzisiere einfach die Anfrage nach, bitte darum, die Quellen separat anzuzeigen, strittige Stellen herauszustellen, Fakten und Annahmen zu trennen oder die Antwort mit einem anderen Rahmen neu zu erstellen. In diesem Sinne ähnelt die Arbeit mit KI sehr dem Coaching: Nützlich ist die Fähigkeit, präzise Fragen zu stellen, die nicht nur die Generierung auslösen, sondern das Denken des Modells in die gewünschte Richtung lenken.

Das ist natürlich meine persönliche Erfahrung und keine allgemeingültige Regel. Vielleicht schreibe ich noch einen separaten Beitrag genau über das Vertrauen in KI, die Qualität klärender Fragen und die kontrollierte Prüfung des Ergebnisses. Für das Refinement ist das besonders wichtig: Je größer die Quellenbasis und je überzeugender die Kurzzusammenfassung, desto höher das Risiko, eine starke Vorbereitung mit bereits geprüftem Verständnis zu verwechseln.

„Je größer die Quellenbasis und je überzeugender die Kurzzusammenfassung, desto höher das Risiko, eine starke Vorbereitung mit bereits geprüftem Verständnis zu verwechseln“

Infolgedessen kommt das Team zum Refinement nicht mehr mit einer rohen Idee, sondern mit einem recht starken Gerüst: Es gibt einen Entwurf der User Story, einen Entwurf der Abnahmekriterien, offene Fragen, eine Risikoliste, einen vorläufigen technischen Ansatz und einen UI-Vorschlag. Dadurch wird das Meeting selbst kürzer und konkreter. Das Team verwendet nicht mehr so viel Zeit auf das Einbringen des Grundkontexts und diskutiert hauptsächlich die strittigen Stellen: ob expired, ob eine separate Zeitzone pro Benutzer eingeführt wird, ob im ersten Release ein Versandjournal nötig ist, ob man sich auf feste Trigger beschränkt, wie man sich vor Duplikaten schützt und was als Grenzen der ersten Version gilt.

Worin besteht der Fortschritt des Teams?

Wenn ein Team gerade erst anfängt, KI zu nutzen, arbeitet sie hauptsächlich als schneller Generator für einen ersten Entwurf. Mit zunehmender Reife ist der nächste logische Schritt jedoch, nicht mehr nur mit dem allgemeinen Modell zu arbeiten, sondern nach und nach das in einen kontrollierten Teamkontext zu überführen, was früher nur im Gedächtnis der Menschen lebte. Das können Produktprinzipien sein, Vorlagen für Abnahmekriterien, häufige Gründe für die Ablehnung einer Aufgabe im Refinement, typische Grenzfälle, architektonische Einschränkungen, eine Sammlung typischer klärender Fragen, interne Organisationsrichtlinien, Definition of Ready und Definition of Done auf Ebene von Organisation und Team sowie Beispiele guter Lösungen für ähnliche Fälle.

Dann beginnt die Qualität des ersten Entwurfs tatsächlich zu steigen. Nicht weil das Modell plötzlich „die Domäne selbst verstanden“ hätte, sondern weil das Team gelernt hat, seine eigenen Denkmuster, internen Einschränkungen und Prüfregeln systematisch in das Modell auszulagern. Und hier wird das Refinement nicht nur zum Ort der Aufgabenprüfung, sondern auch zu einem Ort, an dem das Team nach und nach seine eigene KI-Schicht trainiert.

Was sich nach Rollen verändert

Im Folgenden lohnt es sich, nicht nur auf die Rollen als abstrakte Funktionen zu schauen, sondern auch auf die konkreten Handlungen im modellierten Fall mit Erinnerungen an Pflichtkurse. Genau so wird der Unterschied zwischen dem Modus ohne KI und mit KI wirklich spürbar.

Rolle	Ohne KI	Mit KI
Product Owner	Bringt den Kundenkontext manuell ein, sammelt Anfragen des Kundensupport-Teams und erklärt das Geschäftsproblem im Meeting erneut.	Bereitet einen anonymisierten Input vor, bittet die KI, die Kundenprobleme zu gruppieren, und bringt einen Entwurf der Problemformulierung sowie eine Liste strittiger Produktentscheidungen ins Meeting mit.
Business-Analyst	Sucht ähnliche Fälle, sammelt manuell Status, Einschränkungen, Abhängigkeiten und schreibt alles anschließend in den ersten Entwurf der Aufgabenstellung um.	Organisiert die Anfrage an die KI anhand der Quellen, gleicht die Kurzzusammenfassung mit den Quellen ab, überarbeitet die Abnahmekriterien und hält offene Fragen sowie das fest, was das Modell übersehen haben könnte.
Backend-Entwickler	Taucht oft erst beim Refinement wirklich tief in das Problem ein und bringt Einschränkungen des Benachrichtigungsdienstes und Risiken von Duplikaten direkt während der Diskussion zur Sprache.	Erhält vor dem Meeting einen ersten Durchlauf zu technischen Varianten, prüft vorab Deduplizierung, Scheduler-Aufgaben, Audit Trail und die Grenzen der ersten Version.
Frontend-Entwickler	Versucht im Meeting gemeinsam mit dem Designer zu verstehen, ob ein separater Screen nötig ist, wo die Einstellungen leben sollen und was tatsächlich zur minimalen UI gehört.	Sieht sich vor dem Meeting den KI-Entwurf der UI-Integration an und markiert vorab strittige Stellen zu Einstellungen, Zuständen und Schnittstellenbeschränkungen.
Qualitätsingenieur / QA-Ingenieur	Steigt hauptsächlich im Meeting ein, holt Negativszenarien, Statuskollisionen und zeitliche Risiken erst im gemeinsamen Gespräch hervor.	Erhält vor dem Meeting eine Startliste von Grenzfällen und prüft, ob die KI Duplikate, Zeitzonen, sprachliche Fallback-Szenarien und Ausnahmen bei Benutzerstatus übersehen hat.
UX/UI-Designer	Arbeitet sich während der Diskussion in die Aufgabe ein und schätzt vor Ort ein, ob ein neuer Screen, ein Einstellungsblock oder eine Versandhistorie nötig ist.	Testet schnell zusammen mit dem Frontend mehrere Varianten des UI-Ansatzes und kommt bereits mit einem durchdachten Vorschlag, nicht von null.
Scrum Master	Versammelt die Teilnehmer, hält das Timing, hilft, sich beim chaotischen Aufbau von Kontext nicht zu verlieren, und bringt das Team zum Kern zurück, wenn die Diskussion abschweift.	Verwendet weniger Zeit für organisatorische Mechanik und die Angleichung des Basiskontexts, mehr für die Moderation strittiger Entscheidungen, das Festhalten offener Fragen und die Qualitätskontrolle der Diskussion.

Vorteile, Risiken und freigesetzte Zeit

Der Nutzen von KI im Refinement ist durchaus spürbar. Der Kontext wird schneller zusammengestellt, ein Entwurf der Aufgabe entsteht schneller, die Diskussion startet leichter und die Ergebnisse werden besser verpackt. Aber gerade im Refinement zeigen sich die Risiken von KI auch sehr früh. Das offensichtlichste Risiko ist falsche Klarheit. KI kann saubere Backlog Items erstellen, die visuell und strukturell gut aussehen. Dadurch fällt es dem Team leichter, sich mit dem Gefühl zu täuschen, die Aufgabe sei bereits verstanden, obwohl in ihr weiterhin produktbezogene und technische Lücken bestehen.

Hier ist es sinnvoll, die Dinge beim Namen zu nennen. Erstens ist es Automatisierungsverzerrung und übermäßige Abhängigkeit — die Neigung, die Empfehlung des Systems allzu bereitwillig anzunehmen und von aktiver Prüfung zu passiverem Monitoring überzugehen. In NIST-Profil für generative KI wird direkt als übermäßiges Vertrauen in KI-Systeme beschrieben, und in der empirischen Studie Automation Bias in AI-Decision Support: Results from an Empirical Study zeigt sich, dass ein hoher wahrgenommener Nutzen des Systems die falsche Zustimmung zu seinen Fehlern erhöhen kann, während die Qualität der Nutzerschulung die Wahrscheinlichkeit dieses Effekts senkt. Zweitens ist es Halluzination des Modells — eine plausible, aber nicht durch Quellen belegte Schlussfolgerung. Für das Refinement ist das besonders kritisch, weil KI fast immer über die Zusammenfassung von Dokumenten, Tickets und Chats arbeitet, und das Risiko liegt also nicht nur in einem „schönen, aber erfundenen Entwurf der Akzeptanzkriterien“, sondern auch in der stillen Verzerrung des ursprünglichen Kontexts. Genau deshalb irrt sich KI im Refinement häufiger nicht im Stil des Textes, sondern in den Fakten des Kontexts — und dieses Risiko ist gut beschrieben in der Arbeit On Faithfulness and Factuality in Abstractive Summarization. Das praktische Gegenmittel ist hier recht einfach: das Modell bitten, Fakten von Hypothesen zu trennen, Quellenangaben verlangen und eine kurze Zusammenfassung so aufbauen, dass sie sich schnell bis zu den Dokumenten, Tickets und Entscheidungen des Teams zurückverfolgen lässt.

Es gibt noch eine weitere Risikoeebene — die Daten. Im obigen Fall arbeitet die KI mit Kundenanfragen, internen Systembeschreibungen und Nutzersignalen. Deshalb ist es für das Team wichtig, sich vorab zu verständigen, was überhaupt an das Modell übergeben werden darf und was nicht. Bei generativer KI beschränkt sich das Risiko nicht nur auf den Prompt: personenbezogene Daten können in der Eingabe, in der Ausgabe und sogar durch Memorization/Regurgitation des Modells auftauchen. Wenn in der Arbeit personenbezogene Daten oder sensibler Kundenkontext vorkommen, müssen daher grundlegende Prinzipien der Datenhygiene verpflichtend sein: das Datenvolumen in Prompts minimieren, die Eingabe nach Möglichkeit anonymisieren, keinen ungefilterten Roh-Export in das Modell ziehen, den Zweck der Verarbeitung ausdrücklich verstehen und Aussagen des Anbieters wie „wir verarbeiten keine personenbezogenen Daten“ oder „das Modell ist anonym“ nicht ungeprüft glauben, ohne überprüfbare organisatorische und technische Kontrollen. Zusätzlich ist es sinnvoll, vorab die Rechtsgrundlage der Verarbeitung, den minimal notwendigen Satz an Feldern, Rollen und Verantwortlichkeiten innerhalb des Prozesses und, wo anwendbar, Anforderungen an die Information der betroffenen Personen festzuhalten. Wenn das Szenario personenbezogene Daten umfasst und Umfang oder Risiken erkennbar sind, ist es sinnvoll, vorab zu prüfen, ob eine DPIA erforderlich ist, und diese Entscheidung gesondert festzuhalten. Im europäischen Kontext stimmt dies gut mit den Grundsätzen von GDPR Article 5und mit den praktischen Empfehlungen von CNIL zur Entwicklung von KI-Systemensowie mit EDPS guidance on Generative AI und EDPB Opinion 28/2024.

Und hier stellt sich noch eine wichtige Frage: Wohin fließt die freigewordene Zeit der Fachleute. Die einfachste Variante ist der Versuch, noch mehr Aufgaben hineinzupacken. Reifer ist es, diese Einsparung in die Qualität von Entscheidungen, den Abbau technischer Schulden, die Entwicklung interner Vorlagen, Schulung, Dokumentation und zumindest eine bessere Steuerung der Aufmerksamkeit des Teams zu investieren. Im abschließenden Überblicksartikel der Serie werde ich gesondert darauf eingehen, dass KI nicht nur den Prozess verändert, sondern auch die Kultur des Umgangs mit Teamzeit.

Neue versteckte Kosten, die man nicht ignorieren darf

Damit das Gespräch über Effizienz nicht zu glatt wirkt, ist es wichtig, auch die Kehrseite zu ergänzen: KI liefert selten eine „reine Einsparung“ ohne neue Arten von Arbeit. Ein Teil der Zeit geht nun für die Vorbereitung von Daten, die Einrichtung des Zugangs zu Quellen, die Pflege von Prompts und Vorlagen, die Prüfung von Quellen, die Dokumentation von Entscheidungen und die menschliche Kontrolle drauf. Diese Sichtweise stimmt gut mit den Praktiken des Risk Managements für generative KI überein: zum Beispiel NIST-Profil für generative KI legt den Schwerpunkt nicht nur auf den Nutzen der Automatisierung, sondern auch auf die Notwendigkeit von Oversight, Documentation und Managementkontrolle.

Szenariobasierte Schätzung des Arbeitsaufwands für ein Backlog Refinement (szenariobasiert)

Unten folgt keine „Durchschnittstemperatur des Marktes“, sondern ein Szenariomodell desselben Backlog Refinement für dasselbe siebenköpfige Team: PO, BA, Backend, Frontend, QA, Designer und Scrum Master. Dies ist eine Schätzung für ein großes oder deutlich unklares Backlog Item, nicht für eine kleine, gut verstandene Story. Der Wert dieser Zahlen liegt nicht in der Genauigkeit auf die Minute, sondern im Vergleich der Kostenstruktur: Wohin die Zeit früher floss und wohin sie jetzt fließt.

Im Folgenden geht es genau um Arbeitsstunden für ein großes Backlog Item — Vorbereitung, Diskussion und kurze Nacharbeit nach dem Meeting —, nicht um die Dauer des Meetings selbst. Das Meeting selbst wird in der Regel ebenfalls kürzer, aber ein Teil der Arbeit verlagert sich einfach in die asynchrone Vorbereitung, klärende Durchläufe und die obligatorische manuelle Prüfung.

Anmerkung zur Berechnung des Arbeitsaufwands: Historisch wurde in Scrum Guide 2017 (RU PDF) Refinement ebenfalls als Ongoing Process beschrieben, und dort fand sich ein Richtwert, dass es in der Regel nicht mehr als 10 % der verfügbaren Kapazität des Entwicklungsteams einnimmt. In Scrum Guide 2020 (RU PDF) dieses Richtwerts gibt es bereits nicht mehr, daher sollte die Tabelle unten besser nicht als Norm, sondern als Szenariomodell zum Vergleich zweier Arbeitsmodi gelesen werden.

Wichtig ist die gesonderte Erläuterung: Die Spalte „Mit AI“ unten enthält bereits die grundlegende neue Arbeit, ohne die dieses Szenario nicht funktioniert — die Vorbereitung der Eingabedaten, klärende Anfragen, die Erstprüfung der Kurzzusammenfassung, die Verifikation strittiger Stellen und eine minimale menschliche Prüfung. Das heißt, der endgültige Gewinn in der Tabelle ist keine „schmutzige“ Einsparung vor Berücksichtigung der neuen Aufwände, sondern eine bereits realistischere Szenarioschätzung nach deren grundlegender Einbeziehung.

Damit diese Schätzung reproduzierbar ist, lässt sie sich bequem nach einem einfachen Schema berechnen: TAI = Tbase × ((1 − p) + p × s) + o, wobei Tbase — die Zeit ohne AI ist, p — der Anteil der beschleunigten Arbeit, s — der Beschleunigungsfaktor für diesen Teil, und o — die neue Arbeit für die Datenvorbereitung, klärende Anfragen und die Prüfung des Ergebnisses.

Unten folgt ein kalibriertes Beispiel genau für dieses Basisszenario. Seine Aufgabe ist nicht, eine universelle Norm zu beweisen, sondern zu zeigen, wie dasselbe Modell die Zahlen aus der Tabelle für einen konkreten Fall reproduzieren kann. In einem realen Team sollten solche Parameter besser anhand der letzten 3–5 Backlog Refinements kalibriert und dann die eigene Bandbreite ermittelt werden.

# Calibrated to reproduce the table (base scenario)
# T_ai = T_base * ((1 - p) + p * s) + o
roles = {
    "PO": {"T_base": 4.5, "p": 0.75, "s": 0.20, "o": 0.7},
    "BA": {"T_base": 10.0, "p": 0.70, "s": 0.20, "o": 0.6},
    "BE": {"T_base": 3.5, "p": 0.75, "s": 0.20, "o": 0.6},
    "FE": {"T_base": 3.0, "p": 0.75, "s": 0.20, "o": 0.3},
    "QA": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "UX": {"T_base": 3.0, "p": 0.50, "s": 0.20, "o": 0.2},
    "SM": {"T_base": 2.5, "p": 0.50, "s": 0.20, "o": 0.0},
}

def t_ai(x):
    return x["T_base"] * ((1 - x["p"]) + x["p"] * x["s"]) + x["o"]

total_base = sum(r["T_base"] for r in roles.values())
total_ai = sum(t_ai(r) for r in roles.values())

print("Total base:", round(total_base, 1))
print("Total AI:", round(total_ai, 1))
print("Gain:", round(total_base - total_ai, 1))

for role, x in roles.items():
    print(role, round(t_ai(x), 1))

Rolle	Ohne AI	Mit AI (unter Berücksichtigung der neuen Arbeit)	Was sich ändert
Product Owner	4,5 h	2,5 h	Sammelt den Kundenkontext schneller, verwendet aber einen Teil der Zeit auf die Vorbereitung des Inputs und klärende Anfragen
Business-Analyst	10 h	5 h	Weniger manuelle Suche und Umschreiben, mehr Verifikation, Redaktion und Prüfung, dass die AI nichts Wichtiges übersehen hat
Backend-Entwickler	3,5 h	2 h	Erhält schneller eine erste technische Analyse, prüft aber separat Architekturbeschränkungen und das Risiko von Duplikaten
Frontend-Entwickler	3 h	1,5 h	Schätzt die UI-Integration und Einstellungen schneller ein und wird dabei früher in die Prüfung strittiger Stellen einbezogen
Quality Engineer / QA-Engineer	3 h	2 h	Erhält früher Grenzfälle und zeitliche Risiken, wird aber stärker in die Prüfung von Lücken und Negativszenarien eingebunden
UX/UI-Designer	3 h	2 h	Sammelt schneller eine erste Variante des UI-Ansatzes und schließt überflüssige Interface-Varianten im Voraus aus
Scrum Master	2,5 h	1,5 h	Weniger Zeit für organisatorische Kontextabstimmung, mehr für die Moderation von Entscheidungen und das Festhalten offener Fragen
Gesamt	29,5 h	16,5 h	Szenariogewinn — etwa 13 Arbeitsstunden bei einem solchen Backlog Refinement, bereits nach Berücksichtigung der grundlegenden neuen Arbeit

Szenariobandbreite: Wie sich der Gewinn verändern kann

Szenario	Ohne AI	Mit AI	Reiner Gewinn	Wann das vorkommt
Vorsichtig	24–28 h	18–21 h	4–10 h	Die Quellen sind unvollständig, es gibt viel manuelle Prüfung, das Team baut erst Arbeitsmuster mit AI auf.
Basis	28–32 h	15–18 h	10–15 h	Ungefähr so sieht der modellierte Fall aus: AI beschleunigt die Vorbereitung gut, aber die neue Arbeit für die Verifikation ist bereits berücksichtigt.
Stark	30–36 h	14–17 h	13–19 h	Das Team hat gute Quellen, wiederholbare Muster und klare Regeln für Datenhygiene und manuelle Prüfung.

Welche neue Arbeit im Szenario mit AI bereits berücksichtigt ist

Die folgende Tabelle hebt den Gesamtgewinn aus der ersten nicht auf. Sie schlüsselt lediglich auf, durch welche neuen Handlungen ein Teil der eingesparten Zeit wieder in den Prozess zurückfließt — und warum der reine Effekt auch danach noch deutlich bleibt.

Neuer Arbeitsbereich	Was mit AI entsteht	Wozu das nötig ist
Vorbereitung der Eingabedaten	Bereinigung, Anonymisierung, Extraktion des benötigten Kontexts	Damit das Modell nicht mit Müll überlastet wird und keine überflüssigen Daten mitgezogen werden
Klärende Anfragen	Wiederholte Durchläufe, Präzisierung des Antwortrahmens, Bitte um Trennung von Fakten und Annahmen	Damit die erste schöne Antwort nicht als endgültiges Verständnis angenommen wird
Einrichtung von Vorlagen	Prompts, Vorlagen für Aufgabenstellungen, Regeln für das Ergebnisformat	Damit die AI einen nützlichen, wiederholbaren Entwurf liefert und keinen zufälligen Text
Faktenprüfung	Prüfung von Quellenverweisen, Begriffen, Status und Einschränkungen	Damit Halluzinationen des Modells und falsche Klarheit vor dem Meeting erkannt werden
Dokumentation des Vertrauens	Festhalten, was genau manuell geprüft wurde und warum dem Ergebnis vertraut werden kann	Damit das Team Verantwortung nicht durch einen schönen Entwurf ersetzt

Unterschiede nach Etappen

Etappe	Ohne AI	Mit AI
Kontextsammlung vor dem Meeting	Lange manuelle Suche in Dokumenten, Tickets und im Gedächtnis der Leute	Der erste Durchgang durch die Quellen und die Kurzzusammenfassung gehen deutlich schneller
Entwurf der Aufgabenstellung	Wird manuell geschrieben und bleibt oft roh	Es gibt einen starken Entwurf, den das Team kritisieren und präzisieren kann
Das Backlog Refinement selbst	Viel Zeit geht für die Angleichung des Verständnisses verloren	Der Fokus verschiebt sich auf strittige Entscheidungen, Abhängigkeiten und Grenzen der ersten Version
Nacharbeit nach dem Meeting	Oft muss die Aufgabenstellung fast neu geschrieben werden	Die Ergebnisse sind bereits gut verpackt und erfordern weniger manuelle Nacharbeit

Qualitäts-Checkliste für die AI-Vorbereitung auf das Refinement

Wichtig: Diese Definition of Ready ist eine interne Praxis des Teams und kein Teil des Scrum Guide. Hier dient sie als Schutz vor falscher Klarheit, Lücken und verwischter Verantwortung in der AI-Vorbereitung.

Definition of Ready für den AI-Entwurf

• Fakten sind von Annahmen getrennt: Das Team versteht, was aus Quellen stammt und was das Modell vorgeschlagen hat.
• Es gibt Links oder klare Quellenangaben für zentrale Produkt- und Technikaussagen.
• Offene Fragen sind nicht unter sorgfältigem Text versteckt, sondern explizit ausgewiesen.
• Domänenbegriffe, Status, Einschränkungen, Rollen und Abhängigkeiten sind geprüft.
• Für jede zentrale Aussage ist das Evidenzniveau klar: ein Fakt aus einer Quelle, eine Arbeitshypothese oder eine Annahme des Modells.
• Grenzfälle, Negativszenarien und zeitliche Risiken sind separat geprüft.
• Es ist klar, welche Daten nicht an das Modell übergeben werden durften und welche Maßnahmen zur Datenhygiene angewendet wurden.
• Für die Prüfung nach Aussagetypen sind Verantwortliche benannt: Geschäftslogik, architektonische Umsetzbarkeit, Testbarkeit und Datenarbeit.
• Das Team hat vereinbart, dass der AI-Entwurf Rohmaterial für die Diskussion ist und keine fast fertige Aufgabe.

Damit diese Checkliste nicht zu abstrakt bleibt, so sähe sie in unserem Fall mit E-Mail-Erinnerungen aus:

• Die AI schlägt vor, die Status not_started, in_progress und expired einzubeziehen – das Team markiert ausdrücklich, dass expired vorerst eine Hypothese bleibt und keine bestätigte Regel für die erste Version ist.
• In der Kurzzusammenfassung steht, dass Benachrichtigungen nach der Zeitzone des Nutzers gesendet werden sollen – das Backend gleicht dies mit den Quellen ab und bestätigt, dass in der aktuellen System die Zeitzone nur auf Client-Ebene gespeichert wird und Übergänge zwischen Zeitzonen und DST separat geprüft werden müssen.
• Die AI hat die Versandhistorie als „offensichtlichen“ Teil der Lösung ergänzt – Product Owner und BA entscheiden separat, ob dies ein Pflichtteil der ersten Version oder eine Verbesserung des nächsten Releases ist, weil hier auch die Frage nach Audit und Supportlast besteht.
• QA erhält nicht nur eine Liste von Grenzfällen, sondern eine konkrete Aufgabe: Duplikate bei erneutem Start von Scheduler-Aufgaben prüfen, sprachliche Fallback-Szenarien, Ausnahmen für archivierte und deaktivierte Nutzer sowie Negativszenarien rund um Deadlines.
• Das Backend prüft separat Rate Limits, Throttling, Deliverability und wie sich das System bei wiederholten Sendungen und Anbieterfehlern verhält.
• PO und BA validieren zusätzlich die Benachrichtigungsrichtlinie: Wem dürfen Erinnerungen gesendet werden, wo sind Opt-out oder kundenspezifische Ausnahmen nötig, und was gilt als zulässiges Verhalten für Pflichtkurse.

Für einen solchen Fall ist es sinnvoll, auch zwei praktische Dinge separat anzusprechen, die oft erst näher an der Produktion auftauchen: Deliverability wird schnell zur Last für den Support und das Kundenbetreuungsteam, wenn es keine ordentliche Diagnose „warum die E-Mail nicht angekommen ist“ gibt, und Quiet Hours sowie Kalenderfenster erweisen sich nicht selten nicht als „zusätzliche Option“, sondern als Unternehmensanforderung des Kunden.

Wer was manuell prüft

Was wir prüfen	Wer ist verantwortlich	Beispiel im LMS-Fall
Ziel und Produktrichtlinie	PO und BA	Wem und wann Erinnerungen gesendet werden, welche Ausnahmen zulässig sind, wo die Grenzen der ersten Version liegen.
Korrektheit von Regeln und Status	BA	Welche Status als „nicht abgeschlossen“ gelten, was mit expired zu tun ist und wo dies bereits durch Quellen bestätigt ist.
Architektonische Einschränkungen	Backend-Entwickler	Deduplizierung, Scheduler-Aufgaben, Idempotenz, Audit-Log, Rate Limits und Verhalten bei wiederholten Sendungen.
UI-Grenzen der ersten Version	Frontend-Entwickler und UX/UI-Designer	Wo die Einstellungen liegen, ob ein separater Verlaufsbildschirm nötig ist und welche Interface-Szenarien tatsächlich zur ersten Version gehören.
Negative und zeitliche Szenarien	Qualitätsingenieur / QA-Ingenieur	DST, Zeitzonen, sprachliche Fallback-Szenarien, Ausnahmen für archivierte und deaktivierte Nutzer sowie Duplikate bei erneutem Start von Scheduler-Aufgaben.
Moderation von Entscheidungen und offenen Fragen	Scrum Master	Was bereits entschieden ist, was strittig bleibt und wo das Team einen bewussten Kompromiss eingehen muss.
Datenhygiene und Zulässigkeit der Daten	PO/BA und, falls vorhanden, Security oder DPO	Was an das Modell übergeben werden darf, was anonymisiert werden muss und welche Prüfungen vor dem Start der AI-Vorbereitung Pflicht sind.

Was ich dem Team empfehlen würde

• Den AI-Entwurf nicht allein deshalb als fertige Aufgabe betrachten, weil er gut aussieht.
• Klar vereinbaren, welche Teile des Kontexts das Team vor dem Meeting manuell prüfen muss und welche erst im Meeting selbst.
• Eigene Produkt- und Prozessmuster schrittweise in die KI-Schicht des Teams übertragen, statt nur einen allgemeinen Chat „wie er ist“ zu nutzen.
• Refinement nicht mechanisch verkürzen, nur weil die Vorbereitung schneller geworden ist.
• Bewusst entscheiden, wohin die freigewordene Zeit fließt: in Qualität, Lernen, Dokumentation, technische Schulden oder die Wiederherstellung der Aufmerksamkeit des Teams.

Besonders wichtig ist es, sich der Grenzen der Anwendbarkeit dieses Szenarios bewusst zu sein. Der Effekt von KI wird sehr unterschiedlich sein, je nach Reife der Dokumentation, Verfügbarkeit interner Quellen, Domänenkomplexität des Produkts und danach, wie gut das Team implizites Wissen in wiederholbaren Kontext verwandeln kann. Dort, wo die Ausgangsdaten schwach sind, kann KI die Verpackung beschleunigen, aber nicht unbedingt die Qualität der Entscheidungen verbessern.

Fazit

Ganz kurz gesagt, würde ich den Haupteffekt von KI für Refinement so formulieren: KI beschleunigt nicht die Vereinbarung des Teams selbst, sondern die Vorbereitung des Materials dafür. Genau deshalb wird Refinement am Eingang schneller: Kontext wird schneller gesammelt, ein Entwurf entsteht schneller, grundlegende Fragen und Risiken werden schneller erkannt, Ergebnisse werden schneller verpackt.

Aber das macht Refinement nicht automatisch einfacher. Denn sobald die Kosten der Vorbereitung sinken, steigt der Wert dessen, was KI noch nicht wirklich gut kann: die Domäne verstehen, reale Einschränkungen spüren, falsche Klarheit erkennen, sorgsam mit Daten umgehen und dem Team helfen, bewusste Kompromisse zu treffen.

Deshalb ist die beste Sicht auf KI im Refinement diese: Sie nimmt einen Teil der teuren manuellen Arbeit rund um die Praxis ab, macht aber die menschliche Prüfung des Sinns noch wichtiger. Je einfacher es wurde, Backlog Items zu produzieren, desto wichtiger wurde zu verstehen, welche davon wirklich zur Diskussion bereit sind und welche nur gut aussehen. Und in den nächsten Artikeln der Serie wird es interessant sein zu sehen, wie diese Verschiebung nicht nur den Prozess, sondern auch die Kultur der Nutzung von Teamzeit beeinflusst.

Quellen und Orientierungspunkte

• Scrum Guide 2020 (RU PDF)
• Scrum Guide 2017 (RU PDF)
• Challenges in applying large language models to requirements engineering tasks
• AI-Generated User Stories: Are They Good Enough?
• LLM-Assisted Requirements Engineering in Agile MDD
• Large Language Models (LLMs) for Requirements Engineering (RE): A Systematic Literature Review
• On Faithfulness and Factuality in Abstractive Summarization
• Automation Bias in AI-Decision Support: Results from an Empirical Study
• Examining human reliance on artificial intelligence in decision making
• NIST-Profil für generative KI
• EDPB Opinion 28/2024 on certain data protection aspects related to AI models
• EDPS guidance on Generative AI (2025)
• GDPR Article 5
• CNIL: AI system development recommendations