Ich hatte eine wirklich gute Story. Sauber abgegrenzt und vorher geprüft. Dann lege ich sie einem Team vor und ernte Stirnrunzeln. Nicht wegen des Inhalts. Wegen der Form. „So schreiben wir das hier nicht.“ Ich hatte brav Given-When-Then geliefert, dabei wollte dieses Team knappe, prüfbare Sätze, drei Zeilen und fertig. Inhaltlich top, im Ton komplett daneben.

Seitdem weiß ich: Ich muss meine Jira-Tickets an das Team anpassen und nicht umgekehrt. Eine Story wird nämlich nicht akzeptiert, weil ich sie gut finde. Sie wird akzeptiert, weil das Team sich darin wiederfindet.

Und genau hier schließt sich der Kreis zu dem, womit diese Serie angefangen hat.

Warum „keine KI-Stories“ oft gar nicht an der KI liegt

Erinnerst du dich an den Satz aus Teil 1, „KI-generierte Stories wollen wir nicht lesen“? Ich glaube, dieser Reflex hat oft weniger mit der KI zu tun, als es scheint. Er hat damit zu tun, dass ein Ticket von außen reingekippt wirkt, wenn es nicht zur Arbeitsweise des Teams passt.

Teams haben eine DNA. Das eine liebt Given-When-Then. Das andere findet das aufgeblasen und will drei knappe, testbare Sätze. Ein erfahrenes Team wiederum will Implementierungshinweise gar nicht auf der ersten Seite sehen, weil es das Wie sowieso selbst entscheidet. Dazu kommen dann noch Pflicht-Labels, Versionsangaben und Konventionen, die von Projekt zu Projekt anders aussehen.

Passt das alles nicht, ist die Story fremd. Und fremde Tickets liest keiner gern, egal ob ein Mensch oder eine KI sie geschrieben hat.

Erst die Entscheidung, dann die Form

Bevor eine Story überhaupt in diese Form gebracht wird, kommt der Schritt, der mir am wichtigsten ist: die Finalisierung. Nach dem Review aus Teil 4 setze ich mich in einer zweiten, kurzen Runde mit den offenen Punkten auseinander. Blocker klären, Widersprüche auflösen, entscheiden. Eine Frage nach der anderen, wie im Interview. Nur dass es jetzt nicht mehr ums Erheben geht, sondern ums Entscheiden.

Erst wenn diese Entscheidungen stehen, wird die Story final. Die Form kommt danach, und sie ist alles andere als Beiwerk: An ihr entscheidet sich Annahme oder Ablehnung.

Jira-Tickets an das Team anpassen: konfiguriert, nicht improvisiert

Deshalb konfiguriere ich das Ziel-Template pro Jira-Projekt einmal fest. Wie eine Story am Ende aussieht, bestimmt dann das Projekt und nicht meine Tagesform:

• Akzeptanzkriterien-Format – Given-When-Then, knappe prüfbare Sätze, oder was auch immer das Team lebt.
• Pflicht- und optionale Labels – automatisch gesetzt, keine manuelle Fummelei.
• Fix-Version – aus den offenen Releases vorbefüllt.
• Implementierungshinweise – an, aus, oder bewusst getrennt vom Rest.
• Epic-Zuordnung und Priorität – nach der Konvention des Teams.

Die KI kippt das Ticket also nicht in irgendeiner generischen Form ins Jira. Sie gießt die entschiedene Story in genau die Form, in der dieses eine Team arbeitet.

Dieselbe Story, drei Teams

m konkretesten wird das, wenn dieselbe Anforderung durch drei Teams läuft. Nehmen wir „alte Daten automatisch aufräumen“:

Team A bekommt Given-When-Then: Gegeben ein Postfach über der Quota, wenn der Nutzer „Aufräumen“ wählt, dann werden Daten älter als zwölf Monate archiviert.

Team B bekommt knappe, prüfbare Sätze: Daten älter als zwölf Monate werden archiviert, nicht gelöscht. Vorschau vor der Bestätigung. Aktion ist widerrufbar.

Team C ist ein eingespieltes Team und bekommt nur das knappe Kriterium. Die Implementierungshinweise stehen bewusst getrennt und tauchen nicht auf Seite eins auf, weil dieses Team das Wie selbst bestimmt.

Die Absicht ist in allen drei Fällen dieselbe, nur die Form ändert sich. Das Team ans Werkzeug zu zwingen wäre der falsche Weg, also macht es das Werkzeug andersherum.

Warum das der eigentliche Akzeptanz-Hebel ist

Am Ende zählt nicht, wie gut ich eine Story finde, sondern ob das Team sie annimmt und damit arbeiten kann. Ein Ticket, das sich anfühlt, als hätte es jemand aus dem Team selbst geschrieben, wird angenommen. Eines, das nach Fremdkörper riecht, wird zerredet oder still ignoriert.

Die Form ist also kein kosmetischer letzter Schritt. Sie ist der Punkt, an dem sich entscheidet, ob der ganze Aufwand aus Interview und Review überhaupt beim Team ankommt.

Was ich lange falsch gemacht habe

Die beste Anforderungsarbeit nützt nichts, wenn sie an der Arbeitsweise des Teams vorbeigeht. Content und Form sind zwei getrennte Qualitäten, und ich habe jahrelang nur auf die erste geschaut.

Die Story von damals liegt heute in drei verschiedenen Teams. Dreimal derselbe Kern, dreimal eine andere Form. Und dreimal dasselbe Gefühl im Team: Das ist unser Ticket.

Alle Teile der Serie: Zur Themenseite „Requirements Engineering Pipeline“