Tickethandling - Wie die Aufgabenverwaltung in Jira funktioniert

August 2020

In der alltäglichen Arbeit sind die Aufgaben (Issues) in Jira nahezu unerlässlich, um festzulegen, wer welche Aufgabe bis wann erledigen muss. Damit dieser Prozess so reibungslos wie möglich funktionieren kann, Bedarf es hier einiger wichtiger Punkte, damit klar regegelt ist, welche Informationen in einem Jira Ticket enthalten sein müssen, damit die Arbeit ohne große Verzögerungen an einer Aufgabe von allen beteiligten Personen durchgeführt werden kann.

Die folgenden aufgeführten Punkte sind zwar am Beispiel von Atlassian Jira formuliert, können aber auch auf andere Tools übertragen werden. Wichtig ist grundsätzlich, dass die Informationen vorhanden sind, die nötig sind, um eine Aufgabe effizient zu bearbeiten. Das wird nicht immer möglich sein, weil es im Alltag durchaus Aufgaben gibt, bei denen wichtige Informationen fehlen oder das Ziel in der Beschreibung doch nicht von allen Personen im Projektteam auf gleicherweise verstanden wurde.

Mit einer grundlegenden Anforderungen an eine Aufgabe in einem Ticketsystem wird dies jedoch im besten Fall auf ein Mindestmaß reduziert. Gerade in größeren Projekten, bei denen die Anzahl der Aufgaben sehr schnell zunimmt, ist eine ordentliche Arbeit in den Tickets eine wichtige Grundlage, um die weitere Arbeit in einem guten Fluss zu halten.

Die folgenden Angaben sind aus meiner Erfahrung wichtig und müssen im Ticket eingetragen und angegeben werden:

Titel

Der Titel ist in der Regel der erste Berühungspunkt mit einer Aufgabe. Er sollte so ausführlich wie nötig, aber so kurz wie möglich angegeben werden. Der Vorteil bei einem kurzen prägnanten Titel liegt auf der Hand: Bei der Darstellung des Tickets in einem Scrum oder Kanban Board oder auch in den Suchergebnissen ist es viel einfacher die Tickets mit einem kurzen Titel zu erfassen, als wenn der Titel zu lang ist und es immer erst einen kurzen Moment braucht, um vollständig zu erfassen, was das eigentliche Thema das Tickets ist.

Typ

Die Angabe der Ticketart ist ebenfalls wichtig und gibt direkt Auskunft darüber, um welche Art Aufgabe es sich handelt. Hier ist nicht nur zwischen Story und Task zu unterscheiden. In Fehlerfällen ist auch wichtig, den Tickettyp Bug auszuwählen, um deutlich zu machen, dass hier ein Fehler vorliegt, der je nach schwere des Fehlers auch eine hohe Priorität in der Umsetzung bekommt.

Hier kann es auch noch weitere Arten, wie z.B. Change Request geben. Damit wird direkt für alle beteiligten deutlich, dass es sich hier um eine Änderung an geplanten oder bereits umgesetzten Funktionen handelt. Die Umsetzung dieser Änderungen hat entsprechende Aufwände zur Folge, die sich dann auch entsprechend auf das zur verfügungstehende Budget auswirken.

Components & Labels

Grunsätzlich helfen sowohl die Components als auch die Labels, um dem Ticket weitere Informationen zum Kontext zu geben, in welchem sich das Ticket befindet. Sind Components projektspezifisch und müssen bei Projektstart initial erstellt werden, stehen die Labels über die gesamte Jira-Instanz zur Verfügung und können somit in allen Projekten verwendet werden.

Für die Components können z.B. die einzelnen Gewerke oder Bereiche angelegt werden. Zusätzlich können den Components auch hauptverantwortliche Teammitglieder zugewiesen, um sicherzustellen, dass jeder im Projektteam auch direkt den richtigen Ansprechpartner kennt, wenn es Fragen zu gewissen Aufgaben gibt.

Labels hingegen sind als Tag oder Keyword zu verstehen, die projektübergreifend genutzt werden können. Bei der Erstellung von Labels ist unbedingt drauf zu achten, dass hier keine projekt- oder kundenspezifischen Informationen enthalten sind, da diese von allen Personen einzusehen sind. Ebenfalls ist auf eine richtige Schreibweise zu achten, um so zu vermeiden, dass ähnliche Tags zum gleichen Thema mehrfach angelegt werden:

  • Login vs. login
  • Database vs. DB
  • Auth vs. Authentication

Sowohl Components als auch Labels können für die Filterung von Aufgaben sowohl im Backlog als auch in der Board Ansicht verwendet werden.

Epic-Verknüpfung

Ein Epic ist, wie im Beitrag Die Unterschiede zwischen Epic, User Story und Task in Atlassian Jira beschrieben, ebenfalls eine User Story, die allerdings vom Umfang so groß ist, dass sie in mehrere kleinere Stories aufgeteilt werden muss. Auch wenn nicht jedes Projekt immer Epics beinhaltet, empfiehlt es sich doch, bei der Erstellung von einem Ticket zu prüfen, ob es nicht doch dafür ein Epic geben kann um den verschiedenen Aufgaben eine gewisse Struktur zu geben.

Beschreibung

Die Beschreibung des Tickets ist neben dem Titel die wichtigste Information, die in einem Ticket vorhanden sein muss. Die Beschreibung sollte so ausführlich wie möglich sein, um klar und deutlich zu beschreiben, was die Aufgabe ist und welche Anforderungen zur Umsetzung berücksichtigt werden müssen.

Allgemeine Grundregeln für die Beschreibung:

  • In der Beschreibung ist das gewünschte Verhalten beschrieben werden
  • Die Beschreibung ist so formuliert, dass es keine Missverständnisse gibt und das Ergebnis klar ist
  • Der Inhalt ist verständlich für alle beteiligten (z.B. Projektteam, Stakerholder, etc.)
  • Alle Anforderungen für die Umsetzung der Aufgabe sind erfasst
  • Keine Verwendung von unnötigen Prosa-Text

Erfolgt die konzeptionelle Planung und die Festlegung der notwendigen Anforderungskriterien in Confluence, ist unbedingt drauf zu achten, dass die entsprechende Confluence Seite mit dem jeweiligen Jira Ticket verknüpft wird. Die Beschreibung des Tickets kann in diesem Fall auf ein absolutes Mindesmaß reduziert werden, um Inhalte nicht doppelt anzulegen.

Beschreibung für Bugs

Die allgemeinen Grundregeln gelten auch für Bugs. Dennoch sind bei einem Fehler weitere Informationen anzugeben, damit der Fehler ohne großen Zeitverlust validiert und behoben werden kann.

  • Steps to Reproduce: Welche Schritte sind auszuführen, um den Fehler zu reproduzieren?
  • Expected Result: Was ist das gewünschte und erwartete Verhalten der Funktion?
  • Actual Result: Wechels Verhalten tritt stattdessen auf?
  • Workaround: Gibt es einen Workaround, um den Fehler zu umgehen?

Neben diesen Informationen sind je nach Fehler auch die folgenden Angaben wichtig und hilfreich, um den Fehler zu beheben:

  • Genaue URL und Seite, wo der Fehler auftritt.
  • Browser und genaue Version, die verwendet wird.
  • Screenshots, die das Fehlverhalten verdeutlichen.

Aufwände und Restaufwände

Sobald der Aufwand für eine Aufgabe geschätzt werden kann, ist dieser auch direkt im Ticket einzutragen, damit klar erkennbar ist, wieviel Zeit für die Fertigstellung der Aufgabe zur Verfügung steht bzw. wieviele Storypoints für die Aufgabe geschätzt worden sind. Während der Umsetzung der Aufgabe ist natürlich auf diese Zeit zu achten, so dass die Fertigstellung innerhalb dieser Zeitschätzung möglich ist. Da es sich jedoch nur um eine Schätzung handelt, kann es durchaus vorkommen, dass der tatsächliche Aufwand zur Fertigstellung von der ursprünglichen Schätzung abweicht.

Wenn für die Umsetzung mehr Zeit benötigt wird, als angenommen, so ist dies im Rahmen der Restaufwandsschätzung ebenfalls im Ticket einzutragen. So wird deutlich, wieviel Zeit noch für die Fertigstellung benötigt wird. Die Restaufwandsschätzung gilt unabhängig davon, ob die Schätzung in Story Points oder in tatsächlichen Zeitangaben erfolgt. Wird durch einen erhöhten Zeitaufwand die Aufgabe nicht wie geplant im Sprint fertig, ist der Restaufwand wichtig, um die Aufgabe im nächsten Sprint erneut einplanen zu können.

Fälligkeitsdatum

Der Zeitpunkt, bis wann die Aufgabe fertig umgesetzt werden soll, ist enbenfalls eine wichtige Information, die vom Projekt Manager im Ticket eingetragen werden muss. Ist die Aufgabe innerhalb eines Sprints geplant, gilt natürlich das Ende des Sprints als Fälligkeitsdatum. Wird die Aufgabe jedoch im Rahmen eines Kanban-Workflows umgesetzt, ist es hierfür natürlich ebenfalls wichtig, festzulegen, bis wann die Aufgabe fertig gestellt werden muss. Das Fälligkeitsdatum hat somit auch Auswirkungen auf die Reihenfolge im Product Backlog, in dem die Aufgaben nach Priorität sortiert werden.

Kommentare

Kommentare sind in der Bearbeitung einer Aufgabe zwischen mehreren beteiligten Personen sehr wichtig. Hier ist jedoch drauf zu achten, dass die Kommentarfunktion vor allem dann genutzt werden soll, wenn es für den Ticketverlauf wichtige Anmerkungen oder Fragen gibt. Ebenfalls ist drauf zu achten, dass vor allem bei einem Statuswechsel oder Zuweisung zu einer anderen Person ein kurzer Kommentar eingestellt werden soll, der kurz den aktuellen Stand beschreibt und der zugewiesenen Personklar und deutlich beschreibt, was in der weiteren Bearbeitung der Aufgabe als nächstes ansteht.

Vor allem im weiteren Projektverlauf ist es hilfreich, auf solche wichtigen Kommentare zurück greifen zu können, um zu sehen, welche Unklarheiten in der Vergangenheit beseitigt wurden oder welche Entscheidungen in der Umsetzung einer Aufgabe getroffen wurden. Nichts ist ärgerlicher, wenn hier nur Ticket Ping-Pong gespielt wurde, und das Ticket mehrmals zwischen Person A und Person B gewechselt ist, ohne eine nachvollziere Begründung in Form von kurzen Kommentaren zu sehen. Die Kommentarfunktion soll nach Möglichkeit aber auch nicht überstrapaziert werden, denn es ist gar nicht so einfach in sehr vielen Kommentaren den Überblick zu behalten. Hier gilt es ein gesundes Mindestmaß zu finden.

Zusätzlich ist es hilfreich, wenn wichtige Zwischenstände mit einem kurzen Kommentar beschrieben werden. Übernimmt die weitere Bearbeitung ein anderes Teammitglied, ist das Ticket mitsamt dem Kommentar die erste Anlaufstelle und kann wichtige Informationen weitergeben, die für die weitere Bearbeitung hilfreich sind.

Definition of Ready (DoR)

Die Definition of Ready legt fest, ab wann eine Aufgabe als ready markiert werden kann. Der Status verdeutlicht, dass die Arbeit an der Aufgabe beginnen kann, da alle Unklarheiten beseitigt und offene Fragen geklärt sind. Aufgaben im Backlog, die noch nicht ready sind, können nicht bearbeitet werden. Die DoR ist team- bzw. unternehmensspezifisch und muss gemeinschaftlich festgelegt werden. Eine DoR kann z.B. wie folgt zusammengestellt werden:

  • Die Aufgabe ist klein genug, damit sie in einem Sprint umgesetzt werden kann
  • Die Aufgabe ist für alle Beteiligten verständlich und alle offenen Fragen wurden geklärt
  • Die Aufgabe ist mit einem Aufwand geschätzt
  • Die Aufgabe beinhaltet Akzeptanzkritieren (mindestens 2)
  • Die Aufgabe hat einen Wert für das Projekt

Im Rahmen des Backlog Refinements prüft das Projekteam die Aufgaben im Product Backlog anhand dieser Kriterien. Die Aufgaben, die noch nicht ready sind, werden entsprechend ausgearbeitet, so dass sie für die Umsetzung ausgewählt werden können.

Die Definition of Done ist vorwiegend durch den Product Owner einzuhalten.

Definition of Done (DoD)

Die Definition of Done legt fest, ab wann eine Aufgabe als fertig markiert werden kann. Wie auch bei der Definition of Ready werden Kriterien festgelegt, die eingehalten werden müssen, damit eine Aufgabe als fertig markiert werden kann.

Eine Definition of Done kann beispielhaft wie folgt zusammengestellt werden:

  • Der Code ist fertig gestellt und versioniert
  • Es wurde ein Code Review durchgeführt bzw. der Code wurde im Pair Programming erstellt
  • Vom Team festgelegte Coding Guidelines wurden eingehalten
  • Alle Akzeptanzkriterien wurden erfüllt
  • Unit- oder Functional-Tests wurden erstellt und stehen auf grün
  • Die Dokumentation wurde erstellt bzw. auf den aktuellen Stand gebracht
  • Es sind keine kritischen Bugs enthalten

Die Definition of Done wird in der Regel vom Entwicklungsteam festgelegt. Arbeiten mehrere Teams in einem Product Backlog gilt es sicherzustellen, dass es eine unternehmensweite Defition of Done gibt, um sicherzustellen, dass die Arbeit aller Teams zusammengeführt und veröffentlich werden kann.

Eine einmal erstellte DoD kann sich mit der Zeit verändern, wenn neue Kriterien hinzukommen müssen, um die Qualität zu steigern. In der Restrospektive nach einem Sprint kann sich das Projekteam über die Vollständigkeit oder notwendige Anpassung der DoD austauschen und, sofern nötig, weitere Maßnahmen hinzufügen um die Qualität zu erhöhen. Die DoD gilt hier für alle Aufgaben gleichermaßen, und hat daher auch Auswirkungen auf den Zeitaufwand der benötigt wird, um eine Aufgabe fertig umzusetzen. Daher ist es umso wichtiger, dass die Kritierien, die in der DoD festgelegt sind, dem gesamten Team bekannt sind damit das Team auf dieser Basis besser entscheiden kann, welche Aufgaben in den nächsten Sprint eingeplant werden können.

Die Definition of Done ist hauptsächlich durch das Projektteam einzuhalten.

Fazit

Jira und andere Tools zum Projektmanagent bzw. Aufgabenverwaltung sind nur Tools und Software, die alleine nicht direkt helfen, die Aufgaben besser oder schneller bearbeiten zu können. Ganz im Gegenteil: Ohne eine gewisse Struktur und Vorgaben entsteht hier schnell ein unübersichtliches Chaos, welches dem Projekterfolgt schnell gefährlich werden kann. Welche Vorgaben es gibt, und wie diese ausgearbeitet sind, ist mit gewissen Anteilen unternehmens- und/oder team-spezifisch und lässt sich gar nicht so genau festlegen. Wichtig ist nur, dass es diese Vorgaben auch einzuhalten gilt, auch wenn das im turbulenten Projektalltag nicht immer ein leichtes Unterfangen ist.

Tags

Jira
Chris van Daele

Chris van Daele

Ich bin Fachinformatiker in der Fachrichtung Anwendungsentwicklung und arbeite aktuell als technischer Projekt Manager im Bereich E-Commerce und Individualentwicklung. Zum Profil