Das ist das Problem, das ein Obsidian Jira Sync lösen muss: Nach der Übergabe lebt das Ticket im Jira weiter, mein Vault-Stand bleibt stehen. Und ich merke es nicht, bis ich auf veraltetem Stand plane.

Die naheliegende Lösung wäre ein bidirektionaler Sync, der alles überall synchron hält. Genau die habe ich bewusst nicht gebaut.

Der Schmerz: zwei Wahrheiten, die auseinanderlaufen

Bis zur Übergabe entsteht alles bei mir: Backlog, Planung, Stories, Analysen. Dann geht das Ticket ans Team, und ab da entwickelt es sich in Jira weiter: neu geschnitten, um Akzeptanzkriterien ergänzt, in Sprints gehängt, im Status bewegt.

Diese Änderungen finden keinen Weg zurück in meinen Vault. Mein Stand fossiliert. Das eigentlich Gefährliche sind dabei nicht die auseinanderlaufenden Texte, das ist ärgerlich, aber sichtbar. Gefährlich sind die Dinge, die auf der Story aufbauen. Allen voran die Abhängigkeitsanalyse. Wird eine Story im Refinement neu geschnitten, ist meine Analyse still ungültig, ohne dass es mir irgendwer sagt.

Autorität wandert, sie wird nicht geteilt

Mein Prinzip dagegen ist einfach: Zu jedem Zeitpunkt besitzt genau ein System die Wahrheit. Vor der Übergabe ist das der Vault, dort führe ich Regie. Ab dem Moment, in dem das Ticket ins Jira geht, führt Jira. Bei allem, auch beim Inhalt.

Diese Übergabe ist der Staffelstab. Er wird einmal übergeben, nicht ständig hin- und hergereicht. Das erspart mir den ganzen Ärger, den ein Feld-für-Feld-Merge mit sich bringt: keine Konflikte, keine Endlosschleifen, keine Frage „wer hat zuletzt recht“. Ein klarer Schnitt.

Der Preis dafür ist Disziplin: Nach der Übergabe steuere ich inhaltlich nicht mehr aus dem Vault nach. Will ich etwas ändern, passiert das im Jira-Refinement, dort, wo jetzt die Wahrheit liegt

Obsidian Jira Sync: einseitig und geschichtet

Weil die Autorität exklusiv ist, wird der Sync radikal einfach. Er läuft nur in eine Richtung: von Jira in den Vault. Er schreibt nie nach Jira zurück.

Und er überschreibt meine Story nicht. Meine ursprüngliche Fassung (das Warum, die Reviews, die Verlinkungen, alles, was Jira nie haben wird) bleibt als mein Denk-Anker erhalten. Darüber legt sich ein reiner Lese-Spiegel des Jira-Stands: aktueller Status, Sprint, ob sich etwas verändert hat. Zwei Schichten, sauber getrennt, die sich nie in die Quere kommen.

Technisch holt der Sync nur die Deltas, die Tickets, die sich seit dem letzten Abgleich geändert haben. Das ist billig und liefert genau das, was ich wissen will: Was ist seit meiner Übergabe aus meiner Story geworden?

Der versteckte Mehrwert: der Drift-Report

Das Ergebnis ist ein kurzer Report. Reine Jira-Änderungen wie Status oder Sprint werden still gespiegelt, die muss ich nicht bestätigen. Inhaltliche Abweichungen, etwa ein Story-Split oder ein neu ergänztes Akzeptanzkriterium, werden mir gezeigt. Neue Fremd-Tickets, die Kollegen direkt im Jira angelegt haben, tauchen als Hinweis auf.

Und dann der Punkt, für den ich das Ganze eigentlich gebaut habe: Wenn eine Story sich verändert hat, prüft der Sync automatisch, welche meiner Vault-Artefakte auf dieses Ticket verweisen, und markiert sie. Genau die Abhängigkeitsanalyse, die mir damals stillschweigend unter den Händen ungültig geworden ist, wird jetzt aktiv als betroffen geflaggt.

Das ist „alles im Griff“: nicht nur das einzelne Ticket, sondern alles, was daran hängt. Ich plane nie wieder auf veraltetem Stand, weil die Drift sichtbar wird, bevor sie schadet.

Was mir gehört, bleibt mir

Auch hier gilt, was sich durch die ganze Serie zieht: Meine ursprüngliche Fassung liegt als Klartext-Markdown in Obsidian und bleibt meine. Jira besitzt den Ausführungszustand ab der Übergabe, ich besitze die Absicht, für immer. Der Spiegel ist ein Zusatz, kein Ersatz. Fällt er weg, habe ich immer noch mein vollständiges Denken vor mir.

Das große Ganze

Damit ist die Serie rund. Sechs Teile, ein durchgehender Gedanke:

Ich habe beim Schmerz angefangen: Duplikate, vergessene Entscheidungen, Stories im Vakuum, driftende Planung. Dann kam das Fundament: eine Wissensbasis, damit die KI nicht rät, sondern nachliest. Darauf das Interview, das aus einer Idee einen durchdachten Draft macht. Das Review, das sechs Perspektiven gleichzeitig draufschauen lässt. Die Übersetzung in die Sprache des Teams, damit die Story ankommt. Und zum Schluss die saubere Übergabe.

Der rote Faden durch all das: Der Mensch besitzt die Absicht, die Agenten besitzen die Prüfung. Die KI schreibt bei mir keine Stories, sie prüft, gleicht ab, hinterfragt und spiegelt. Entschieden habe am Ende immer ich. Und weil alles Klartext in Obsidian ist, bleibe ich handlungsfähig, auch wenn die KI mal nicht da ist.

Genau das ist der Unterschied zwischen einer KI, die dir die Arbeit abnimmt, und einer, die dich bei deiner Arbeit besser macht. Ich will die zweite.

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

Der Beitrag Obsidian Jira Sync: der Staffelstab, wenn das Team übernimmt erschien zuerst auf Das ist die Welt von Thomas.

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“

Der Beitrag Jira-Tickets an das Team anpassen: Warum die Story die Sprache des Teams sprechen muss erschien zuerst auf Das ist die Welt von Thomas.