Von Jira zu KI-Agenten: Vom Projektmanagement-Tool zur Projektwissen-Architektur

In Kürze: Von Jira zu KI-Agenten

Jira wurde nach Godzilla benannt und zur Fehlerverfolgung entwickelt. Es wurde zum Standard-Tool für agile Teams, weil es einem zutiefst menschlichen Bedürfnis entgegenkam: die Arbeit kontrollieren, indem man sie anhand von Status, Verantwortlichen und Fälligkeitsdaten kategorisiert. Dieses System funktioniert für Menschen, die Dashboards scannen. Es funktioniert nicht für autonome Agenten, die Muster über Iterationen hinweg erkennen, wiederkehrende Probleme aufspüren und vorhersagen müssen, was als Nächstes scheitert. Dieser Artikel argumentiert, dass das Tool, auf das 62 % der agilen Teams vertrauen, kurz davor steht, von der Wissensautorität zur Ausführungsoberfläche degradiert zu werden. Wir müssen den Wechsel von Jira zu KI-Agenten vollziehen.

---

🎓 🇬🇧 🤖 The Claude Cowork BootCamp — $149

Cowork turns Claude into an autonomous AI agent who works on your tasks independently; no coding required.

In this hands-on founding cohort, you will build your own AI agents from scratch, using your real work challenges:

• Three Wednesday sessions, three hours each, April 15 to 29, 2026, at 3 pm CEST / 9 am ET. Limited spots.
• Prerequisite: Claude Pro subscription and the Claude Desktop app on macOS or Windows.

👉 Start Building Agents: Claude Cowork BootCamp: Build Your Own AI Agent, No Coding Required.

---

🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 35,000-plus subscribers.

🎓 Join Stefan in one of his upcoming Professional Scrum training classes!

---

Jiras Ursprung

Im 17th Annual State of Agile Report (2023) nannten 62 % der Befragten Jira als ihr agiles Tool auf Teamebene. (Die 18. Ausgabe, veröffentlicht im Oktober 2025, verlagerte ihren Fokus vollständig auf KI und enthielt keine Fragen zur Tool-Nutzung mehr.) Die 2024 Stack Overflow Developer Umfrage ergab, dass 57,5 % der professionellen Entwickler Jira als kollaboratives Arbeitsmanagement-Tool nutzen. Atlassian gibt an, dass mehr als 300.000 Unternehmen Jira eingeführt haben.

Jira wurde nicht für agile Arbeit entwickelt. Atlassian brachte es in den frühen 2000er Jahren als Issue-Tracker auf den Markt. Der Name ist eine Verkürzung von „Gojira“, dem japanischen Wort für Godzilla, womit Atlassians Entwickler Bugzilla bezeichneten, den Bug-Tracker, den sie intern nutzten, bevor sie ihren eigenen bauten. Agile Funktionen kamen im Laufe der Zeit hinzu: Atlassian übernahm GreenHopper 2009 und fügte Release-Planung, Burndown-Charts sowie die Agile-Board-Funktionen hinzu, die zum Standard in Jira wurden. Scrum Boards wurden 2012 zu einer integrierten Jira-Funktion. Das zugrunde liegende Objektmodell blieb jedoch Issue-zentriert. Alle agilen Funktionen Jiras sitzen auf einer Ticket-Datenbank.

Die Ticket-System-DNA verschwand nie. Pflichtfelder, Statusübergänge, Workflow-Schemata: Alles geht davon aus, dass Arbeit ein Ticket ist, das verfolgt wird, aber kein Problem, das gelöst werden muss. Viele Praktiker wissen das. Manche verabscheuen Jira offen. Andere tolerieren es, weil der Einkauf es vor einem Jahrzehnt freigegeben hat und die Wechselkosten prohibitiv erscheinen.

Die nächste Herausforderung dreht sich nicht um die resultierende Reibung im Alltag, sondern um die Frage, wer im Zeitalter von KI Projektdaten konsumiert und was diese Konsumenten von den Daten brauchen.

Cannot see the form? Please click here.

Wie Jira zum Standard wurde

Zwischen 2002 und 2010 verbreitete sich Jira in Organisationen so, wie die meiste Enterprise-Software sich verbreitet: Die IT installierte es für das Bug-Tracking, und als Teams beschlossen, „agil zu werden“, war es bereits da. Nach der Übernahme von GreenHopper 2009 hatte Jira agile Boards, aber sie waren lediglich eine Ansichtsebene für die Ticket-Datenbank. Die Diskrepanz war handhabbar, weil die Teams klein waren und die Scrum-Events kompensierten, was das Tool nicht leisten konnte.

Zwischen 2010 und 2020 machte die Einführung von „Agile“ in Unternehmen Jira zum Standard, weil der Einkauf es bereits freigegeben hatte. Der Atlassian Marketplace startete 2012, und das Plugin-Ökosystem verstärkte die Abhängigkeit. Organisationen passten Jira umfangreich an. In meiner Beratungspraxis für europäische Unternehmen habe ich Jira-Instanzen mit über 300 benutzerdefinierten Feldern gesehen; das ist keine Seltenheit. Jira wurde zum System of Record, aber die Aufzeichnung, die es führte, war für den menschlichen Dashboard-Konsum optimiert: Statusaktualisierungen, Burndown-Charts, Velocity-Grafiken. Daten gingen als Tickets hinein und kamen als Berichte heraus, die Menschen auf Bildschirmen lasen. (Ich erinnere mich noch an das „Definition of Ready“-Plugin und den daraus resultierenden Bericht, auf den ein VP eines Kunden jeden einzelnen Sprint bestand. Er war an diesem Output mehr interessiert als am gelieferten Kundenwert.)

Das Problem mit Jira im Zeitalter der KI-Agenten

Seit 2020 hat KI die Fragestellung verändert. Praktiker wollten Sprint-Muster über die Zeit analysieren, Lieferrisiken vorhersagen, die Gesundheit des Produkt-Backlogs bewerten und Abhängigkeiten automatisch abbilden. Sie versuchten, Kontext aus Jira zu extrahieren. Was sie bekamen, war eine API, die Ticket-Metadaten zurückgibt: Status, Verantwortlicher, Priorität, Übergänge. Die zeitliche Dimension, wie sich Dinge über Sprints hinweg veränderten, ist in Issue-Historien vergraben, die mehrere API-Aufrufe und Interpretationen erfordern, um sie zu rekonstruieren. Beziehungen zwischen Artefakten sind implizit, verborgen in Issue-Links und Kommentar-Threads. Jira speichert Workflow-Status und fragmentierten Kontext. Es speichert kein kohärentes, versioniertes Wissensmodell, das für zeitübergreifendes Reasoning optimiert ist.

Atlassians Antwort ist ernst zu nehmen

Atlassian steht nicht still, und ihre KI-Bemühungen abzutun wäre unehrlich.

Sie bauten Atlassian Intelligence über Jira, Confluence und Jira Service Management hinweg auf. Sie entwickelten Rovo, eine KI-Ebene, die semantische Suche, Chat und Agenten-Fähigkeiten bietet. Im Februar 2026 kündigten sie direkt in Jira eingebettete KI-Agenten an (offene Beta), die es Teams ermöglichen, Arbeit an Rovo-Agenten und MCP-fähige Drittanbieter-Agenten zuzuweisen. Sie übernahmen das Model Context Protocol, um Rovo mit externen KI-Clients zu verbinden, darunter Claude, Cursor und die Gemini CLI.

Unter all dem sitzt der Teamwork Graph, den Atlassian als Datenintelligenz-Ebene seiner Plattform beschreibt. Er vereint Daten zu Atlassian-Produkten sowie zu über 100 verbundenen Drittanbieter-Apps. Zum Zeitpunkt dieses Artikels gibt Atlassian an, dass der Teamwork Graph über 100 Milliarden Objekte und Beziehungen verfolgt. Der Teamwork Graph ist kein Anbau, sondern eine Infrastruktur, die KI-Funktionen ein reichhaltigeres Datenmodell bieten soll als rohe Jira-Tickets.

Atlassians Argument ist klar: Intelligenz dort aufbauen, wo die Daten bereits liegen, statt Organisationen zu bitten, von Grund auf neue Informationsarchitekturen aufzubauen. Das ist eine vernünftige Position: Für Organisationen, die bereits tief im Atlassian-Ökosystem stecken, sind Rovo und der Teamwork Graph der Weg des geringsten Widerstands. Gleichzeitig sichert sie Atlassian weitere Lizenzumsätze.

Allerdings bricht das Argument an dieser Stelle auch zusammen.

Der Teamwork-Graph verbindet die erfassten Elemente. Er bildet Beziehungen zwischen existierenden Objekten ab: Tickets, Seiten, Nachrichten, Benutzer und Projekte. Er kann sogar etwas Kontext aus verbundenen Drittanbieter-Systemen über seine 100+ Konnektoren sichtbar machen. Was er nicht vollständig kompensieren kann, ist Kontext, der nie explizit erfasst oder konsistent in einer Form strukturiert wurde, die Agenten-Reasoning über die Zeit unterstützt:

• Warum hat das Team den Scope in Sprint 23 geändert?
• Welchen Trade-off hat die Product Ownerin gemacht, als sie die Performance-Arbeit deprioritisierte?
• Welches Muster verbindet steigende Bug-Zahlen in einem Team mit sinkender Moral in einem anderen Team?

Dieses Wissen lebt in den Köpfen der Teammitglieder, in Meeting-Notizen, die nie im System landeten, in Slack-Threads, die vorbeiscrollten, in Retrospective-Ergebnissen, die ein Scrum Master auf einem Whiteboard festhielt, fotografierte, aber nie strukturierte.

Rovo kann einen Jira-Ticket-Thread zusammenfassen. Es kann natürliche Sprache in JQL übersetzen. Es kann Workflow-Übergänge automatisieren. All das ist nützlich. Aber es operiert innerhalb der Grenzen dessen, was Jira und verbundene Tools erfasst haben, und das Erfassungsmodell wurde für Menschen entworfen, die Ticket-Status verfolgen, nicht für Agenten, die über die Projektentwicklung im Laufe der Zeit nachdenken.

Von Jira zu KI-Agenten: Was Agenten brauchen, das Ticket-Systeme nicht bieten

Ein Agent, der Projektperformance analysiert, muss über Veränderungen im Zeitverlauf nachdenken. Nicht über den aktuellen Zustand eines Boards, sondern über die Trajektorie: Was war geplant, was geschah, was wurde gelernt und wie beeinflusste dieses Lernen den nächsten Zyklus.

Ein konkretes Szenario: Ein Scrum Master will verstehen, warum die Teamleistung zwischen den Sprints 22 und 24 abfiel. Der Agent braucht den Zustand des Product Backlogs zu Beginn von Sprint 22, die Verpflichtung, die das Team einging, was sich mitten im Sprint änderte, was die Retrospective zutage förderte, und wie diese Erkenntnisse die Sprint-23-Planung beeinflussten. Er muss drei Zeitpunkte vergleichen und Muster über die Übergänge hinweg erkennen.

In Jira sind diese Informationen in Issue-Historien, Kommentar-Zeitstempeln und Sprint-Reports verteilt. Ein kohärentes Bild zusammenzusetzen erfordert erheblichen Aufwand. Den meisten Praktikern fehlen die technischen Fähigkeiten, dies über die API zu extrahieren und zusammenzusetzen, und die meisten Agenten tun sich schwer, dies ohne strukturierten Input zuverlässig zu leisten.

Stellen Sie sich stattdessen folgende Informationsarchitektur vor. Das Projektwissen lebt in Markdown-Dateien, organisiert nach Sprints:

megabrain-io/
  sprint-22/
    sprint-goal.md
    selected-pbi.md
    daily-notes/
      day-01.md
      day-05.md
    retrospective-outcomes.md
    scope-changes.md
  sprint-23/
    sprint-goal.md
    selected-pbi.md
    ...
  team/
    working-agreements.md
    definition-of-done.md
    skills/
      retrospective-analyzer.md
      backlog-health-check.md

Jede Datei ist reiner Text. Jeder Sprint-Ordner ist ein Snapshot. Der team/skills/-Ordner enthält die Agenten-Konfigurationen, die das Team verwendet. Wenn jemand eine Konfiguration verbessert, ist die Änderung in der Versionshistorie sichtbar: was sich geändert hat, wer es geändert hat und wann.

Ein Agent liest den Sprint-22-Ordner, dann den Sprint-24-Ordner und vergleicht beide. Die zeitliche Dimension ist strukturell, nicht implizit. Die Beziehungen zwischen Artefakten sind explizit in der Dateiorganisation.

Ich habe einen kleinen Vergleich mit drei Sprint-Retrospective-Zusammenfassungen aus dem MegaBrain.io-Szenario meines Kurses durchgeführt, wobei ich dieselben zugrunde liegenden Daten in zwei Formaten verwendet habe. Das erste Format war ein einzelner fortlaufender Kommentar-Thread, so wie Retrospective-Ergebnisse typischerweise in einem Jira-Ticket landen: drei Absätze mit Notizen aus drei Sprints, mit Maßnahmen inline aufgelistet. Das zweite Format war drei separate Markdown-Dateien, eine pro Sprint, jeweils mit expliziten Abschnitten für Sprint Goal, Metriken, ungelöste Punkte aus vorherigen Sprints und Action Items mit Verantwortlichkeit und Status.

Ich gab beide einem KI-Agenten mit demselben Prompt: „Welche Muster erkennst du über diese drei Retrospectives hinweg? Was wurde identifiziert, aber nie gelöst?“

Die Markdown-Version deckte das Carry-over-Problem sofort auf: Scope-Änderungen wurden in Sprint 22 angesprochen, als offene Maßnahme nach Sprint 23 mitgenommen und in Sprint 24 immer noch ungelöst. Dasselbe galt für das Burnout-Risiko. Die Dateistruktur machte die Wiederholung sichtbar, weil der Abschnitt „Unresolved Issues“ jeder Datei explizit auf vorherige Sprints verwies. (Ja, mein geliebtes „Retrospective Action Item Accounting.“) Der flache Kommentar-Thread enthielt dieselben Informationen, jedoch eingebettet in Absätze, in denen das zeitliche Signal schwächer war. Die Analyse des Agenten aus dem Thread war weniger präzise hinsichtlich der Dauer und Persistenz der ungelösten Punkte.

Dieser Unterschied ist nicht dem Dateiformat inhärent. Ein Jira-Kommentar könnte mit denselben Abschnitten und dem Carry-over-Tracking strukturiert werden. Der Punkt ist, dass die Konvention „ein Ordner pro Sprint“ mit explizitem Status-Tracking eine zeitliche Struktur fördert, die ein flacher Kommentar-Thread nicht erzwingt. Die Konvention erledigt einen Teil der Arbeit des Agenten, bevor dieser beginnt.

Ich sollte ehrlich darüber sein, was dieser Vergleich verbirgt. Die Ordnerstruktur, die ich oben beschrieben habe, wird manchmal als „Vault“ bezeichnet, ein Begriff, der von Obsidian und ähnlichen Tools stammt, die einen Ordner mit Markdown-Dateien als eigenständige Wissensbasis behandeln. Ein echtes Vault, das von einem Team von sieben Personen über zwölf Sprints gepflegt wird, entwickelt eigene Probleme: Benennungsdrift, inkonsistente Struktur, Dateien, die jemand hätte hinzufügen sollen, aber nicht tat, und Merge-Konflikte, wenn zwei Personen dasselbe Dokument bearbeiten. Der Wartungsaufwand ist real. (Natürlich ist die Pflege von Jira auch nicht kostenlos.)

Beide Systeme werden unordentlich. Die Frage ist, welches Chaos einem Agenten mehr Material zum Arbeiten gibt. Ein unordentliches Markdown-Vault mit inkonsistenter Benennung, aber expliziten Sprint-Snapshots, gibt einem Agenten immer noch zeitlichen Kontext, den ein Jira-Board, wie gut auch immer gepflegt, teuer zu extrahieren macht, weil das Board nicht dafür entworfen wurde, seine eigene Historie in maschinenlesbarer Form zu bewahren.

Meine These ist nicht: „Markdown ist besser als Jira.“ Sie lautet: Agentische Projektarbeit braucht ein anderes Substrat als das, für das Legacy-Ticket-Systeme entworfen wurden. Die eigentliche Anforderung ist portables, versioniertes, agentenlesbares Wissen mit expliziten zeitlichen Snapshots. Markdown plus Git ist eine Implementierung. Es ist nicht die einzige. Confluence mit disziplinierten Export-Snapshots könnte einen Teil dieses Bedarfs decken. Eine Graph-Datenbank, die für temporale Abfragen konzipiert wurde, könnte es anders lösen. Das Prinzip zählt mehr als das Tooling.

Von Jira zu KI-Agenten: Klein anfangen, und Skalierung ist schwer

Ein einzelner Praktiker kann heute damit anfangen. Ein Ordner auf dem Laptop. Hierzu ist keine Genehmigung seitens der Organisation erforderlich. Der Wert zeigt sich zum ersten Mal, wenn Sie einen Agenten bitten, zwei Sprint-Retrospective-Ergebnisse zu vergleichen, und er ein Muster aufdeckt, das Ihre Jira-Berichte nie gezeigt haben.

Der schwierige Teil beginnt, wenn Sie es teilen wollen. Ein Team-Vault erfordert Konventionen: wer was, wann und in welchem Format committet. Es erfordert jemanden, der die Struktur pflegt, genau wie es heute jemand die Jira-Board-Konfiguration pflegt. Der Unterschied ist, dass eine Textdatei-Konvention günstiger zu ändern ist als ein Jira-Workflow-Schema und ihre Versionshistorie ihre Entwicklung sichtbar macht.

Auf Organisationsebene werden die Fragen schwieriger:

• Welche Agenten-Konfigurationen sind freigegeben?
• Welche Version der Analyse-Vorlage ist der Standard?
• Wie vergleicht man Ergebnisse über Teams hinweg?

Es gibt kein allgemein akzeptiertes Betriebsmodell für die Governance von Agenten-Konfigurationen, Skill-Sets, Prompt-Bibliotheken oder portablem Projektwissen im großen Maßstab. Einige Organisationen bauen Governance- und Freigabe-Kontrollen rund um KI-Systeme auf, und Atlassian selbst bewegt sich mit rollenbasierten Berechtigungen für Agenten in diese Richtung. Aber es gibt kein etabliertes Playbook.

(Organisationen kennen dieses Muster: Wenn das offizielle Tooling zu langsam oder zu starr ist, bauen Teams Workarounds. Die Lösung ist nicht, Workarounds zu verbieten. Sie besteht darin, den offiziellen Weg einfacher zu machen als die Alternative.)

Der Rollenwechsel

Mein Argument zielt nicht darauf ab, Jira herauszureißen. Das wäre so disruptiv wie unnötig. Jira kann liefern, wofür es entworfen wurde: den Status von Arbeitselementen über Workflows hinweg zu verfolgen. (Jira ist ziemlich gut darin, wenn man auf übermäßige Anpassungen und den Aufbau eines ausgefeilten Rollen- und Berechtigungssystems verzichtet.)

Was sich ändert, ist Jiras Rolle in der Projektinformationsarchitektur. Mein Argument lautet: Man degradiert es von der Wissensautorität zur Ausführungsoberfläche. Das autoritative Projektwissen, die Art, die Agenten brauchen, um über Veränderung im Zeitverlauf nachzudenken, wird zunehmend in einem strukturierten, versionierten, portablen Format leben. Jira kann in dieses Repository einspeisen. Es kann daraus auch lesen. Aber es ist nicht mehr das System of Record für Projektwissen, weil es nie dafür konzipiert wurde.

Das gilt über Jira hinaus. Jedes Tool, dessen primärer Wert darin besteht, Daten in einem Dashboard für Menschen anzuzeigen, steht unter demselben Druck. Ein wachsender Anteil des Projektdatenkonsums wird sich von Menschen, die Boards scannen, zu Agenten verlagern, die strukturierten Kontext lesen. Diese Verlagerung ist noch nicht abgeschlossen und wird noch Jahre dauern. Aber dort, wo sie geschieht, werden die Tools bzw. Konzepte, die als Kontextlieferanten dienen können, wertvoller, und die Tools, die es nicht können, werden optional.

Probieren Sie dies, bevor Sie sich für den Wechsel von Jira zu KI-Agenten entscheiden

Nehmen Sie die Ergebnisse Ihrer letzten drei Sprint-Retrospektiven. Wenn sie auf Post-Its stehen, tippen Sie sie ab. (Natürlich kann das auch Ihr LLM für Sie erledigen.) Wenn sie in Confluence stehen, kopieren Sie den Text. Legen Sie jedes in eine separate Markdown-Datei: retro-sprint-22.md, retro-sprint-23.md, retro-sprint-24.md.

Geben Sie alle drei Dateien einem KI-Agenten (Claude, ChatGPT, was auch immer Sie nutzen) und fragen Sie: „Welche Muster erkennst du über diese drei Retrospectives hinweg?“ Was wurde identifiziert, aber nie gelöst? Was wird schlimmer?“

Vergleichen Sie die Antwort mit dem, was Ihnen Ihre Jira-Dashboards oder Confluence-Seiten über denselben Zeitraum verraten haben.

Dieser Vergleich wird Ihnen mehr über den Wert von strukturiertem, agentenlesbarem Projektwissen sagen als dieser Artikel. Es dauert fünfzehn Minuten. Die einzigen Kosten sind die Ehrlichkeit, die es braucht, um sich das Ergebnis anzusehen.

Fazit

Ticket-Systeme werden nicht verschwinden. Aber ihre Rolle verändert sich. Die Organisationen, die Projektwissen von der Projektverfolgung trennen, werden ihren KI-Agenten einen besseren Kontext geben, und dieser bessere Kontext akkumuliert über Zeit exponentiell.

Fangen Sie mit einem Ordner, drei Retrospektivedateien und einem fünfzehnminütigen Experiment an. Wenn der Agent etwas findet, das Ihr Dashboard übersehen hat, haben Sie Ihre Antwort. Der Rest ist Konvention und Disziplin.

📖 Von Jira zu KI-Agenten — Weitere Lektüre

Drei Claude Skills für Ihr Urteilsvermögen

Warum Agile Praktiker für 2026 optimistisch sein sollten (Teil 1): Sie haben dies bereits früher überstanden

KI für agile Praktiker: Warum Sie für 2026 optimistisch sein sollten (Teil 2)

Das A3-Rahmenwerk: Ein Entscheidungssystem für KI-Delegation

👆 Stefan Wolpers: The Scrum Anti-Patterns Guide (Amazon advertisement.)

📅 Professional Scrum-Schulungen nach Scrum.org, Workshops und Events

Sie können sich Ihren Platz für KI- und Scrum-Schulungen, Workshops und Meetups direkt sichern, indem Sie dem entsprechenden Link in der Tabelle unten folgen:

Alle kommenden Professional-Scrum-Klassen finden Sie hier.

Sie können Ihren Platz für die Schulung direkt buchen, indem Sie dem entsprechenden Link zum Ticketshop folgen. Sollte der Beschaffungsprozess Ihrer Organisation einen anderen Einkaufsprozess erfordern, wenden Sie sich bitte direkt an die Berlin Product People GmbH.

✋ Nicht versäumen: Einen Erfahrungsaustausch über das Thema von Jira zu KI-Agenten gibt es im 20.000-köpfigen „Hands-on Agile“ Slack-Team

Ich lade Sie ein, sich dem „Hands-on Agile“ Slack-Team anzuschließen und die Vorteile einer schnell wachsenden, lebendigen Gemeinschaft agiler Praktikern aus der ganzen Welt zu genießen.

Wenn Sie jetzt beitreten möchten, müssen Sie nur noch Ihre Anmeldeinformationen über dieses Google-Formular angeben, und ich werde Sie anmelden. Die Mitgliedschaft ist kostenlos.

Reflektieren Sie über den Weg von Jira zu KI-Agenten, indem Sie den kostenlosen Scrum Anti-Patterns Guide lesen: