10 Dinge, die Entwickler an (JIRA-)Tickets schätzen

Im letzten Monat habe ich auf dem PO-Camp darüber gesprochen, welche Bestandteile und Prinzipien aus Entwickler-Sicht für gute (JIRA-)Tickets erforderlich sind. Die gesammelten Anforderungen basieren auf der einen Seite auf kurzen Interviews mit Entwickler-Kollegen, die ich im Rahmen unserer Slacktime durchgeführt habe („Was machen für Dich gute JIRA-Tickets aus?“). Zum anderen fließen aber auch meine persönliche Erfahrung als Entwickler und Team-Mitglied, das relativ viel mit dem Kunden kommuniziert, mit ein.

Herausgekommen sind 10 Punkte, die sich auf das Format, den Inhalt und die Rahmenbedingungen, unter denen das Team mit den Tickets arbeitet, beziehen.

10 Dinge, die Entwickler an (JIRA-)Tickets schätzen

Während die Folien zum Talk absichtlich plakativ und provokativ waren, möchte ich in diesem Blogpost versuchen, die einzelnen Punkte möglichst kurz und prägnant zusammenzufassen:

1. Ticket-Typ

   • Der Ticket-Typ gibt ein erstes Gefühl für das Ticket: Während ein Bug alles von „ein Zeichen ändern“ bis „eine Woche Debugging“ heißen kann, ist eine Story etwas, das sich in der Regel in einem vorgegebenen (Maximal-)Rahmen bewegt.
   • Der Ticket-Typ sollte beim Erstellen des Tickets nicht vernachlässigt, sondern sorgfältig gesetzt werden.

2. Ticket-Titel

   • Der Titel ist gerade bei digitalen Ticket-Boards essentiell, um das Ticket schnell einordnen und vor allem aber auch wiedererkennen zu können (von der ersten Vorstellung des Tickets über das Refinement bis hin zur Bearbeitung).
   • Der Titel sollte kurz, prägnant und aussagekräftig sein.

3. Beschreibung

   • Die Beschreibung sollte immer eine User-Story enthalten („Als X möchte ich Y, um Z zu erreichen“). Eine Ausnahme hierfür sind Bug-Tickets.
   • In weiteren Absätzen kann die Beschreibung Hinweise auf Abweichungen zum „normalen“ Vorgehen, bereits bekannte mögliche Seiteneffekte, ähnliche Stellen, etc. enthalten. Das ist jedoch je Team sehr individuell.
   • Die Beschreibung sollte immer eine Person mit ausreichendem Fachwissen formulieren, um missverständlichen Formulierungen vorzubeugen.
   • Eine Beschreibung enthält nicht: technische Umsetzungsvorgabe, epische Aufgabenformulierungen, …

4. Akzeptanzkriterien

   • Akzeptanzkriterien sind überprüfbar.
   • Sie sind gegenüber der Beschreibung klar abgegrenzt.
   • Sie fungieren als eine Art „Checkliste“ für Entwickler (sind alle Bestandteile umgesetzt), Stakeholder (was genau ist nötig, um die User-Story zu erfüllen) und Tester (was muss ich im Rahmen dieses Tickets testen und was nicht).
   • Der in Akzeptanzkriterien verwendete Detailgrad ist von Team zu Team sehr unterschiedlich und muss sich mit der Zeit „eingrooven“.

5. Keine Redundanzen

   • $Dinge werden nur einmal im Ticket genannt: beispielsweise wird nur an einer Stelle auf einen Anhang verwiesen oder ein API-URL wird nur an einer Stelle genannt.

6. Keine Widersprüche

   • Das Ticket enthält keine widersprüchlichen Informationen!
   • Beschreibung, Akzeptanzkriterien, Anhänge, Kommentare, … über die Lebensdauer eines Tickets kommt es hier oft zu Inkonsistenzen, die entfernt sein sollten, sobald das Ticket für die Umsetzung freigegeben wird.

7. Anhänge

   • Das Ticket enthält nur Ticket-relevante Anhänge, bzw. Anhänge mit Ticket-relevanten Daten.
   • Über die Namen der Anhänge ist klar, welchem Zweck ein Anhang dient.

8. Links / URLs

   • Sind als solche deutlich erkennbar; z.B. um Pull-Request auf einen Blick
     erkennen zu können.

9. Sinnvoll (geschnitten)

   • Tickets sollten so geschnitten sein, dass sie als (Teil-)Feature eigenständig deploybar sind und damit schnell Nutzen beim Kunden erzeugen können.
   • Nach Möglichkeit haben Tickets keine Abhängigkeiten zu anderen Tickets.

10. Leicht verständlich

    • Leicht verständliche Tickets sind auch leicht zu schätzen bzw. einzuschätzen.
    • Sie haben weniger Potential für Missverständnisse, unvorhersehbaren Mehraufwand, …

10 Entwickler-Anforderungen an Tickets vs. INVEST

Ohne es beabsichtigt zu haben sind die im Mayflower-Entwickler-Kontext gesammelten Punkte relativ deckungsgleich mit dem, was sich hinter dem Akronym INVEST verbirgt. Seit 2003 kenn die agile Literatur INVEST als Checkliste bzw. Technik, um User-Stories zu evaluieren. Man kennt das geflügelte Wort „good user-stories are INVEST“ – gute User-Stories sind also:

• „I“ ndependent (of all others)
• „N“ egotiable (not a specific contract for features)
• „V“ aluable (or vertical)
• „E“ stimable (to a good approximation)
• „S“ mall (so as to fit within an iteration)
• „T“ estable (in principle, even if there isn’t a test for it yet)

Und weiter?

Diese Liste hat natürlich keinen Anspruch auf Vollständigkeit. Aber das Zusammentragen der Anforderungen, die wir als Entwickler an Tickets stellen, hat mir folgendes gezeigt: Wir setzten viele Dinge beim Schreiben von Tickets als Common Sense voraus, die den Ticket-Erstellern unter Umständen gar nicht bekannt sind, oder deren Bedeutung ihnen nicht bewusst ist. Und um noch einmal auf INVEST zurück zu kommen: Ich habe mir noch nicht die Mühe gemacht, die 10 Mayflower-Punkte akribisch gegen INVEST zu challengen.

Viel interessanter ist für mich aber auch, was für euch essentielle Anforderungen an gute (JIRA-)Tickets sind! Ab damit in die Kommentare, bitte :)