Product Owner und KI-Agenten: Wer schreibt jetzt die Anforderungen?

Ich schreibe Anforderungen in zwei Rollen. Hauptberuflich bin ich Product Owner bei der ING, und was ich aufschreibe, setzen Menschen um. Nebenbei baue ich iOS-Apps und diese Website, inzwischen mit Coding-Agenten, und was ich dort aufschreibe, setzt ein Modell um. Legt man beides nebeneinander, sieht man, wie viel ein Team bisher ausgeglichen hat, ohne dass es im Ticket stand.

Die Bilanz im Beitrag KI-gestützte Programmierung ein Jahr später lautete: Der Engpass ist nicht mehr das Schreiben von Code, sondern die Urteilskraft darüber. Das war der Blick aus der Entwicklung, auf das Review danach. Hier geht es um den Schritt davor: um das, was im Ticket steht, bevor Code entsteht.

Die höchste Mauer

Im Beitrag über Silos ging es um die Übergabe: Ein Team wirft etwas über die Mauer, und auf der anderen Seite fehlt die Absicht. Bei einem Coding-Agenten ist diese Mauer so hoch, wie sie nur sein kann. Der Agent war bei keinem Refinement dabei. Er kennt die Stakeholder nicht, hat die Diskussion nach dem Meeting nicht gehört und weiß nicht, welcher Randfall schon einmal Ärger gemacht hat. Er hat nur, was aufgeschrieben ist.

Ein menschliches Team füllt Lücken im Ticket. Es fragt nach, kennt die Geschichte des Produkts, erinnert sich an die Entscheidung aus dem letzten Quartal. Ein Agent füllt Lücken auch, aber in der Regel ohne Rückfrage: mit der naheliegendsten Annahme. Bei widersprüchlichen Regeln entscheidet er sich still für eine, darum ging es in Der Agent widerspricht nicht. Bei Lücken ist es nicht anders. Das Ergebnis läuft, sieht fertig aus und löst eine etwas andere Aufgabe als die gemeinte.

GitHub hat das bei der Vorstellung von Spec Kit knapp formuliert: Sprachmodelle sind stark darin, Muster zu vervollständigen, aber nicht im Gedankenlesen. Ein vager Prompt zwingt sie, potenziell tausende unausgesprochene Anforderungen zu raten.

Wenn Code billig wird, wird die Anforderung teuer

Solange die Umsetzung Wochen dauert, wird eine ungenaue Anforderung unterwegs korrigiert: im Daily, beim Pairing, in der Rückfrage am Nachbartisch. Erledigt ein Agent dieselbe Arbeit in einer Stunde, fallen diese Schleifen weg. Die Anforderung wird nicht nachgeschärft, sondern ausgeführt. Was drinsteht, wird gebaut. Was fehlt, wird geraten.

Damit verschiebt sich, welches Dokument zählt. Im GitHub-Blog heißt es, man bewege sich weg von "der Code ist die Quelle der Wahrheit" hin zu "die Absicht ist die Quelle der Wahrheit". Das klingt nach Konferenzfolie, der Mechanismus dahinter ist aber schlicht: Wenn sich Code aus einer Spezifikation neu erzeugen lässt, ist die Spezifikation das, was gepflegt werden muss.

Was eine ausführbare Anforderung enthält

Die Dokumentation von Claude Code beschreibt ziemlich genau, wie eine Spezifikation aussieht, die ein Agent abarbeiten kann. Die nützlichsten sind in sich geschlossen: Sie nennen die beteiligten Dateien und Schnittstellen, sagen, was nicht dazugehört, und enden mit einer End-to-End-Prüfung, die zeigt, dass das Feature funktioniert. Dazu kommt ein Satz, der auch in eine PO-Schulung gehört: Zeit, die in eine präzise Spezifikation fließt, zahlt sich mehr aus als Zeit, in der man der Umsetzung zusieht. Für größere Features empfiehlt die Dokumentation außerdem, sich vorher vom Agenten interviewen und ihn daraus die Spezifikation schreiben zu lassen. Das ist ein Refinement, nur anders besetzt.

Für Product Owner ist das bekanntes Terrain, nur strenger. In die Sprache des Backlogs übersetzt:

• Akzeptanzkriterien, die sich ausführen lassen. "Die Suche soll schnell sein" ist für Menschen ein Gesprächsanlass und für einen Agenten ein Freibrief. Ein Kriterium, aus dem sich ein Test ableiten lässt, ist keins von beidem. Die Dokumentation nennt den Grund: Der Agent hört auf, wenn die Arbeit fertig aussieht. Ohne eine Prüfung, die er selbst ausführen kann, ist "sieht fertig aus" das einzige Signal.
• Abgrenzung. Was nicht zum Umfang gehört, stand selten im Ticket, weil das Team es ohnehin wusste. Ein Agent weiß es nicht und räumt dann gern nebenbei noch etwas mit auf.
• Entscheidungen samt Begründung. Eine Regel ohne Grund wird irgendwann gebrochen, von Menschen wie von Modellen. In meinen Nebenprojekten liegt neben dem Code eine Datei, die Entscheidungen festhält und jeweils sagt, warum. Für diese Website steht dort zum Beispiel, warum interne Links keine .html-Endung tragen: Google hatte über solche Links die doppelten Adressen gefunden und die richtigen nicht indexiert. Das ist Produktkontext, nur in einer Form, die eine Maschine zu Beginn jeder Sitzung liest.
• Kontext, der sonst im Kopf steckt. Zielgruppen, regulatorische Randbedingungen, die Vorgeschichte eines Features. Was bisher mündlich weitergegeben wurde, muss irgendwo stehen, sonst existiert es für den Agenten nicht.

Mehr Text heißt dabei nicht besser. Was für Instruktionsdateien gilt, gilt auch hier: Eine Anforderung, die alles erwähnt, versteckt das Wichtige. Präzise heißt kurz und prüfbar.

Was sich für die Rolle verschiebt

Der Scrum Guide 2020 schreibt der Rolle Product Owner unter anderem zu, Product-Backlog-Einträge zu erstellen und klar zu kommunizieren, ihre Reihenfolge festzulegen und sicherzustellen, dass das Product Backlog transparent, sichtbar und verstanden ist. Keiner dieser Punkte verschwindet mit Agenten. Die Gewichte verschieben sich.

Spezifikation. "Klar kommunizieren" hieß bisher oft: im Gespräch klären. Ein Agent kennt nur, was schriftlich klar ist. Das Schreiben trägt damit mehr als vorher.

Reihenfolge. Wenn Umsetzung billig wird, begrenzt nicht mehr die Kapazität, was entsteht. Was ohne strenge Auswahl herauskommt, zeigt im Großen die Flut generierter Apps, von denen kaum eine ein Publikum findet. Ein Backlog, das schneller abgearbeitet wird, braucht deshalb eine strengere Reihenfolge, keine lockerere.

Abnahme. Das Review rückt nach vorn und kommt häufiger. Spec Kit baut in jede Phase einen Prüfpunkt ein, an dem ein Mensch nachsieht, bevor es weitergeht. Der Satz dazu: Die KI erzeugt die Artefakte, du stellst sicher, dass sie stimmen. Für Product Owner heißt das, früher und öfter auf Ergebnisse zu schauen, nicht erst im Sprint Review.

Marty Cagan ging im Februar 2025 weiter: Discovery sei vor allem Urteilskraft, Delivery deutlich stärker Prozess. Seine Erwartung: In drei bis zehn Jahren verbringen Produktteams fast ihre ganze Zeit mit Discovery. Man muss diese Prognose nicht teilen, um die Richtung zu sehen. Was sich automatisieren lässt, liegt auf der Delivery-Seite.

Die Grenzen

So weit die These. Sie hat Grenzen, einige davon grundsätzlich.

Verantwortung lässt sich nicht delegieren. Der Scrum Guide ist da eindeutig: Product Owner ist "eine Person, kein Gremium". Arbeit darf delegiert werden, ergebnisverantwortlich bleibt die Rolle trotzdem. Ein Agent kann eine Spezifikation entwerfen, Akzeptanzkriterien vorschlagen und Feedback zusammenfassen. Was ausgeliefert wird, entscheidet weiterhin ein Mensch. In regulierten Branchen wie dem Bankwesen ist das keine Stilfrage.

Discovery findet bei den Nutzenden statt. Ein Agent kann aus einem Ticket Code machen. Ob das Ticket das richtige Problem beschreibt, weiß er nicht. Das erfährt man nur im Gespräch mit Nutzenden, im Test, in der Beobachtung. Der DORA-Bericht 2025 nennt den Fokus auf die Nutzenden eine Voraussetzung für den Erfolg mit KI. Laut seinen Daten verstärkt dieser Fokus den positiven Einfluss von KI auf die Leistung eines Teams.

KI ist ein Verstärker. Laut demselben Bericht nutzen 90 Prozent der Befragten KI bei der Arbeit. Seine Kernaussage: KI repariert kein Team, sie verstärkt, was schon da ist. Ein Team mit schlechten Anforderungen bekommt durch Agenten keine besseren Anforderungen, sondern schneller schlechte Software.

Das Framework kennt keine Agenten. Im Scrum Guide 2020 kommen KI und Agenten nicht vor. Das Scrum Team ist dort ausdrücklich "ein kleines Team von Menschen". Ob ein Agent dazugehört, ein Werkzeug ist oder etwas dazwischen, lässt der Guide offen. Das ist kein Vorwurf an ein Dokument von 2020, heißt aber: Wer Agenten einsetzt, muss die Regeln dafür selbst festlegen. Wer prüft den Code der Agenten? Wer darf ein Ticket direkt an einen Agenten geben? Was gilt als Done?

Tickets lesen auch Menschen. Wer Anforderungen nur noch für Maschinen optimiert, schreibt irgendwann am Team vorbei. Ein Ticket, das nur aus Dateipfaden und Testfällen besteht, sagt dem Team, was zu bauen ist, aber nicht mehr, wofür.

Fazit

Die Anforderung war schon immer das, was Product Owner abliefern. Neu ist, dass sie jetzt beim Wort genommen wird. Damit zählt, was zur Rolle schon immer gehörte: genau aufschreiben, streng ordnen, früh prüfen. Wer schreibt jetzt die Anforderungen? Dieselbe Rolle wie vorher. Nur liest jetzt jemand mit, der nicht von selbst nachfragt.

Quellen

• Ken Schwaber und Jeff Sutherland: Der Scrum Guide (November 2020) - Aufgaben der Rolle Product Owner, "eine Person, kein Gremium", Ergebnisverantwortung, "ein kleines Team von Menschen"; englisches Original
• Anthropic: Best practices for Claude Code - Aufbau einer Spezifikation, Interview vor der Spezifikation, "sieht fertig aus" als einziges Signal
• GitHub Blog: Spec-driven development with AI: Get started with a new open source toolkit - Mustervervollständigung statt Gedankenlesen, Absicht als Quelle der Wahrheit, Prüfpunkte in jeder Phase (Den Delimarsky, 02.09.2025)
• Google Cloud: Announcing the 2025 DORA Report - Nutzung von KI, KI als Verstärker, Fokus auf Nutzende (23.09.2025)
• Silicon Valley Product Group: A Vision For Product Teams - Marty Cagan über Discovery und Delivery (25.02.2025)