Wir haben Jira abgeschafft: KI-Agenten und eine tasks.md, die sich selbst füllt

Das letzte Ticket, das wir in unserem Jira für ein eigenes Projekt angelegt haben, stammt aus dem Februar. Niemand hat in einem Meeting beschlossen, es nicht mehr zu nutzen. Es ist von selbst passiert: Wer ein Ticket schrieb, schrieb am Ende dasselbe noch einmal in den Prompt des Agenten, und das Ticket las danach niemand mehr. Nach ein paar Wochen ließen die Leute die erste Fassung einfach weg.

Heute steht die Arbeit jedes Projekts in einer Textdatei, tasks.md, die im Projekt selbst liegt und die die Agenten während der Arbeit befüllen. Für uns funktioniert das in fast allem besser als Jira. In einer Sache funktioniert es schlechter, und die tut uns am meisten weh: zu wissen, woran jeder gerade arbeitet.

Dieser Text hat eine Meinung. Ich glaube, Jira und fast jeder Ticket-Tracker sind dafür gebaut, Entwicklerstunden zu verteilen, und die waren zwanzig Jahre lang das Teuerste an einem Projekt. Mit Agenten kostet das Schreiben des Codes Minuten oder Stunden. Teuer ist jetzt, zu wissen, was man will, und zu prüfen, ob das Ergebnis stimmt. Bei beidem hilft ein Ticket-Board nicht.

Es ist auch ein unfertiger Text. Wir arbeiten seit acht Monaten mit diesem System, haben es viermal umgebaut und werden es weiter umbauen. Ich erzähle, was gut lief, was schlecht lief und was wir noch nicht lösen können.

Eine Warnung vorweg: Wir sind eine Agentur, und ein Teil dessen, was wir verkaufen, sind Entwicklungsstunden. Wenn Schätzen in Stunden keinen Sinn mehr ergibt, trifft das uns vor allen anderen.

Wofür Jira da war

Nehmen Sie Jira die Integrationen, die Farben und die benutzerdefinierten Felder weg, dann bleiben vier Funktionen:

1. Eine Warteschlange: was zu tun ist und in welcher Reihenfolge.
2. Eine Verteilung: wer was macht.
3. Eine Schätzung: was es kosten wird, in Stunden oder Punkten, damit man weiß, was in einen Sprint passt.
4. Ein Status: wo jede Sache steht, damit es auch weiß, wer gerade nicht programmiert, ohne nachzufragen.

Alle vier drehen sich um dieselbe knappe Ressource: die Zeit eines Menschen, der programmieren kann. Den Sprint gibt es, weil diese Zeit alle zwei Wochen aufgebraucht ist. Die Punkte gibt es, weil man sie verteilen muss, bevor man sie ausgibt. Die Spalten “In Arbeit” und “Im Review” gibt es, weil eine Aufgabe in jeder davon Tage verbringen konnte.

Jahrelang haben wir so gearbeitet, und es hat funktioniert. Wir hatten montags Refinements, alle zwei Wochen ein Planning, eine Retro, die manchmal ausfiel, und ein Board pro Projekt. Über das Board sahen Kunde, Projektleitung und Team dasselbe.

Was sich mit den Agenten geändert hat

Als Erstes fiel uns auf, dass die Schätzungen nicht mehr aufgingen, und zwar nicht, weil sie schlecht waren. Eine Drei-Punkte-Aufgabe, früher anderthalb Tage Arbeit, war an einem Nachmittag erledigt. Eine Fünfer an einem Tag. Die Achter kosteten weiterhin gleich viel oder mehr, denn dort war das Schwierige nie das Tippen. Schwierig war, zu verstehen, was zu tun war.

Rund zwei Monate lang versuchten wir, die Punkte neu zu kalibrieren. Es klappte nicht. Wie lange eine Aufgabe dauerte, hing nicht mehr von ihrer Größe ab, sondern davon, wie gut sie erklärt war. Eine große, aber klare Aufgabe war an einem Vormittag fertig. Eine kleine, aber mehrdeutige konnte zwei Tage Hin und Her fressen, weil der Agent sehr selbstsicher etwas baute, das wir nicht wollten, wir es noch einmal erklären mussten und er wieder etwas anderes baute.

Da verstanden wir, dass sich der Engpass verschoben hatte. Früher blieb die Arbeit bei “Wer hat Zeit dafür?” hängen. Heute bleibt sie an zwei Stellen hängen:

• Vor dem Start: gut aufschreiben, was man will. Nicht in einem Zweizeiler-Ticket, sondern mit Kontext, Einschränkungen, dem, was nicht angefasst werden darf, und woran man erkennt, dass es stimmt.
• Am Ende: prüfen, was der Agent gemacht hat. Die Änderung lesen, sie testen, verstehen, ob etwas kaputtgegangen ist, das man nicht sieht.

Jira hat für keins von beiden eine Spalte. Es hat “Zu erledigen”, “In Arbeit” und “Erledigt”, und der größte Teil des Aufwands steckt nicht mehr in “In Arbeit”.

Außerdem änderte sich, wie lange eine Aufgabe in jedem Status verbrachte. Steht eine Aufgabe vierzig Minuten auf “In Arbeit”, kostet das Verschieben auf dem Board fast so viel wie die Aufgabe selbst. Die Leute hörten auf, sie zu verschieben. Das Board fing an zu lügen. Und ein Board, das lügt, ist schlimmer als gar keins, weil jemand draufschaut und es glaubt.

Die tasks.md

Die Alternative entstand in einem kleinen Projekt, fast aus Versehen. Ein Entwickler im Team legte dem Agenten eine Liste offener Punkte in eine Textdatei im Stammverzeichnis des Projekts, damit er ihm nicht jeden Morgen den Kontext erklären musste. Nach einer Woche pflegte der Agent diese Liste selbst: Er hakte ab, was er fertig hatte, ergänzte, worüber er unterwegs stolperte, und notierte, warum er etwas halb fertig liegen ließ.

Wir haben das in die übrigen Projekte übernommen. Heute hat jedes eine, und sie sieht ungefähr so aus:

# Aufgaben

## In Arbeit
- [ ] Export von Bestellungen als CSV mit Filter nach Filiale (Laura, seit 14. Okt.)
  - Fehlt noch: mit mehr als 10.000 Zeilen testen
- [ ] Umstellung des Zahlungsanbieters auf die neue API (Dani, seit 15. Okt.)

## Offen
- [ ] Die Suche ignoriert Umlaute ("Mobel" findet "Möbel" nicht)
- [ ] Rechtstexte der Checkout-Seite prüfen (wartet auf Antwort des Kunden)

## Erledigt
- [x] Login per Magic Link per E-Mail (Laura, 13. Okt.)
  - Login mit Passwort auf dem Smartphone auf Wunsch des Kunden entfernt
- [x] Berechnung der Mehrwertsteuer bei Teilrücksendungen korrigiert (Dani, 11. Okt.)

Die Regeln sind wenige:

• Der Agent liest sie zu Beginn jeder Sitzung. So weiß er, was offen ist, wer woran arbeitet und was vorher entschieden wurde, ohne dass es ihm jemand erzählt.
• Der Agent aktualisiert sie am Ende. Er verschiebt, was er erledigt hat, nach “Erledigt”, mit einer Zeile dazu, was sich geändert hat, und wenn nötig, warum. Ist er auf etwas Kaputtes gestoßen, das nicht seine Aufgabe war, trägt er es unter “Offen” ein.
• Menschen lesen und korrigieren sie. Ändert sich eine Priorität, wird die Zeile von Hand verschoben. Niemand muss “Karten schieben”, damit der Status aktuell ist, denn den Status schreibt, wer die Arbeit macht.
• Alles, was nicht in eine Zeile passt, gehört woandershin. Designentscheidungen und Projektregeln stehen in einer eigenen Datei, die der Agent ebenfalls liest. Die tasks.md ist nur die Liste.

Gegenüber Jira gewinnt sie in drei Punkten. Sie liegt beim Code, wird also mit ihm gespeichert, versioniert und wiederhergestellt. Der Agent liest sie ohne Integrationen, ohne Berechtigungen und ohne Konnektoren, weil sie Text ist. Und ein Mensch liest sie in dreißig Sekunden komplett, was man von einem Board mit hundertzwanzig Karten nicht behaupten kann.

In anderen Punkten verliert sie, und die erzähle ich weiter unten.

Was gut lief

Die Änderung aus dem Meeting

Im Frühjahr hatten wir ein Status-Meeting mit einem Kunden aus dem Handel. Mitten im Meeting sagte der Betriebsleiter, der Bestellbericht, den wir geliefert hatten, sei brauchbar, aber eigentlich bräuchten sie ihn nach Filialen aufgeschlüsselt und zum Herunterladen, um ihn an die jeweilige Filialleitung weiterzugeben.

Mit unserem alten Prozess wäre das ein Ticket geworden, ein Refinement am folgenden Montag, eine Schätzung und, mit Glück, ein Platz im Sprint der Woche danach. Zwei Wochen, optimistisch gerechnet.

Die Entwicklerin, die im Meeting saß, trug es während des Gesprächs in die tasks.md ein, mit den Worten des Kunden. Danach öffnete sie eine Sitzung mit dem Agenten. Um fünf Uhr nachmittags schickten wir ihm einen Link zur Testumgebung mit dem Filialfilter und dem Download. Die Antwort des Betriebsleiters war eine WhatsApp-Sprachnachricht, die wir uns ab und zu immer noch anhören.

Der Agent hat seinen Teil beigetragen. Gespart wurden die zwei Wochen aber, weil zwischen Anfrage und Code nichts mehr lag: kein Ticket, keine Warteschlange, kein Planning. Nötig war nur, genau zu verstehen, was der Kunde wollte, und das wussten wir schon, weil wir im Meeting gesessen hatten.

Das MVP, das früher fertig war

Für ein Startup hatten wir ein erstes Produkt in sechs Wochen geplant: Registrierung, ein Dashboard mit drei Ansichten, Zahlungen und Benachrichtigungen. Fertig war es nach zweieinhalb.

Am meisten wog, dass der Kunde ohne Sprints jeden Tag Fortschritte sah und jeden Tag korrigierte. Als ihm in der zweiten Woche klar wurde, dass eine der drei Dashboard-Ansichten niemand nutzen würde, haben wir sie noch am selben Nachmittag entfernt. In einem Zwei-Wochen-Sprint wäre diese Änderung zu spät gekommen, mit der Ansicht schon gebaut und getestet.

Die Gründerin sagte uns hinterher, wir seien der erste Dienstleister, bei dem sie nicht das Gefühl hatte, zu warten.

Der Kunde, der keinen Wochenbericht mehr wollte

Mehreren Kunden schickten wir einen wöchentlichen Statusbericht. Die Projektleitung schrieb ihn freitags auf Basis des Jira-Boards, und er kostete gut eine Stunde.

Ein Kunde fragte, ob er direkt “diese Liste, die ihr benutzt” sehen könne. Wir gaben ihm Lesezugriff auf die tasks.md. Zwei Wochen später bat er uns, ihm den Bericht nicht mehr zu schicken: Er schaute lieber in die Liste, wann es ihm passte, und dort stand alles, was er wissen musste. In seinen Worten verstand er in der Datei mehr als im Bericht, weil jede Zeile von der Person stammte, die die Arbeit gemacht hatte.

Nicht jeder Kunde will das so, und das ist in Ordnung. Aber keiner hat uns gebeten, zum Board zurückzukehren.

Einarbeitung an einem Tag

Wer mitten in ein laufendes Projekt einsteigt, verbringt normalerweise zwei oder drei Tage damit, Tickets zu lesen, Fragen zu stellen und zu verstehen, was halb fertig ist. Diesen Sommer kam ein neuer Entwickler in ein Projekt, das seit vier Monaten lief. Er bat den Agenten, die tasks.md und die Regeldatei zu lesen und ihm den Stand des Projekts zu erklären. Noch am selben Vormittag schloss er seine erste Aufgabe ab.

Weniger Meetings

Planning und Refinement haben wir abgeschafft. Wir reden weiterhin miteinander, nur anders: zehn Minuten am Morgen, in denen jeder sagt, woran er arbeiten wird, und kurze Gespräche, wenn etwas entschieden werden muss. Nach einem Monat erzählten die Leute im Team, dass sie ganze Nachmittage ohne Unterbrechung arbeiten konnten, und das merkte man an dem, was herauskam.

Was schiefging

Zwei Personen, dieselbe Aufgabe

An einem Dienstag behoben zwei Entwickler gleichzeitig denselben Fehler. Der Kunde hatte ihn über zwei Kanäle gemeldet, einer sah ihn in der E-Mail, der andere im Projektchat, und jeder gab ihn an seinen Agenten weiter. Keiner der beiden schaute vorher in die tasks.md, und die Agenten auch nicht, weil die Aufgabe noch nicht eingetragen war. Wir merkten es beim Review: zwei verschiedene Fixes für dasselbe Problem, beide vernünftig und nicht miteinander vereinbar.

Wir haben einen Nachmittag verloren. Das ist nicht viel, aber genau so etwas verhindert ein Board mit zugewiesener verantwortlicher Person, und das hatten wir abgeschafft.

Neun Tage “In Arbeit”

In einem anderen Projekt stand eine Aufgabe neun Tage lang auf “In Arbeit”. Die zuständige Person war in ein anderes, dringendes Projekt gewechselt und hatte sie nicht verschoben. Die Agenten gingen bei jedem Lesen der Datei davon aus, dass jemand daran saß, und rührten sie nicht an. Wir haben es entdeckt, als der Kunde nach der Funktion fragte.

Eine Datei, die sich selbst füllt, füllt sich mit dem, was der Agent weiß. Was außerhalb der Sitzung passiert (jemand wechselt das Projekt, ein Kunde überlegt es sich am Telefon anders), landet nicht in der Datei, wenn es kein Mensch hineinschreibt.

Der Agent, der etwas Halbfertiges für erledigt erklärte

Die tasks.md aktualisiert der Agent, und der Agent ist manchmal optimistisch. Wir hatten Aufgaben, die als erledigt markiert und nur halb fertig waren: Der Export funktionierte, aber nicht mit den echten Daten des Kunden; das Formular wurde abgeschickt, aber die Bestätigungsmail ging nicht raus. In beiden Fällen stand in der Datei “Erledigt”, mit derselben Selbstsicherheit.

Seitdem ist eine Aufgabe nicht erledigt, weil der Agent es sagt. Erledigt ist sie, wenn ein Mensch sie geprüft hat, und dieses Häkchen kann der Agent nicht setzen.

”Woran arbeitet ihr gerade?”

Das hat uns am meisten gekostet. Ein Kunde rief an einem Donnerstag an und fragte, völlig zu Recht, woran wir in dieser Woche arbeiteten. Die Projektleitung wusste es nicht sicher. Im Projekt waren zwei Personen, jede mit zwei oder drei offenen Agentensitzungen, und die tasks.md zeigte, was abgeschlossen war, aber nicht, was gerade passierte. Die Projektleitung musste im Teamchat nachfragen und den Kunden zwanzig Minuten später zurückrufen.

Mit Jira beantwortete ein Blick auf eine Spalte diese Frage. Die Spalte log oft, aber die Frage war beantwortet.

Die Geschwindigkeitsfalle

Der Kunde mit der Änderung aus dem Meeting gewöhnte sich daran, dass Dinge am selben Tag kamen. Drei Monate später wollte er eine Anbindung an sein Abrechnungssystem, die von einem externen Anbieter abhing und von Berechtigungen, die eine Woche auf sich warten ließen. Für ihn war eine Woche quälend langsam. Früher wäre dieselbe Integration ein ganzer Sprint gewesen, und das hätte er normal gefunden.

Tempo verändert, was der Kunde erwartet, und wenn etwas nicht schnell gehen kann, muss man es erklären, bevor er fragt. Das haben wir spät gelernt.

Das Problem, das wir nicht gelöst haben: paralleles Arbeiten

Wenn es eine Sache gibt, die Jira gut konnte und wir noch nicht, dann ist es, mehrere Personen zu koordinieren, die gleichzeitig am selben Projekt arbeiten.

Mit Agenten kann jeder Entwickler mehrere Aufgaben gleichzeitig vorantreiben. Das vervielfacht, was herauskommt, vervielfacht aber auch die Gefahr, dass zwei Aufgaben dasselbe Stück Code anfassen oder zwei Personen dasselbe Problem getrennt lösen. Und die tasks.md reicht dafür nicht, weil sie zeigt, was entschieden oder abgeschlossen ist, nicht, was gerade passiert.

Was wir heute tun, ist wenig raffiniert: Die Entwickler reden miteinander. Bevor jemand etwas anfängt, das einen heiklen Teil des Projekts berührt, sagt er im Teamchat Bescheid, mit einem “Ich gehe heute Vormittag an die Zahlungen”. Das Zehn-Minuten-Meeting jeden Morgen dient vor allem dazu. Und die Regel lautet: Eine Aufgabe wird mit Namen in die Datei eingetragen, bevor sie an einen Agenten geht, nicht danach.

Das funktioniert, weil wir pro Projekt wenige sind und uns kennen. Ob es mit fünfzehn Leuten funktionieren würde, weiß ich nicht.

Wir haben anderes ausprobiert, das nicht funktioniert hat:

• Eine Aufgabendatei pro Person. Jeder kannte seinen Teil, und niemand sah das Ganze. Das hielt zwei Wochen.
• Den Agenten melden lassen, woran er sitzt. Wir baten ihn, zu Beginn in die Datei zu schreiben, was er anfassen würde. Das tat er, aber wenn zwei Sitzungen fast gleichzeitig starteten, sah keine, was die andere geschrieben hatte.
• Zurück zu einem Board nur für laufende Arbeit. Das hielt kürzer als die Datei pro Person. Niemand hat es aktualisiert, aus demselben Grund wie früher.

Wir schauen uns Werkzeuge an, die genau das lösen wollen. Orca von Stably AI ist eine Open-Source-Desktop-App, die mehrere Agenten parallel startet, jeden isoliert, und auf einem einzigen Bildschirm zeigt, was jeder gerade tut, und die Ergebnisse vergleichen lässt. Das löst die Frage, was die Agenten einer Person tun. Die Frage, was jede Person im Team tut, bleibt offen.

Was Atlassian und Linear machen

Die Hersteller von Trackern haben dasselbe gesehen und reagieren, indem sie die Agenten ins Produkt holen.

Atlassian hat Agents in Jira im Februar 2026 als Beta geöffnet und im Mai auf der Team ‘26 als allgemein verfügbar angekündigt. Sie weisen ein Ticket einem Agenten über dasselbe Dropdown zu, das Sie für eine Person nutzen, und der Agent liest das Ticket und dokumentiert dort seinen Fortschritt.

Linear hat eine Entscheidung getroffen, die ich für besser halte: Ein Issue wird nur Personen zugewiesen und an Agenten delegiert. Der Agent arbeitet, verantwortlich bleibt ein Mensch. Auf dem Bildschirm ist das ein kleiner Unterschied, in der Praxis ein großer, weil klar ist, wer geradesteht, wenn der Agent sich irrt. Genau das ist uns mit den Aufgaben passiert, die der Agent für erledigt erklärte.

Beide Antworten haben dasselbe Grundproblem: Sie gehen davon aus, dass ein Ticket eine gute Spezifikation für einen Agenten ist, und das ist fast keins. “Login in Safari reparieren” reicht einem Menschen, der weiß, wen er fragen kann. Ein Agent mit diesem Ticket wird irgendetwas tun, und zwar sehr selbstsicher. Weil das Zuweisen von Tickets an Agenten so bequem ist, landet schlecht erklärte Arbeit leichter bei etwas, das nicht nachfragt.

Wo Jira weiterhin recht hat

Wenn Sie bis hierher gelesen haben und denken “Das funktioniert bei euch, weil ihr wenige seid”, haben Sie teilweise recht. Es gibt Bereiche, in denen ich Jira nicht abschaffen würde:

• Mehrere Teams, die voneinander abhängen. Eine tasks.md koordiniert ein Projekt. Wenn das Payment-Team darauf angewiesen ist, dass das Plattform-Team etwas ändert, und jedes an seinem eigenen Teil arbeitet, braucht es einen gemeinsamen Ort, an dem diese Abhängigkeit sichtbar ist.
• Leute, die nicht im Projekt sind. Geschäftsführung, Support, Vertrieb oder Compliance müssen wissen, was passiert, ohne eine Datei im Code zu öffnen. Ein Board ist eine Oberfläche für sie, und daran ändert sich nichts, nur weil ein Agent den Code schreibt.
• Audits. Wenn Sie nach ISO 27001 oder SOC 2 auditiert werden, will der Auditor sehen, dass jede Änderung eine Anforderung, eine Freigabe und eine verantwortliche Person hat. Wenn Ihr Change-Management-Prozess schon auf Jira aufbaut, lohnt sich der Umbau nicht.
• Das Team eines Kunden. Wenn wir uns in das Produktteam eines Kunden einfügen, arbeiten wir mit dessen Werkzeugen. Bei Orquest haben wir ihr Jira genutzt und an ihren Dailies teilgenommen. Da gibt es nichts zu diskutieren: Der Tracker gehört ihnen.

Gemeinsam ist allen, dass es fast immer um Kommunikation mit Menschen geht, die nicht im Code stecken. Der Teil von Jira, der weiterhin Sinn ergibt, ist der, der mit Menschen spricht. Für uns hat der Teil seinen Sinn verloren, der die Arbeit der Entwickler plante.

Was wir tun würden, wenn wir heute anfingen

Das ändert sich weiter, aber wenn uns morgen ein Team fragte, wie es anfangen soll, würden wir ihm Folgendes sagen:

1. Hören Sie auf, die Arbeit eines Agenten zu schätzen. Wenn das Team weiter Punkte für Aufgaben von vierzig Minuten vergibt, misst es das Ritual und nicht die Arbeit.
2. Legen Sie die Aufgabenliste ins Projekt, in eine Datei, die der Agent zu Beginn liest und am Ende aktualisiert. Billiger bekommt der Agent kein Gedächtnis zwischen den Sitzungen.
3. Tragen Sie die Aufgabe mit Namen ein, bevor Sie sie einem Agenten geben. Das ist die einzige Regel, die uns tatsächlich doppelte Arbeit erspart hat.
4. Erledigt ist eine Aufgabe erst, wenn ein Mensch sie geprüft hat. Der Agent kann vorschlagen, dass sie fertig ist; entscheiden kann er es nicht.
5. Sprechen Sie mit dem Rest des Teams, bevor Sie etwas Heikles anfassen. Eine einzeilige Nachricht im Chat erspart einen verlorenen Nachmittag. Etwas Besseres haben wir noch nicht gefunden.
6. Schließen Sie, was sich seit Wochen nicht bewegt. Eine Aufgabe, die seit sechs Wochen niemand angefasst hat, ist eine Entscheidung, die niemand treffen wollte. Wenn sie wichtig war, macht sie jemand wieder auf.
7. Behalten Sie Jira, oder was Sie sonst nutzen, für die Kommunikation mit allen, die nicht im Code arbeiten. Kunden, die es so wollen, Geschäftsführung, Audit.

In sechs Monaten ist dieser Text wahrscheinlich schon veraltet. Wenn wir das parallele Arbeiten lösen, erzählen wir es hier. Und wenn jemand es schon gelöst hat, würden wir gern erfahren, wie: Schreiben Sie uns an info@soamee.com.