Ich hatte eine saubere Abhängigkeitsanalyse gebaut. Welche Story hängt an welcher, was muss zuerst passieren, solide Arbeit, auf die ich mich verlassen wollte. Wochen später plane ich auf ihrer Basis weiter und merke: Eine der Stories gibt es so nicht mehr. Das Team hatte sie im Jira längst in zwei Tickets gesplittet. Meine Analyse zeigte auf etwas, das es nicht mehr gab.

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“