Die versteckten Kosten vager Jira-Tickets
Ein vages Jira-Ticket wirkt anfangs fast nie riskant. Das eigentliche Problem zeigt sich später, wenn unterschiedliche Menschen die Lücken mit unterschiedlichen Annahmen füllen und mehrere Tage konzentrierter Arbeit am falschen Ziel vorbeigehen.
Warum vage Tickets überleben
Eine Backend-Entwicklerin greift am Montagmorgen ein Ticket auf. Der Titel klingt konkret: „Benachrichtigungen für Nutzer bei Bestell-Updates hinzufügen“. Die Beschreibung besteht aus zwei Sätzen und einem Link zu einem Slack-Thread von vor drei Wochen. Das wirkt zunächst klar genug. Sie verbringt drei Tage damit, eine E-Mail-Benachrichtigungspipeline zu bauen, die bei jeder Statusänderung einer Bestellung ausgelöst wird.
Am Donnerstag schaut der PM in die PR-Review und sagt: „So war das nicht gemeint. Wir brauchten nur In-App-Benachrichtigungen für Versandereignisse, und die Nutzer sollten sie abschalten können.“ Niemand lag falsch. Niemand war nachlässig. Das Ticket hat die Entscheidungen, die darin versteckt waren, nur nie sichtbar gemacht.
Niemand schreibt absichtlich ein vages Ticket. Man schreibt es in zwei Minuten zwischen zwei Meetings, in der festen Absicht, später noch Details nachzutragen. Das passiert dann nicht. Die Person, die es verfasst, hat den ganzen Kontext im Kopf. Sie weiß, welche Ereignisse relevant sind, an welche Kanäle gedacht ist und welche Nutzer betroffen sind.
Nichts davon landet auf der Seite, weil es offensichtlich erscheint. Für alle anderen ist es das nicht.
Jira verschärft das Problem gerade dadurch, dass es so einfach ist. Es gibt kein Pflichtfeld, das fragt, was ausdrücklich nicht zum Umfang gehört. Es gibt keinen Schutzmechanismus, der eine Beschreibung unter zwanzig Wörtern zurückweist. Man kann drei Wörter in das Zusammenfassungsfeld tippen, die Beschreibung leer lassen und auf Erstellen klicken. Jira wehrt sich nicht. Das ist Stärke und Falle zugleich. So entsteht ein Backlog voller Tickets, die auf den ersten Blick vollständig wirken und ihre Unschärfe erst dann zeigen, wenn jemand schon mit dem Bauen begonnen hat.
Was ein wirklich baureifer Plan enthält
Die meisten Tickets beantworten eine Frage: Was wollen wir? Ein baureifer Plan beantwortet sechs.
| Teil | Was er beantwortet |
|---|---|
| Umfang | Was dazugehört und was ausdrücklich nicht dazugehört |
| Einschränkungen | Was nicht verändert oder beschädigt werden darf |
| Schritte | Was passieren muss und in welcher Reihenfolge |
| Randfälle | Was geschieht, wenn der offensichtliche Weg scheitert |
| Abhängigkeiten | Was vorher vorhanden sein muss |
| Definition von fertig | Woran alle erkennen, dass die Arbeit wirklich abgeschlossen ist |
Das ist keine Prüfliste für jeden winzigen Bugfix im Backlog. Aber alles, was in einen Sprint geht, alles, was voraussichtlich mehr als ein paar Stunden Zeit kostet, braucht diese Antworten vor dem Start. Am häufigsten überspringen Teams den Umfang. Festzuhalten, was nicht dazugehört, wirkt unnötig, wenn alle gedanklich bei dem sind, was drin ist. Gerade dort beginnt aber überraschend viel Nacharbeit.
Einschränkungen sind die stillen Anforderungen:
- Den bestehenden Bestell-E-Mail-Fluss nicht beschädigen.
- Im bestehenden Benachrichtigungsdienst bleiben.
- In diesem Sprint keine neue Infrastruktur aufbauen.
Diese Details werden selten notiert, weil der Autor davon ausgeht, dass sie ohnehin allen bekannt sind. Das sind sie nicht. Und die Definition von fertig ist die Linie zwischen „Ich glaube, das ist fertig“ und „Wir sind uns einig, dass es fertig ist“. Eine gute Definition von fertig ist beobachtbar und überprüfbar.
Fragen kommen vor Struktur
Irgendwann durchläuft jede Jira-Instanz denselben Zyklus. Jemand fügt eine Beschreibungsvorlage hinzu mit Abschnitten wie Zusammenfassung, Akzeptanzkriterien, Technische Hinweise und Außerhalb des Umfangs. Einige Wochen lang füllen die Leute das aus. Danach verteilt sich dieselbe vage Sprache, die früher in einer leeren Beschreibung stand, einfach auf mehr beschriftete Kästen. Die Struktur wurde besser. Das Denken nicht.
Vorlagen lösen das Problem nicht, weil das Problem nicht strukturell ist. Es ist kognitiv. Die Person, die schreibt, weiß nicht, was ihr fehlt. Ein leerer Abschnitt mit der Überschrift Randfälle hilft niemandem, der noch gar nicht an Randfälle gedacht hat. Fragen tun das. Konkrete, präzise Fragen, die Entscheidungen erzwingen.
Fünf Fragen holen versteckte Entscheidungen besonders zuverlässig nach oben:
- Was ändert sich im Verhalten des Systems?
- Wer ist die Hauptperson, und was versucht sie zu erreichen?
- Gibt es einen Fall, in dem das nicht passieren soll?
- Was geht kaputt, wenn wir das nicht ausliefern?
- Gilt das für bestehende Nutzer, neue Nutzer oder für beide?
Diese Fragen funktionieren, weil sie konkret genug sind, um beantwortet zu werden, und zugleich breit genug, um bei fast jedem Feature-Ticket zu helfen. Das Beantworten selbst ist die Planung. Die Vorlage ist nur der Ort, an dem die Antworten landen.
Vollständiges Beispiel
So sieht das in der Praxis aus. Das ursprüngliche Ticket ist winzig: „Benachrichtigungen für Nutzer bei Bestell-Updates hinzufügen“. In der Beschreibung steht nur, dass Nutzer benachrichtigt werden sollen, wenn sich der Bestellstatus ändert, plus ein Hinweis, das visuelle Verhalten mit dem Design abzustimmen. Das reicht, um in einen Sprint gezogen zu werden, aber bei Weitem nicht, um mit Sicherheit zu bauen.
Eine kurze Klärungsrunde verändert alles:
| Klärungsfrage | Antwort |
|---|---|
| Welche Statusänderungen sind relevant? | Nur versendet und zugestellt |
| Welche Kanäle? | In diesem Sprint nur in der App |
| Können Nutzer sie abschalten? | Ja, standardmäßig eingeschaltet |
| Was ist mit Nutzern, die offline sind? | Die Benachrichtigung wird bis zum nächsten Login vorgemerkt |
| Gilt das auch für bestehende Bestellungen? | Nein, nur für neue |
| Was passiert, wenn die Zustellung fehlschlägt? | Einmal erneut versuchen, dann protokollieren |
Fünfzehn Minuten später bedeutet das Ticket für alle genau dasselbe. Die neue Version enthält echten Umfang, echte Einschränkungen, geordnete Schritte, echte Randfälle und eine Definition von fertig, die sich testen lässt. Es ist dasselbe Ticket. Nur die Klarheit ist eine völlig andere. Der Unterschied ist keine bessere Vorlage. Der Unterschied ist eine kleine Menge bewusster Fragen, bevor die Arbeit beginnt.
Wo KI in diesen Prozess passt
KI schreibt keine Tickets. Menschen schreiben Tickets. Aber KI ist an einem ganz bestimmten Punkt im Prozess nützlich: nachdem die Absicht feststeht, bevor die Struktur final ist. Ein Sprachmodell kann eine vage Beschreibung lesen und fragen: „Habt ihr bedacht, was passiert, wenn der Nutzer offline ist?“ Es kann verstreute Antworten aus einem Slack-Thread in Umfang, Einschränkungen und Schritte ordnen. Es kann bemerken, dass im Plan eine Datenbankmigration erwähnt wird, in der Abhängigkeitsliste aber die Prüfung durch die richtigen Personen fehlt.
Worin KI nicht gut ist: Produktentscheidungen für euch treffen. Sie kann fragen, ob das per E-Mail, Push oder In-App laufen sollte. Sie kann aber nicht entscheiden, welche dieser Optionen für eure Nutzer und euren Sprint richtig ist. Sie kann eine plausible Definition von fertig erzeugen, aber nur ein Mensch mit Produktverständnis weiß, ob diese Definition tatsächlich passt.
Das Muster ist einfach: Menschen entscheiden, KI strukturiert. Menschen setzen den Umfang, KI findet Lücken. Genau auf diesem Muster, klären, planen, ausführen, baut Just im Atlassian Marketplace innerhalb von Jira auf. Dasselbe Muster funktioniert auch manuell. KI macht die Schleife nur schneller.
Drei Dinge für heute
- Nimm vor dem nächsten Sprint das vageste Ticket aus deinem Backlog und stelle die fünf Fragen aus diesem Artikel, bevor jemand Code schreibt. Du wirst mit hoher Wahrscheinlichkeit mindestens zwei Entscheidungen finden, von denen niemand gemerkt hatte, dass sie noch offen sind.
- Schreibe die Antworten als Umfang, Einschränkungen und überprüfbare Definition von fertig auf, nicht in ein separates Dokument, sondern direkt in das Ticket selbst, dort, wo die Person, die es baut, sie tatsächlich sieht.
- Verstehe die obige Vorlage als Ausgangspunkt, nicht als starre Norm. Passe sie an die Sprache deines Teams an, aber überspringe die Fragen nicht. Wenn du den größeren Rahmen dazu willst, warum dieser Klärungsschritt noch wichtiger wird, sobald vage Tickets direkt an KI weitergegeben werden, dann erklärt der erste Artikel dieser Reihe das Alignment-Problem im Detail: Warum die meisten KI-Tools für Jira das Alignment-Problem eher verschärfen als lösen.
