3 Gründe, warum Jira für schlechte User Stories sorgt – und was Du jetzt dagegen tun kannst

3 Gründe, warum Jira für schlechte User Stories sorgt – und was Du jetzt dagegen tun kannst

Ein Blick ins Backlog – und am liebsten würde ich es direkt wieder zumachen. Als erstes springt mich das Ticket mit der kryptischen Überschrift an. Beschreibung? Gibt es noch keine. Na gut, das nächste: „Neues Feature“. Was sich dahinter wohl verbirgt? „Ein Nutzer braucht einen blauen Button“. Wer hat das denn angelegt? Ah ja, alles klar. Und dann gibt es da noch das Ticket mit den 217 Kommentaren, die noch in die Beschreibung eingearbeitet werden wollen. Worauf haben wir uns da nochmal geeinigt? Puuh.

Kennst Du solche Backlogs? Wenn Du Product Owner bist, kannst Du Dir vielleicht vorstellen, wovon ich hier rede. Und Du bekommst allein von dem Gedanken daran eine Gänsehaut. Schließlich ist es als Product Owner Deine Aufgabe, dass Dein Team stets weiß, was als nächstes zu tun ist. Und dazu gehört: Klare, präzise und prägnante User Stories schreiben und verständliche Tickets anlegen.

Aber nicht immer macht es Dir Euer Ticketsystem leicht: Egal, wie viel Zeit, Energie und Liebe Du in Tickets steckst, so wirklich optimal läuft es (noch) nicht. Warum ist das eigentlich so?

Grund 1: Jira ist ein Tool zur Aufgabenverwaltung und kein Werkzeug für gute User Stories

Fast alle Softwareteams nutzen Jira oder ein vergleichbares Ticketsystem, um sich zu organisieren. Welche Features bearbeiten wir im nächsten Sprint? Welche Bugs müssen dringend gelöst werden? Wer macht was? Wie weit sind wir eigentlich? Jira hilft uns, Aufgaben zu verwalten und zu organisieren. Es verschafft uns Übersicht darüber, was ansteht und wo wir stehen. Darin ist Jira gut und ohne die Zuweisung von Tickets und die asynchrone Aktualisierung des Fortschritts wären viele Teams wahrscheinlich im Chaos verloren.

Schaut man sich Jira aber einmal unvoreingenommen an, sieht man, dass Tickets aus einem Titel, einer Beschreibung und sehr vielen Statusinformationen (Assignee, Status, Estimations etc.) bestehen. Der eigentliche Inhalt von Tickets, d. h. was genau zu tun ist, wird in einem Freitextfeld (Description) beschrieben. Mehr Vorgaben gibt uns Jira hier nicht. Es lässt offen, ob wir die Beschreibung mit einem Satz oder umfangreichen Details befüllen. Wir sind auf uns selbst gestellt, hier gute Inhalte einzutragen.

Wichtige Informationen, die jeder Entwickler braucht und die wir in jeder agilen User Story finden, z. B. „Wer nutzt ein gewünschtes Feature?“, „Welche Randbedingungen gelten?“, „Was soll nicht Teil des Features sein?“ etc., werden in Jira Tickets nicht abgefragt. Nur wenn wir die nötige Disziplin aufbringen und beispielsweise ein Template benutzen oder Vorgaben einhalten, bekommen wir gute Tickets. Jira selbst greift uns hier einfach nicht unter die Arme.

Grund 2: Jira fördert Diskussionen, zwingt uns aber nicht, zu einem Ergebnis zu kommen

Jira hat eine Kommentarfunktion. Und diese Funktion wird viel und gerne genutzt. „Unter“ den Tickets führen Entwickler, Designer und POs oft lange Diskussionen oder versuchen Details zu klären. Jeder kennt Tickets, bei denen man scheinbar endlos nach unten scrollen kann. Ein Ende der Diskussion scheint nicht in Sicht.

Obwohl eine Diskussion oder die Klärung von offenen Fragen nützlich und wichtig ist, so wird es für den Leser des Tickets unheimlich schwer, den aktuellen Stand des Tickets schnell und einfach zu erfassen. Oft muss er oder sie die gesamte Diskussion in ihrer epischen Länge noch einmal nachvollziehen, um zu verstehen, was das Ergebnis der Diskussion ist und was nun genau zu tun ist. Das ist so ähnlich, als müsste man alle Transaktionen auf seinem Girokonto jedes Mal selbst aufaddieren, wenn man den Kontostand wissen möchte.

Natürlich könnte man die Beschreibung des Tickets kontinuierlich aktualisieren, aber die Mechanismen, die uns Jira anbietet, verleiten offensichtlich dazu, lieber Kommentare zu schreiben. Jeder kann sehen, wer was gesagt hat. Jira hilft uns dabei zu diskutieren, aber es hilft uns nicht, das Ergebnis dieser Diskussion vernünftig festzuhalten. Jeder Lesende muss das Ergebnis aus den Kommentaren rekonstruieren. Wir arbeiten nicht mit einer klaren Anforderungsbeschreibung, sondern einem länglichen Diskussionsprotokoll.

Grund 3: Jira setzt den Fokus auf Output statt Outcome

Schaut man sich die Funktionalitäten von Jira genau an so findet man unheimlich viele Dinge, die dabei helfen sollen, Fortschritt quantitativ zu messen. Wie viele Tickets sind im Sprint schon erledigt (Burndown-Chart)? Wie viele Tickets sind schon angefangen? Wie hoch ist die Velocity eines Teams? Wie viele Epics können wir für die nächsten Monate und Quartale einplanen? Welche Aufwände sind für ein Feature geschätzt? Welche Roadmap ergibt sich aus den geschätzten Aufwänden und den verfügbaren Ressourcen?

Jira ist offenbar mit einem Fokus auf diese Fragen entwickelt worden. Die Frage „Wie viele Tickets sind fertig?“ wird über die Frage „Wie viel Nutzen haben wir für Kunden erzeugt?“ gestellt. Jira leitet uns nicht an, Tickets bezüglich ihres Werts zu betrachten oder zu bewerten. Nichts spiegelt wider, ob wir einhundert Tickets abhaken, die absolut keinen Kundennutzen erzeugen, oder ob wir genauso viele Features erledigen, die bei Kunden für echtes „Delightment“ oder „Excitement“ sorgen.

Jira hilft uns dabei, selbst Kleinigkeiten nicht zu vergessen, aber es hilft uns nicht, wirklich produktiv zu sein.

Du willst dafür zu sorgen, dass Eure Tickets klar, vollständig und einfach zu verstehen sind? Du willst sicherstellen, dass Dein Team maximalen Kundenwert erzeugt?

Egal, ob Du mit Jira oder einem anderen Ticketsystem arbeitest, der Schlüssel liegt darin, bei der Erstellung der Tickets die richtigen Fragen zu stellen. An der Stelle wo Jira und ein weißes Blatt Papier (das Description Textfeld) vorlegt, brauchst Du eine Liste von Fragen, die für jede gute User Story oder jedes Feature beantwortet werden müssen.

Fragen zum Kundennutzen:

• Wer braucht dieses Feature?
• Wobei hilft ihm/ihr dieses Feature?
• Warum schafft das Feature Wert für den Nutzer?
• Wie erledigt der Nutzer seine/ihre Arbeit bisher?

Fragen zur technischen Umsetzung:

• Wie soll das Feature genau funktionieren?
• Welche Voraussetzungen müssen erfüllt sein, damit man das Feature benutzen kann?
• Welche Anforderungen an Performance, Antwortzeiten oder Sicherheit gibt es?
• Welche Implikationen hat das Feature auf andere (existierende oder geplante) Features?
• Welche Ausnahmefälle müssen bedacht werden?
• Was soll (bewusst) nicht umgesetzt werden?
• Wie kann das Feature getestet werden?

Diese Liste lässt sich sicher noch fortführen und einige Bestandteile erscheinen evtl. bekannt. Einige Teams arbeiten mit Templates und Checklisten für Definition of Ready (DoR) und Definition of Done (DoD), um Antworten auf diese Frage zu erzwingen.

Doch es geht noch weiter! Um wirklich gute User Stories zu bekommen, braucht es nicht nur einen statischen Katalog von Fragen. Die richtig guten Fragen stellen (momentan) die Menschen, die sich mit dem System auskennen. Sie kennen den Kontext und die Fachlichkeit. Sie wissen, was die Software kann und was nicht. Genau deswegen besprechen fast alle POs die Tickets mit ihren Entwicklern und Entwicklerinnen in Refinement-Meetings. Nur jemand mit dem notwendigen Kontextwissen kann Fragen stellen, die genau zum Feature passen und so die User Story vervollständigen und so klar wie möglich machen.

Wir sind davon überzeugt, dass man mit den richtigen Fragen auch die notwendigen Antworten bekommt. Da uns Jira (und andere Issue Tracking Tools) leider keine besonders konkreten Fragen stellen, helfen wir uns heute oft selbst. Wir nutzen Templates, füllen Fragebögen aus und haken Checklisten hab. Wir schreiben Solution Designs und diskutieren im Refinement.

Und doch sind unsere Tools kaum mehr als hübsche Formulare. Sie stellen uns statische Fragen und wir tippen Buchstaben in Eingabefelder.

Warum hier nicht einen Schritt weiter gehen?!

Wir möchten die Möglichkeiten nutzen, die uns KI mit ChatGPT und ähnlichen Sprachmodellen bereitstellt, um dynamisch bessere Fragen gestellt zu bekommen. Wir wollen Tools, die mitdenken und inspirierende Ideen vorschlagen. Wir wollen leere Eingabefelder durch einen smarten Helfer ersetzen, der uns (und Dir) hilft schneller bessere User Stories zu erzeugen. Dazu muss die KI sich keine Features für uns ausdenken – das überlassen wir besser noch den Menschen. Aber KI kann uns helfen, Features klarer und kundenorientierter zu beschreiben.

Um Product Ownern dieses Potenzial von KI zugänglich zu machen entwickeln wir den Product Copilot – eine KI die POs beim Schreiben von User Stories unterstützt.

Wenn Du ausprobieren willst, wie es ist, Deine User Stories mit einem smarten KI-Helfer zu schreiben, sichere Dir jetzt Early Access zum Tool.