[{"data":1,"prerenderedAt":20},["ShallowReactive",2],{"blog-post-de-ki-agent-jira-sprintplanung":3},{"slug":4,"lang":5,"title":6,"description":7,"heading":6,"translationKey":8,"date":9,"keywords":10,"readingMinutes":16,"html":17,"alternates":18},"ki-agent-jira-sprintplanung","de","KI-Agent für die Jira-Sprintplanung: Zugriff mit Grenzen","Wie ein KI-Agent das Jira-Backlog pflegt und Sprints vorbereitet, welche Berechtigungen er wirklich braucht und wie man ihn auf ein Projekt begrenzt.","jira-sprint-planning","2026-07-24",[11,12,13,14,15],"KI-Agent Jira Sprintplanung","Jira MCP","Backlog-Pflege mit KI","Jira KI-Agent Berechtigungen","Jira MCP Server Sicherheit",6,"\u003Cp>Die Sprintplanung ist einer der ersten Bereiche, in denen Teams KI-Agenten im Entwicklungsprozess ausprobieren. Die Arbeit wiederholt sich, sie besteht zum großen Teil aus Text, und fast alle Informationen, die der Agent braucht, liegen bereits in Jira: offene Issues, Schätzungen, Abhängigkeiten und der Stand des letzten Sprints. Ein Agent, der über das Model Context Protocol (MCP) mit Jira verbunden ist, kann das Backlog lesen, einen Sprint-Umfang vorschlagen, Issues in den Sprint verschieben und sie priorisieren. Das spart Zeit. Es bedeutet aber auch, dass ein Sprachmodell Schreibzugriff auf das System hat, in dem festgelegt ist, was das Team als Nächstes baut.\u003C\u002Fp>\n\u003Cp>Dieser Beitrag beschreibt, was ein Agent für die Sprintplanung konkret tut, welche Berechtigungen er dafür benötigt und wie sich diese Berechtigungen so einschränken lassen, dass der Agent nützlich bleibt, ohne mehr verändern zu können, als seine Aufgabe erfordert. Er gehört zu unserer Reihe über \u003Ca href=\"\u002Fde\u002Fblog\u002Fki-agenten-softwareentwicklung\">KI-Agenten in der Softwareentwicklung\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Was ein Planungsagent in der Praxis macht\u003C\u002Fh2>\n\u003Cp>In einem typischen Setup übernimmt der Agent drei Arten von Aufgaben. Die erste ist die Backlog-Pflege: neue Issues lesen, prüfen, ob Issue-Typ, übergeordnetes Epic und eine verständliche Beschreibung vorhanden sind, und fehlende Angaben per Kommentar nachfragen. Die zweite ist die Vorbereitung des Sprints: die Kapazität des nächsten Sprints betrachten, Issues aus dem priorisierten Backlog auswählen und einen Umfang vorschlagen. Die dritte ist die eigentliche Änderung: die ausgewählten Issues in den Sprint verschieben, die Reihenfolge anpassen und in manchen Teams den Sprint nach dem Planungsmeeting starten.\u003C\u002Fp>\n\u003Cp>Nur die erste Aufgabe besteht überwiegend aus Lesezugriffen. Die zweite und dritte sind Schreibvorgänge, und einige davon lassen sich nicht sauber rückgängig machen. Wenn fünfzig Issues im falschen Sprint landen oder ein Sprint zu früh abgeschlossen wird, gehen zwar keine Daten verloren, aber das Board muss von Hand repariert werden, und der Sprint-Bericht ist nachträglich verfälscht.\u003C\u002Fp>\n\u003Cfigure class=\"post-figure\">\n\u003Csvg viewBox=\"0 0 760 280\" xmlns=\"http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg\" role=\"img\" aria-labelledby=\"jirasp-stages-title\">\n  \u003Ctitle id=\"jirasp-stages-title\">Ein Planungsagent erledigt drei Arten von Aufgaben; nur die Backlog-Pflege besteht überwiegend aus Lesen.\u003C\u002Ftitle>\n  \u003Cpath class=\"fig-flow\" d=\"M216 109 H280\"\u002F>\n  \u003Cpath class=\"fig-flow\" d=\"M480 109 H544\"\u002F>\n  \u003Cpath class=\"fig-head\" d=\"M280 109 l-8 -5 v10 z\"\u002F>\n  \u003Cpath class=\"fig-head\" d=\"M544 109 l-8 -5 v10 z\"\u002F>\n  \u003Crect class=\"fig-box\" x=\"16\" y=\"24\" width=\"200\" height=\"170\" rx=\"12\"\u002F>\n  \u003Ctext class=\"fig-h fig-c-primary\" x=\"32\" y=\"50\">01\u003C\u002Ftext>\n  \u003Ctext class=\"fig-t\" x=\"32\" y=\"74\">Backlog pflegen\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"32\" y=\"102\">search_issues\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"32\" y=\"120\">read_issue\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"32\" y=\"138\">add_comment\u003C\u002Ftext>\n  \u003Ctext class=\"fig-h fig-c-ok\" x=\"32\" y=\"176\">ÜBERWIEGEND LESEN\u003C\u002Ftext>\n  \u003Crect class=\"fig-box\" x=\"280\" y=\"24\" width=\"200\" height=\"170\" rx=\"12\"\u002F>\n  \u003Ctext class=\"fig-h fig-c-primary\" x=\"296\" y=\"50\">02\u003C\u002Ftext>\n  \u003Ctext class=\"fig-t\" x=\"296\" y=\"74\">Sprint vorbereiten\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"296\" y=\"102\">read_board_configuration\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"296\" y=\"120\">list_sprints\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"296\" y=\"138\">create_sprint\u003C\u002Ftext>\n  \u003Ctext class=\"fig-h fig-c-deny\" x=\"296\" y=\"176\">SCHREIBT\u003C\u002Ftext>\n  \u003Crect class=\"fig-box\" x=\"544\" y=\"24\" width=\"200\" height=\"170\" rx=\"12\"\u002F>\n  \u003Ctext class=\"fig-h fig-c-primary\" x=\"560\" y=\"50\">03\u003C\u002Ftext>\n  \u003Ctext class=\"fig-t\" x=\"560\" y=\"74\">Änderungen umsetzen\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"560\" y=\"102\">move_issue_to_sprint\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"560\" y=\"120\">rank_issues\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"560\" y=\"138\">update_sprint\u003C\u002Ftext>\n  \u003Ctext class=\"fig-h fig-c-deny\" x=\"560\" y=\"176\">SCHREIBT\u003C\u002Ftext>\n  \u003Cpath class=\"fig-edge\" d=\"M644 194 V214\"\u002F>\n  \u003Crect class=\"fig-box fig-box--muted fig-box--dashed\" x=\"504\" y=\"214\" width=\"240\" height=\"52\" rx=\"10\"\u002F>\n  \u003Ctext class=\"fig-s\" x=\"624\" y=\"236\" text-anchor=\"middle\">optional: Freigabe für\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"624\" y=\"254\" text-anchor=\"middle\">update_sprint, vom Admin gesetzt\u003C\u002Ftext>\n\u003C\u002Fsvg>\n\u003Cfigcaption>Die drei Aufgaben eines Planungsagenten und die Jira-Operationen dahinter. Nur die Backlog-Pflege besteht überwiegend aus Lesezugriffen; für update_sprint, das einen Sprint startet und abschließt, kann ein Admin eine Freigabe verlangen.\u003C\u002Ffigcaption>\n\u003C\u002Ffigure>\n\n\u003Ch2>Warum ein Jira-API-Token zu viel Zugriff gibt\u003C\u002Fh2>\n\u003Cp>Der einfachste Weg, einen Agenten mit Jira zu verbinden, ist ein persönliches API-Token. Das Problem dabei: Ein Token hat genau die Rechte der Person, die es erstellt hat. Ist diese Person Projektadministrator in zehn Jira-Projekten, ist der Agent faktisch ebenfalls Administrator in zehn Projekten. Er kann Issues löschen, Projekte anlegen und alles durchsuchen, was diese Person sehen darf, auch Projekte, die mit dem Sprint nichts zu tun haben.\u003C\u002Fp>\n\u003Cp>Außerdem unterscheidet ein Token nicht zwischen Lesen und Ändern auf feiner Ebene. Eine Regel wie „dieser Agent darf Issues in Board 42 priorisieren, aber nicht löschen“ lässt sich damit nicht abbilden. Hinzu kommt, dass Jira die Änderung unter dem Konto der Person protokolliert. Im Nachhinein ist daher kaum festzustellen, ob eine Änderung von der Person selbst oder vom Agenten in ihrem Namen stammt.\u003C\u002Fp>\n\u003Ch2>Welche Berechtigungen ein Sprint-Agent wirklich braucht\u003C\u002Fh2>\n\u003Cp>Wenn die Aufgabe genau beschrieben ist, wird die Liste der nötigen Operationen kurz. Für die Sprintplanung eines Teams braucht der Agent in der Regel:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Lesezugriff auf Issues, Suche, Boards, Sprints und die Board-Konfiguration.\u003C\u002Fli>\n\u003Cli>Verschieben von Issues ins Backlog, auf ein Board oder in einen Sprint.\u003C\u002Fli>\n\u003Cli>Priorisieren (Ranking) von Issues.\u003C\u002Fli>\n\u003Cli>Anlegen und Aktualisieren von Sprints (über die Aktualisierung wird ein Sprint auch gestartet und abgeschlossen).\u003C\u002Fli>\n\u003Cli>Kommentare anlegen, falls der Agent seine Vorschläge im Issue begründen soll.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Er muss keine Issues oder Sprints löschen, keine Projekte anlegen oder entfernen und keine Anhänge löschen. Er braucht auch keinen Zugriff auf andere Projekte als das, für das er plant. Das ist das Prinzip der minimalen Rechte (Least Privilege), angewendet auf einen Agenten: Er erhält die Operationen und Ressourcen, die seine Aufgabe erfordert, und keine weiteren.\u003C\u002Fp>\n\u003Ch2>Wie Vordix einen Jira-Agenten begrenzt\u003C\u002Fh2>\n\u003Cp>Vordix ist ein selbst gehostetes Gateway, das zwischen dem Agenten und Jira sitzt. Der Agent verbindet sich mit einem Vordix-Workspace statt direkt mit Jira, und jeder Aufruf durchläuft dieselben Prüfungen, bevor er Jira erreicht. Für einen Planungsagenten sind vor allem die folgenden Kontrollen relevant.\u003C\u002Fp>\n\u003Cfigure class=\"post-figure\">\n\u003Csvg viewBox=\"0 0 760 340\" xmlns=\"http:\u002F\u002Fwww.w3.org\u002F2000\u002Fsvg\" role=\"img\" aria-labelledby=\"jirasp-calls-title\">\n  \u003Ctitle id=\"jirasp-calls-title\">Fünf Aufrufe eines Sprint-Agenten: Drei erfüllen die Richtlinie, zwei werden mit Begründung abgelehnt, alle fünf werden protokolliert.\u003C\u002Ftitle>\n  \u003Crect class=\"fig-box fig-box--ai\" x=\"16\" y=\"128\" width=\"112\" height=\"64\" rx=\"10\"\u002F>\n  \u003Ctext class=\"fig-t fig-c-ai\" x=\"72\" y=\"156\" text-anchor=\"middle\">Sprint-Agent\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"72\" y=\"175\" text-anchor=\"middle\">Workspace MOB\u003C\u002Ftext>\n  \u003Cpath class=\"fig-edge fig-edge--faint\" d=\"M128 160 C140 160 138 52 150 52\"\u002F>\n  \u003Crect class=\"fig-box\" x=\"150\" y=\"32\" width=\"236\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t\" x=\"162\" y=\"49\">search_issues\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"162\" y=\"65\">Status = To Do\u003C\u002Ftext>\n  \u003Cpath class=\"fig-flow fig-flow--ok\" d=\"M386 52 H520\"\u002F>\n  \u003Crect class=\"fig-box fig-box--ok\" x=\"520\" y=\"32\" width=\"224\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t fig-c-ok\" x=\"532\" y=\"49\">✓ erlaubt\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"532\" y=\"65\">an Jira weitergeleitet\u003C\u002Ftext>\n  \u003Cpath class=\"fig-edge fig-edge--faint\" d=\"M128 160 C140 160 138 100 150 100\"\u002F>\n  \u003Crect class=\"fig-box\" x=\"150\" y=\"80\" width=\"236\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t\" x=\"162\" y=\"97\">move_issue_to_sprint\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"162\" y=\"113\">Board 42 · 12 Issues\u003C\u002Ftext>\n  \u003Cpath class=\"fig-flow fig-flow--ok\" d=\"M386 100 H520\"\u002F>\n  \u003Crect class=\"fig-box fig-box--ok\" x=\"520\" y=\"80\" width=\"224\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t fig-c-ok\" x=\"532\" y=\"97\">✓ erlaubt\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"532\" y=\"113\">an Jira weitergeleitet\u003C\u002Ftext>\n  \u003Cpath class=\"fig-edge fig-edge--faint\" d=\"M128 160 C140 160 138 148 150 148\"\u002F>\n  \u003Crect class=\"fig-box\" x=\"150\" y=\"128\" width=\"236\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t\" x=\"162\" y=\"145\">rank_issues\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"162\" y=\"161\">MOB-311\u003C\u002Ftext>\n  \u003Cpath class=\"fig-flow fig-flow--ok\" d=\"M386 148 H520\"\u002F>\n  \u003Crect class=\"fig-box fig-box--ok\" x=\"520\" y=\"128\" width=\"224\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t fig-c-ok\" x=\"532\" y=\"145\">✓ erlaubt\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"532\" y=\"161\">an Jira weitergeleitet\u003C\u002Ftext>\n  \u003Cpath class=\"fig-edge fig-edge--faint\" d=\"M128 160 C140 160 138 196 150 196\"\u002F>\n  \u003Crect class=\"fig-box\" x=\"150\" y=\"176\" width=\"236\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t\" x=\"162\" y=\"193\">move_issue_to_sprint\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"162\" y=\"209\">Board 77 · Projekt HR\u003C\u002Ftext>\n  \u003Cpath class=\"fig-flow fig-flow--deny\" d=\"M386 196 H410\"\u002F>\n  \u003Crect class=\"fig-box fig-box--deny\" x=\"520\" y=\"176\" width=\"224\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t fig-c-deny\" x=\"532\" y=\"193\">× abgelehnt\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"532\" y=\"209\">Board 77 nicht in MOB\u003C\u002Ftext>\n  \u003Cpath class=\"fig-edge fig-edge--faint\" d=\"M128 160 C140 160 138 244 150 244\"\u002F>\n  \u003Crect class=\"fig-box\" x=\"150\" y=\"224\" width=\"236\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t\" x=\"162\" y=\"241\">delete_issue\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"162\" y=\"257\">MOB-204\u003C\u002Ftext>\n  \u003Cpath class=\"fig-flow fig-flow--deny\" d=\"M386 244 H410\"\u002F>\n  \u003Crect class=\"fig-box fig-box--deny\" x=\"520\" y=\"224\" width=\"224\" height=\"40\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-t fig-c-deny\" x=\"532\" y=\"241\">× abgelehnt\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"532\" y=\"257\">Operation nicht freigeschaltet\u003C\u002Ftext>\n  \u003Crect class=\"fig-box fig-box--primary\" x=\"410\" y=\"24\" width=\"86\" height=\"248\" rx=\"12\"\u002F>\n  \u003Ctext class=\"fig-t fig-c-primary\" x=\"453\" y=\"144\" text-anchor=\"middle\">Vordix\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"453\" y=\"162\" text-anchor=\"middle\">Richtlinie\u003C\u002Ftext>\n  \u003Cpath class=\"fig-edge\" d=\"M453 272 V292\"\u002F>\n  \u003Crect class=\"fig-box fig-box--muted\" x=\"150\" y=\"292\" width=\"594\" height=\"36\" rx=\"8\"\u002F>\n  \u003Ctext class=\"fig-h\" x=\"166\" y=\"315\">AUDIT-LOG\u003C\u002Ftext>\n  \u003Ctext class=\"fig-s\" x=\"262\" y=\"315\">5 Einträge: 3 erlaubt, 2 abgelehnt, jeweils mit Begründung\u003C\u002Ftext>\n\u003C\u002Fsvg>\n\u003Cfigcaption>Fünf Aufrufe eines Sprint-Agenten laufen durch Vordix. Drei bleiben im Projekt MOB und erreichen Jira; ein Board aus einem anderen Projekt und eine nicht freigeschaltete Operation werden abgelehnt, und jeder Aufruf landet im Audit-Log.\u003C\u002Ffigcaption>\n\u003C\u002Ffigure>\n\n\u003Cp>\u003Cstrong>Operationen werden einzeln freigeschaltet.\u003C\u002Fstrong> Jede Jira-Operation ist zunächst deaktiviert. Ein Admin schaltet frei, was die Organisation grundsätzlich erlaubt, die Projektleitung aktiviert, was das Projekt braucht, und der Workspace des Agenten erhält nur die Operationen für seine Aufgabe. Ist \u003Ccode>delete_issue\u003C\u002Fcode> nicht freigeschaltet, taucht das Tool in der Tool-Liste des Agenten gar nicht erst auf.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Ressourcen werden über Werte eingegrenzt.\u003C\u002Fstrong> Die Jira-Integration ist über den Projektschlüssel abgegrenzt. Darunter können Allowlists den Issue-Typ, das übergeordnete Epic, einzelne Issue-Keys, das Board und den Sprint einschränken. Ein Planungsagent lässt sich so auf das Projekt \u003Ccode>MOB\u003C\u002Fcode>, Board 42 und die Sprints dieses Boards begrenzen.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Die Zugehörigkeit von Board und Sprint wird geprüft.\u003C\u002Fstrong> Board- und Sprint-IDs sind Zahlen, und ein Agent könnte die ID eines Boards übergeben, das zu einem anderen Projekt gehört. Vor jedem Agile-Aufruf prüft Vordix deshalb, ob Board oder Sprint tatsächlich zum freigegebenen Projekt gehören. Eine fremde ID wird abgelehnt, auch wenn Jira die Zahl selbst akzeptieren würde.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Die Suche nutzt strukturierte Filter statt JQL.\u003C\u002Fstrong> Der Agent sucht mit Filtern wie Status oder Issue-Typ. Vordix erzeugt die Abfrage in der Jira Query Language (JQL) selbst und setzt die Projektbedingung immer fest. Eine Suche lässt sich daher nicht durch geschickt formulierte Abfragen auf andere Projekte ausweiten.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Massenverschiebungen sind begrenzt.\u003C\u002Fstrong> Pro Aufruf lassen sich höchstens 50 Issues aus einem Projekt in einen Sprint oder ins Backlog verschieben. Ein Fehler betrifft damit immer nur eine überschaubare Menge.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Personenbezogene Daten lassen sich maskieren.\u003C\u002Fstrong> Felder wie die E-Mail-Adresse von Bearbeiter oder Melder können maskiert oder entfernt werden, bevor die Antwort das Modell erreicht. Der Agent sieht weiterhin, welche Issues zugewiesen sind, aber nicht die persönlichen Daten dahinter.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Kritische Schritte können eine Freigabe erfordern.\u003C\u002Fstrong> Ein Admin kann eine Freigaberegel an eine einzelne Operation binden, zum Beispiel an die Aktualisierung eines Sprints, über die ein Sprint gestartet oder abgeschlossen wird. Der Aufruf wird dann angehalten, bis jemand ihn bestätigt. Standardmäßig ist das nicht aktiv; jede Organisation entscheidet selbst, welche Operationen sie so absichern will.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Jeder Aufruf wird protokolliert.\u003C\u002Fstrong> Jede Anfrage, auch jede abgelehnte, landet mit Workspace, Operation, Parametern und Entscheidung in einem unveränderlichen Audit-Log. Damit lässt sich später beantworten, welche Änderungen der Agent vorgenommen hat und welche er versucht hat, ohne sie zu dürfen. Mehr dazu steht im Beitrag über \u003Ca href=\"\u002Fde\u002Fblog\u002Faudit-log-ki-agenten-eu-ai-act\">Audit-Logs für KI-Agenten\u003C\u002Fa>.\u003C\u002Fp>\n\u003Cp>Die Grundidee einer kontrollierten Ebene zwischen Agenten und Tools erklärt der Beitrag \u003Ca href=\"\u002Fde\u002Fblog\u002Fwas-ist-ein-mcp-gateway\">Was ist ein MCP Gateway?\u003C\u002Fa>.\u003C\u002Fp>\n\u003Ch2>Kompromisse und Grenzen\u003C\u002Fh2>\n\u003Cp>Ein kontrolliertes Setup hat seinen Preis, und der sollte vor der Einführung klar sein.\u003C\u002Fp>\n\u003Cp>Die strukturierte Suche ist sicherer als freies JQL, aber auch weniger ausdrucksstark. Manche komplexen Abfragen, die erfahrene Jira-Nutzer von Hand schreiben, lassen sich mit den verfügbaren Filtern nicht abbilden. Für die Planung reicht das in der Regel aus. Ein Agent, der beliebige Auswertungsfragen beantworten soll, stößt jedoch schneller an Grenzen.\u003C\u002Fp>\n\u003Cp>Die Begrenzung auf 50 Issues führt dazu, dass eine große Umplanung, etwa nach einer Quartalsplanung, mehrere Aufrufe braucht. Das ist gewollt, weil jeder Schritt klein und nachvollziehbar bleibt, macht den Vorgang aber langsamer.\u003C\u002Fp>\n\u003Cp>Freigaben kosten Zeit. Muss der Start eines Sprints bestätigt werden, kann der Agent die Planung nicht allein abschließen, und es muss jemand erreichbar sein. Viele Teams starten deshalb ohne Freigaben und führen sie nur für Operationen ein, die tatsächlich Probleme verursacht haben.\u003C\u002Fp>\n\u003Cp>Schließlich kontrolliert das Gateway, was der Agent tun darf, aber nicht, ob seine Vorschläge gut sind. Auch ein sauber begrenzter Agent kann einen Sprint vorschlagen, der eine Abhängigkeit übersieht oder eine Person überlastet. Die Qualität der Planung hängt weiterhin von der Qualität der Daten im Backlog ab und davon, dass ein Mensch den Vorschlag prüft.\u003C\u002Fp>\n\u003Ch2>Fazit\u003C\u002Fh2>\n\u003Cp>KI-Agenten können einen großen Teil der Routinearbeit rund um die Sprintplanung in Jira übernehmen. Ein persönliches API-Token gibt ihnen dafür aber deutlich mehr Zugriff als nötig. Ein besseres Setup begrenzt den Agenten auf die Operationen und das Projekt, die er braucht, prüft die Zugehörigkeit von Boards und Sprints und protokolliert jeden Aufruf. Damit verschiebt sich die Frage von „Darf ein Agent überhaupt in Jira arbeiten?“ zu „Welche konkreten Aktionen soll er übernehmen, und welche bleiben beim Team?“\u003C\u002Fp>\n\u003Cp>Wie ein solcher Workspace eingerichtet wird, beschreibt die Vordix-Dokumentation zur Jira-Integration; in einer Demo zeigen wir es an einem echten Board.\u003C\u002Fp>\n",{"de":4,"en":19},"ai-agent-jira-sprint-planning",1790588073399]