Stakeholder wollen Ergebnisse, keine Tickets

Ticketing ist ein Prozess und nichts weiter. Ein Ticket beschreibt ein Problem, einen Lösungsansatz oder eine Anforderung. Es hilft dabei, Informationen möglichst verlustfrei von einer Person zur nächsten zu transportieren. Das eigentliche Ziel war aber nie das Ticket selbst. Das Ziel ist immer das Ergebnis, das am Ende entsteht.

Genau das wird deutlich, wenn man Stakeholdern aufmerksam zuhört. Noch nie hat sich jemand Monate später daran erinnert, wie gut eine User Story geschrieben war oder wie sauber die Akzeptanzkriterien formuliert wurden. Die einzige Frage lautet: Haben wir das Problem gelöst?

Für Stakeholder ist die Dokumentation unsichtbar – und das ist auch richtig so. Sie gehört zum Maschinenraum eines Produktteams. Gute Dokumentation ist wichtig, aber sie ist niemals der eigentliche Mehrwert.

Das bedeutet allerdings nicht, dass Tickets unwichtig sind. Sie müssen verständlich sein, ausreichend Kontext liefern und Entwicklern klar vermitteln, was gebaut werden soll und warum. Schlechte Tickets kosten später Zeit – durch Rückfragen, Missverständnisse oder Features, die zwar exakt der Spezifikation entsprechen, das eigentliche Problem aber verfehlen.

Perfekt müssen sie deshalb trotzdem nicht sein.

Wenn zwei zusätzliche Stunden Dokumentation keinen besseren Output erzeugen, waren es schlicht zwei Stunden zu viel. Gute Produktarbeit bedeutet nicht, möglichst viel zu dokumentieren, sondern genau so viel, wie das Team benötigt.

Gerade hier verändert KI meine Arbeitsweise. Heute kann ich aus einer groben Beschreibung innerhalb weniger Sekunden einen ersten Ticketentwurf inklusive Akzeptanzkriterien erzeugen lassen. Das spart Zeit, ersetzt aber nicht das eigentliche Denken. KI kann formulieren. Sie kann strukturieren. Sie kann schreiben. Entscheiden, was gebaut werden soll und warum, muss weiterhin der Product Owner.

Der eigentliche Wert lag nie im Schreiben eines Tickets. Er lag immer darin, das Problem richtig zu verstehen.

Ein weiterer Grund, Tickets nicht zu überbewerten, ist, dass sich das Verständnis eines Problems fast immer verändert.

Die erste Anforderung eines Stakeholders beschreibt häufig nicht das eigentliche Bedürfnis, sondern bereits seine vermutete Lösung. Wenn jemand sagt: „Wir brauchen einen neuen Filter“, steckt dahinter oft etwas völlig anderes – beispielsweise, dass Nutzer Inhalte nicht finden. Ein Wunsch nach einem Dashboard bedeutet häufig nicht, dass ein weiteres Dashboard fehlt, sondern dass den bestehenden Zahlen nicht vertraut wird.

Genau hier beginnt die eigentliche Produktarbeit.

Frameworks wie Outcome over Output oder Jobs to be Done beschreiben letztlich genau diesen Gedanken: Nicht das gewünschte Feature steht im Mittelpunkt, sondern das Problem, das ein Nutzer oder Stakeholder tatsächlich lösen möchte.

Ein guter Product Owner versucht deshalb möglichst früh, hinter die geäußerte Anforderung zu schauen. Je besser dieses Verständnis ist, desto geringer ist die Wahrscheinlichkeit, später das falsche Feature zu entwickeln.

Auch dabei unterstützt mich KI inzwischen regelmäßig. Sie hilft dabei, Interviewnotizen zusammenzufassen, Feedback zu clustern oder verschiedene Lösungsansätze zu entwerfen. Nicht, weil sie bessere Entscheidungen trifft, sondern weil sie mich schneller zu den Informationen bringt, auf deren Grundlage ich Entscheidungen treffen kann.

Deshalb versuche ich heute nicht mehr, perfekte Tickets zu schreiben. Ich versuche vielmehr, den Weg von einem Problem zu einer funktionierenden Lösung kontinuierlich zu verbessern.

Das sind zwei unterschiedliche Ziele. Das Team mit dem saubersten Backlog entwickelt nicht automatisch das beste Produkt. Ein Ticket bleibt ein Kommunikationswerkzeug – nicht mehr und nicht weniger. Seine Aufgabe ist erfüllt, sobald alle Beteiligten verstanden haben, was gebaut werden soll und warum.

Am Ende erinnern sich Stakeholder nicht an gut formulierte Tickets. Sie erinnern sich daran, ob ihr Problem gelöst wurde. Und genau daran sollte sich auch gute Produktarbeit messen lassen.