Warum das Ticket-Board ungeöffnet blieb

Ich baue derzeit mehrere Produkte weitgehend allein, mit Claude als Assistenten. Eines davon ist Mamabande, eine App für Mütter, deren gesamter Stand in meinem Obsidian-Wissenssystem liegt. Linear hatte ich dafür aufgesetzt, weil es zum Standardrepertoire gehört. Dann blieb es zwei Wochen lang ungeöffnet, nicht aus Nachlässigkeit, sondern weil es keinen Zweck mehr erfüllte: Der aktuelle Stand stand längst woanders, präziser und ohne dass ich Tickets pflegen musste. Das eigentliche Problem ist deshalb nicht das Werkzeug, sondern die selten hinterfragte Annahme, dass Produktarbeit zwingend ein Ticket-Board braucht. Diese Annahme stammt aus einer Zeit, in der ein Backlog der einzige geteilte Speicher zwischen vielen Beteiligten war. In der Solo-Arbeit mit einem KI-Assistenten und lebenden Dokumenten trägt sie nicht mehr.

Was ein Tool leistet, was KI ersetzt

Was ein Backlog-Tool eigentlich leistet

Bevor sich beurteilen lässt, ob ein Werkzeug entfallen kann, muss klar sein, welche Arbeit es überhaupt erledigt. Ein Ticket-Tool wie Linear oder Jira bündelt mehrere Funktionen, die in der Praxis meist als eine wahrgenommen werden:

• Priorisierung: Was kommt als Nächstes, was wartet, was fällt raus.
• Inkremente schneiden: Große Vorhaben in machbare Einheiten zerlegen.
• Status: Wo steht jede Einheit gerade, was ist erledigt, was blockiert.
• Verlauf: Wer hat wann was entschieden und warum.
• Sichtbarkeit: Andere können nachsehen, ohne mich zu fragen.
• Verbindlichkeit: Eine Zuweisung ist eine sichtbare Zusage.

Die ersten vier Funktionen sind kognitive Arbeit: ordnen, zerlegen, festhalten, nachvollziehen. Die letzten beiden sind soziale Arbeit: sehen lassen und sich verpflichten. Genau an dieser Trennlinie entscheidet sich, ob ein KI-Assistent das Tool ersetzen kann.

Was ein KI-Assistent plus lebende Dokumente übernimmt

Die kognitiven Funktionen kann ein KI-Assistent zusammen mit drei lebenden Dokumenten tragen. Lebend heißt: ein Dokument, das immer den aktuellen Stand zeigt statt einer Historie aus Tickets. In meiner Solo-Arbeit sind das drei Dateien:

• Eine Produkt-Doku, die den aktuellen Stand beschreibt, nicht die Vergangenheit. Was ist gebaut, was ist als Nächstes dran.
• Ein Backlog als lebende Datei, eine geordnete Liste statt einzelner Karten. Die Priorität ergibt sich aus der Reihenfolge.
• Ein Decision-Log für Architektur- und Produktentscheidungen, ein leichtgewichtiges ADR-Format. Warum so entschieden wurde und welche Alternativen es gab.

Den Verlauf übernimmt Git: Jede Änderung an diesen Dateien ist ein datierter, nachvollziehbarer Commit, also ein vollständiger Audit-Trail ohne manuelle Ticketpflege. Priorisierung und das Schneiden der Inkremente entstehen im Dialog: Ich beschreibe das Ziel, der Assistent schlägt einen Schnitt vor, wir verhandeln ihn, und das Ergebnis landet im lebenden Backlog. Der entscheidende Unterschied liegt in der Aktivität des Gegenübers. Ein Ticket-Board ist ein passiver Speicher, in den ich aktiv hineinschreiben muss. Ein KI-Assistent ist ein aktiver Gegenpart, der den Stand zwischen den Sitzungen hält und mir die Pflege abnimmt.

Daraus folgt ein einfaches Kriterium: Was als Nebenprodukt der eigentlichen Arbeit einen aktuellen Stand hinterlässt, trägt. Was zusätzliche Pflege verlangt, die niemand liest, fällt mit der Zeit durch. Die Interaktion mit dem Assistenten ist die Arbeit selbst, nicht ihre Buchhaltung, und gerade das macht sie haltbar.

Hier lohnt eine Präzisierung der eigenen These. Lebende Dokumente sind kein Speicher ohne Leser, denn sie haben einen: den Assistenten. Er liest sie bei jeder Sitzung. Das verschiebt die Frage. Nicht ob ich einen Speicher pflege, sondern ob er so strukturiert ist, dass sein wichtigster Leser ihn versteht. Eine unsortierte Notizhalde trägt einen Assistenten so wenig wie einen Menschen. Die Pflege verschwindet damit nicht, sie wandert vom Ticketstatus zur Lesbarkeit für die Maschine.

Was der Assistent allein nicht übernimmt

Was lebende Dokumente und Dialog nicht leisten, sind die sozialen Funktionen: Sichtbarkeit und Verbindlichkeit über mehrere Menschen hinweg. Solange ich der einzige Mensch im System bin, fällt das nicht ins Gewicht, denn ich muss mir nichts sichtbar machen, was ich ohnehin weiß. Sobald ein zweiter Mensch hinzukommt, ändert sich die Rechnung grundlegend. Asynchrone Zusammenarbeit lebt davon, dass jeder denselben Stand sehen kann, ohne dass ich ihn erzähle. Genau hier hat ein geteiltes Artefakt seine Berechtigung, die im Solo-Fall vollständig fehlt. Linear, ein Board oder eine geteilte Map lösen primär ein Kommunikationsproblem zwischen Menschen, kein Denkproblem in einem einzelnen Kopf.

Was ich verändert habe

Solo arbeite ich heute ohne Ticket-Tool. Mein Setup besteht aus den drei lebenden Dateien, dem Dialog mit dem Assistenten und Git als Verlauf. Den Backlog halte ich als geordnete Liste statt als Kartenstapel und priorisiere durch Umsortieren, nicht durch Status-Felder.

Im Team mache ich es bewusst anders. Gerade arbeite ich mit mehreren Beteiligten an einer Produktidee: MatGrid, einer KI-gestützten Plattform, die Dachdeckern die Materialermittlung für ihre Projekte abnimmt und den Rechercheaufwand zwischen Herstellerdaten, Normen und Produktauswahl automatisiert. Dort reicht der Stand in meinem Kopf nicht mehr, weil ihn andere sehen müssen. Statt Tickets zu verteilen, habe ich fürs MVP-Scoping eine interaktive Story-Map gebaut: eine deployte, geteilte Seite im eigenen Branding, ergänzt um eine DACI-Matrix für die Rollenklärung. Alle sehen denselben Zusammenhang auf einen Blick, ohne synchron darüber reden zu müssen. Das ist kein Widerspruch zur Solo-Position, sondern ihre logische Fortsetzung: Das Medium folgt der Zahl der Köpfe, die denselben Stand sehen müssen.

Wenn das Tool bleibt: KI statt statischer Views

Es gibt einen dritten Fall, in dem ein Ticket-Tool nicht verschwindet: das größere Team mit hohem Durchsatz, vielen parallelen Strängen und echten Abhängigkeiten zwischen den Funktionen. Hier trägt Linear weiter. Doch auch in diesem Fall verändert ein KI-Assistent, was das Tool überhaupt leisten kann.

Klassisch arbeitet man in Linear mit gespeicherten Views, also vordefinierten Filtern über Zuständigkeit, Label und Status. Eine View beantwortet eine Frage, die ich vorab kenne, in der Struktur, die das Tool zulässt. Sie zeigt eine Liste, und ich muss sie selbst lesen, deuten und gegen die Lage von gestern halten. Ändert sich meine Frage, baue oder pflege ich die nächste View.

Ein Assistent mit Zugriff auf die Boards arbeitet anders. Er liest nicht nur die Metadaten, sondern den Inhalt der Tickets, und das über alle Teams hinweg. So beantwortet er die Frage, die ich heute habe, etwa was diese Woche quer durch fünf Teams den Launch blockiert. Das ist keine gespeicherte Abfrage, sondern eine Interpretation. Der Gewinn liegt auf drei Ebenen. Erstens entfällt die Pflege der Views, weil die Frage sich täglich ändern darf, ohne dass ich etwas umkonfiguriere. Zweitens zieht der Assistent aus vielen Boards die wenigen Punkte zusammen, die zählen, samt teamübergreifender Abhängigkeiten, die eine einzelne View gar nicht abbilden kann, etwa wenn ein Ticket in Team A ein Ticket in Team B aufhält. Drittens bleibt es nicht bei einer Liste: Der Assistent erklärt, warum ein Punkt kritisch ist und was als Nächstes ansteht, und meldet von sich aus, wenn Tickets stillstehen oder ihren Zuschnitt verändern.

Der Unterschied zur eigenen View ist damit kein gradueller. Eine View strukturiert vorhandene Daten nach einer Frage von gestern. Ein Assistent synthetisiert aus denselben Daten eine Antwort auf die Frage von heute und nimmt mir das Lesen, Verknüpfen und Einordnen ab. Der Engpass verschiebt sich vom Konfigurieren der Filter zum Stellen der richtigen Frage.

Das ist keine Zukunftsvision am Reißbrett. Die Plattformen selbst bewegen sich genau dorthin: Ticket-Tools binden inzwischen Assistenten direkt ein, die Tickets lesen, zuordnen und Fragen dazu beantworten. Die Frage ist deshalb nicht mehr, ob ein Assistent das Board steuert, sondern wessen Assistent es tut und wie gut er die Daten vorfindet.

Diese Wirkung hat eine Bedingung, die man ehrlich benennen muss: Der Assistent ist nur so gut wie die Datenpflege in den Tickets. Wo Titel nichtssagend und Beschreibungen leer sind, synthetisiert auch eine KI nur Nebel. Die Sichtbarkeit, die ein Team in seine Tickets investiert, bekommt es als Übersicht zurück, nicht mehr und nicht weniger.

Kritische Einordnung

Was lebende Dokumente kosten

Dieser Verzicht hat einen Preis, den man ehrlich benennen muss. Git speichert den Verlauf, aber es verhindert keine Drift. Lebende Dateien laufen mit der Zeit auseinander: Benennungen werden uneinheitlich, die Struktur franst aus, und nach einigen Monaten ist nicht mehr selbstverständlich, welche Datei den gültigen Stand hält. Solo trage ich diese Pflege still mit, weil ich das System im Kopf habe. Sobald ein zweiter Mensch oder ein zweiter Assistent dazukommt, wird sie zur expliziten Aufgabe: Wer hält die Dokumente konsistent, wer ist der Linter? Dazu kommt eine Voraussetzung, die selten erfüllt ist, nämlich das Warum mitzuschreiben und nicht nur das Was. Ein Decision-Log trägt nur, wenn es wirklich geführt wird. Lebende Dokumente schaffen den Aufwand also nicht ab, sie verschieben ihn vom Ticketstatus zur Konsistenz der Dateien.

Dass dahinter kein Einzelfall-Reflex steckt, zeigt der Blick in die Fachdebatte. Erfahrene Agile-Praktiker kommen unabhängig zur selben Schlussfolgerung, versionierte und strukturierte Dateien als Wissensmodell für KI statt fragmentierter Tickets, und sie benennen dieselbe Achillesferse: die Governance dieser Dateien. Der Konsens ist nicht, dass das Tool verschwindet, sondern dass sich der Ort der Wahrheit verschiebt und die Pflege ihm folgt.

Funktioniert dieser Verzicht nur bei mir? Teilweise, denn jedes Setup trägt eine persönliche Arbeitsweise mit. Die Logik dahinter ist jedoch allgemein: Ein Speicher ohne Leser ist verschwendete Arbeit. Die Grenze des Solo-Setups ist klar benannt. Es skaliert nicht über eine Person hinaus, und schon bei vielen parallelen Strängen mit dichten Abhängigkeiten stößt eine lineare lebende Datei an ihre Grenzen. Dann hilft die explizite Struktur eines Tools, das Status und Abhängigkeiten modelliert, idealerweise gesteuert von einem Assistenten wie oben beschrieben. Auch der Eigenbau hat eine Grenze: Eine selbstgebaute Story-Map lohnt sich, wenn das geteilte Bild den Aufwand trägt, für eine schnelle Solo-Notiz ist sie Overengineering. Das Werkzeug folgt dem Problem, nicht umgekehrt.

Drei Optionen, drei Einsatzfelder

Die belastbare Antwort auf die Leitfrage ist deshalb keine Ja-Nein-Entscheidung, sondern eine Zuordnung von Medium zu Kontext:

• Lebende Docs plus Dialog sind das richtige Medium für die Solo-Arbeit mit einem KI-Assistenten. Die kognitive Arbeit erledigt der Assistent, der Stand steht in den Dateien, der Verlauf in Git. Ein Ticket-Tool ist hier überflüssig.
• Eine visuelle Story-Map schlägt das Ticket-Board, sobald ein kleines Team asynchron ein gemeinsames Bild braucht, etwa für MVP-Scoping, Roadmap-Alignment und Rollenklärung. Eine Karte zeigt Zusammenhang und Priorität auf einen Blick, ein Board zeigt nur eine Liste von Karten.
• Ein Ticket-Tool wie Linear trägt, wenn ein größeres Team mit hohem Durchsatz das laufende Wie koordinieren muss. Seinen Wert entfaltet es heute aber weniger über manuell gepflegte Views als über einen KI-Assistenten, der die Boards teamübergreifend liest und das Wesentliche zusammenzieht.

Map und Ticket-Tool schließen sich nicht aus. In der Praxis klärt die Story-Map zuerst das gemeinsame Bild, und erst die daraus geschnittenen MVP-Karten wandern für die Umsetzung ins Ticket-Tool.