So visualisiert ihr den Projektstatus in Jira

Dashboards und Visualisierungen in Jira

Wir haben zahlreiche Jira-Schulungen durchgeführt, und eines meiner Lieblingsthemen sind Visualisierungen und Dashboards. Ein wichtiger Punkt, den ich immer betone: Sie lassen sich sowohl auf individueller Ebene als auch für Teams erstellen. Ihr müsst keine Jira-Administratoren sein, um wirklich nützliche Visualisierungen zu erstellen. Wenn ihr oder euer Team keine eigenen Dashboards erstellt, verpasst ihr also etwas. Der erste Schritt zur Verbesserung ist das Messen.

Um euch den Einstieg zu erleichtern, stellen wir einige Gadgets vor, mit denen wir unseren Kunden helfen, ihre Arbeitsweise zu verbessern.

Den Aufgabenfriedhof aufräumen

In „Making Work Visible“ empfiehlt Dominica DeGrandis, regelmäßig die ältesten Aufgaben zu prüfen und sie entweder zu priorisieren oder zu entfernen.

Der folgende Filter hilft euch, die Anzahl veralteter Issues im Backlog zu messen. Mit dem folgenden JQL findet ihr ungelöste Issues, die in den letzten zwei Jahren nicht aktualisiert wurden, oder eine leere Beschreibung haben und seit einem Jahr nicht verschoben wurden. Diese Issues schaffen keinen Mehrwert. Andernfalls hätte jemand einen Kommentar hinzugefügt, um nach einem Update zu fragen. Sie sind nur Ballast und sollten gelöscht werden.

resolution = Unresolved AND ((description is EMPTY AND updated <= -365d) OR (updated <= -730d))

Ihr könnt dies an die Kriterien anpassen, die ihr verwenden möchtet. Wir haben Kunden gesehen, die eine Standard-Platzhalterbeschreibung nutzen, um an GIVEN-WHEN-THEN-Szenarien oder „as a developer I want to ….“ zu erinnern. In diesem Fall müsst ihr auch danach suchen, um alle veralteten Issues zu erfassen.

Zusätzlich ist es sinnvoll, in allen Fällen nach einer leeren Beschreibung zu suchen:

resolution = Unresolved AND description is EMPTY

Das Epic-Duell

Epics sind in Jira etwas Besonderes. Sie verhalten sich anders und werden in der Backlog-Ansicht anders dargestellt. Deshalb vergessen viele Nutzer, dass Epics genauso Issues sind wie Stories und Aufgaben. Wenn alle Aufgaben eines Epics abgeschlossen sind, markieren wir es im Epics-Panel des Backlogs als erledigt und vergessen es. Aus irgendeinem Grund wird dadurch das Epic-Issue jedoch nicht tatsächlich geschlossen.

Die folgende JQL-Abfrage zeigt euch die nicht geschlossenen Epics, die im Backlog nicht mehr sichtbar sind und in Vergessenheit geraten sind:

issuetype = epic AND "Epic Status" = Done AND resolution = Unresolved

In Bearbeitung, aber nicht wirklich

Zu wissen, was in Bearbeitung ist, sollte eine einfache Aufgabe sein. Bei Arbeit „in Bearbeitung“ wird erwartet, dass sie bald abgeschlossen wird – wobei „bald“ in Unternehmen unterschiedlich definiert sein kann. Es gibt jedoch einige häufige Fallstricke.

Ein Issue kann „in Bearbeitung“ sein, ohne dass etwas daran passiert. Das ist oft ein Zeichen dafür, dass die Arbeit nicht klar genug beschrieben wurde, der Verantwortliche zu viel Multitasking betreibt oder etwas blockiert ist. Issues in Bearbeitung sollten regelmäßig aktualisiert, idealerweise abgeschlossen und geschlossen werden. Ist das nicht der Fall, sollten wir untersuchen, warum. Die folgende Abfrage zeigt euch Issues, die in Bearbeitung sind, aber in der letzten Woche nicht aktualisiert wurden:statusCategory = “In Progress” AND updated <= -7d

Arbeitsprioritäten können sich ändern. Wenn wir aber vergessen, unser Issue-Tracking aufzuräumen, stellen wir keine aktuellen Informationen bereit.

Eine offensichtliche Aussage zu Issues in Bearbeitung ist, dass jemand daran arbeiten sollte. Andernfalls sollten sie nicht als in Bearbeitung gelten. Dieses JQL zeigt euch Issues, die in Bearbeitung, aber nicht zugewiesen sind:

assignee is EMPTY AND statusCategory = "In Progress"

Bei der Arbeit in einem Scrum-Umfeld wurden Aufgaben möglicherweise aus einem Sprint entfernt, nachdem die Arbeit daran begonnen hatte. Oder es gibt Aufgaben im abschließenden Sprint, die ins Backlog statt in den nächsten Sprint verschoben wurden. Das folgende JQL zeigt euch Issues, die in Bearbeitung, aber nicht in einem aktiven Sprint sind:

resolution = Unresolved AND Sprint not in openSprints() AND statusCategory = "In Progress"

Die oben genannten Abfragen könnt ihr als Filter speichern und mit project in (proj-1, proj-2) oder project = proj-1 auf bestimmte Projekte beschränken.

Wir haben sehr gute Erfahrungen damit gemacht, diese Hindernisse im Projektmanagement zu visualisieren. Auf einem großen Bildschirm werden sie beachtet und priorisiert. Die wichtigste Erkenntnis: Habt keine Angst vor dem Backlog. Es ist nicht die schreckliche Aufgabe, für die ihr es haltet. Mit diesen Abfragen, Dashboards und Filtern könnt ihr die Unordnung in eurem System deutlich reduzieren, ohne euch dabei die Hände schmutzig zu machen.