Vorwort

Ich berate nun seit einigen Jahren Konzerne im agilen Kontext. Dabei habe ich mich zum Jira-Admin-und-Berater gewandelt, gezwungenermaßen. Ich habe in mehreren Unternehmen und Teams Jira eingeführt und werde meine best Practices hier immer mal wieder berichten. Dazu vielleicht eine Anmerkung: Ich glaube an die Kraft und Effizienz der "neuen" PM-Tools wie Monday, Asana und Co. Nur leider ist es diesen Anbietern, zumindest in meiner persönlichen Empirie, noch nicht gelungen im Konzernumfeld wirklich anzukommen. Was ich da vorfinde, ist immer: Jira und Confluence. Und dann ist es das Beste, was zur Verfügung steht, um Transparenz zu schaffen.

Und immer wieder: die nervigen Jira Subtasks

Wenn Teams "einfach so anfangen", mit Jira zu arbeiten, dann benutzen sie oft Subtaks. Das sind die Issues, die aussehen wie Tasks, aber in der Hierarchie unterhalb eines Tasks oder einer Story angesiedelt sind. Dann passiert Folgendes:

• Die Default Jira Board Konfiguration macht Storys oder Tasks zu Swimlanes
• Das Einzige, was dann von rechts nach links geschoben wird, sind die Subtasks

Aus Jira Storys oder Tasks werden Epics

Daraus ergeben sich aber sehr grundlegende Probleme und eine Kausalkette:

• Meistens werden die Storys oder Tasks viel zu groß: Weil die Subtasks die "Kärtchen" sind, die nach rechts geschoben werden, haben sie bald die Größe von Storys oder Tasks. Damit werden diese faktisch zu Epics.
• Daraufhin werden die Tasks oder Storys in einem Sprint nicht fertig - denn: Eine Story / Task gilt nur dann als fertig, wenn alle Subtasks fertig sind.
• Die Sprintplanung wird unübersichtlich, denn in der Backlogansicht schiebt man Storys oder Tasks hin- und her, keine Subtasks. Im Zweifel sieht man nicht mal, wie viele Subtasks darunter sind und kann die Größe nicht mehr einschätzen.

Im agilen Kontext ist das also erstmal schlecht. Und Jira hat sich das so auch nicht vorgestellt. Was also kann man tun?

Wie Checklisten Items helfen, Jira Subtask zu vermeiden

Die erste Reaktion, die viele haben, ist diese: Wir stellen unseren Boardfilter auf Query (JQL) um, und versuchen den Issuetype Subtask nicht mitzuberücksichtigen. Kann man machen, macht es aber auch komplex, denn: Es gibt Situationen, in denen die Subtasks wirklich Sinn machen. Die erscheinen dann nicht mehr.

Die beste Lösung sind Checklisten. Checklisten gibt es als Marketplace Apps im Atlassian Store. Nun ist es so, dass Apps normalerweise sehr, sehr teuer sind und es oft eine unternehmensweite Entscheidung sein sollte, diese zu kaufen. Es gibt aber auch freie Apps, z.B. die Issue Checklist (for free), oder die Checklist for Jira Cloud. Ich habe mit beiden schon erfolgreich gearbeitet und kann sie guten Gewissens empfehlen. Was ist der Vorteil zwischen Jira Checklisten gegenüber Jira Subtasks?

• In den Checklisten kannst du auch Namen (mit @mention), Datum, Status (nur letztere App) vermerken.
• Sie tauchen aber nie im Board auf,
• wenn also mehre Entwickler oder Teammitglieder an einer Story arbeiten, so können die Tasks aus dem Task-Breakdown noch immer in Checklisten-Items verpackt werden,
• aber: die gesamte Story verbleibt im gleichen Status und verteilt sich nicht über die Subtasks auf das gesamte Board.

‍

Ich habe das nun bei mehreren Teams eingeführt, und es hat sich bewährt.

‍

‍