Ein Jira-Dashboard ist schnell angelegt. Ein paar Kreisdiagramme, eine Liste der zuletzt erstellten Vorgänge, fertig. Nach drei Wochen schaut es niemand mehr an. Vor der Projektbesprechung pflegt dann wieder jemand eine Tabelle von Hand.
Meist stimmt die Reihenfolge nicht. Wer ein Jira-Dashboard erstellen will, das die Geschäftsführung tatsächlich nutzt, beginnt nicht bei den Gadgets. Die Reihenfolge lautet: Steuerungsfragen, dann Filter, dann Dashboard.
Schritt 1: Die Steuerungsfragen festlegen
Eine Geschäftsführung braucht keine Übersicht über alle Vorgänge. Sie braucht Antworten auf wenige Fragen, die sie jede Woche stellt. Typisch sind diese fünf:
- Was ist überfällig? Welche Arbeit hat ihren Termin überschritten und ist noch nicht erledigt?
- Was wird in den nächsten Tagen kritisch? Wo droht ein Termin zu reißen, solange man noch gegensteuern kann?
- Was steht still? Welche Arbeit ist blockiert oder hat sich lange nicht bewegt?
- Was gehört niemandem? Wo fehlen Verantwortliche oder Termine?
- Halten wir unsere Zusagen? Wie viel Arbeit wurde zum ursprünglich geplanten Termin fertig?
Schreiben Sie Ihre eigenen Fragen auf, bevor Sie etwas in Jira anlegen. Stimmen Sie sie mit den Menschen ab, die das Dashboard nutzen sollen. Jede Frage, die niemand stellt, wird später ein Diagramm, das niemand liest.
Ein Grundsatz gehört dazu: Das Dashboard zeigt Projekte und Vorhaben, keine Ranglisten einzelner Personen. Wer Mitarbeitende über Jira vergleicht, bekommt geschönte Daten statt ehrlicher Stände.
Schritt 2: Aus jeder Frage einen Filter machen
Jede Steuerungsfrage wird zu einem gespeicherten Filter in JQL, der Abfragesprache von Jira. Die folgenden Beispiele verwenden einen fiktiven Projektschlüssel DEMO. Die Status „Blockiert“ und „Pausiert“ sind ebenfalls Beispiele und müssen in Ihrem Workflow existieren.
Überfällig:
project = DEMO AND duedate < startOfDay() AND statusCategory != Done ORDER BY duedate ASC
startOfDay() statt now(), damit heute fällige Vorgänge nicht schon am Vormittag als überfällig gelten: Erst wenn der Tag vorbei ist, an dem ein Termin lag, gilt er als gerissen.
Fällig in den nächsten fünf Tagen:
project = DEMO AND duedate >= startOfDay() AND duedate <= endOfDay("+5d") AND statusCategory != Done ORDER BY duedate ASC
Blockiert oder pausiert:
project = DEMO AND status in ("Blockiert", "Pausiert") ORDER BY updated ASC
Stillstand seit zwei Wochen:
project = DEMO AND statusCategory = "In Progress" AND updated <= -14d ORDER BY updated ASC
Ohne Verantwortlichen oder ohne Termin:
project = DEMO AND statusCategory != Done AND (assignee is EMPTY OR duedate is EMPTY)
Ein Hinweis zu statusCategory: Die Abfrage nach der Statuskategorie ist robuster als eine Liste einzelner Status. Sie funktioniert nur, wenn jeder Status der richtigen Kategorie zugeordnet ist. Steht ein Status „Wartet auf Kunde“ in der Kategorie „Erledigt“, fehlt diese Arbeit in allen Filtern. Das ist einer der häufigsten Fehler, die ich in gewachsenen Umgebungen sehe. Mehr dazu steht im Beitrag Jira aufräumen: 8 Anzeichen für Wildwuchs.
Speichern Sie die Filter mit klaren Namen, etwa „GF · Überfällig”, und teilen Sie sie mit der passenden Gruppe. Nur geteilte Filter lassen sich in einem Dashboard für andere anzeigen.
Wer solche Filter anlegen und ändern darf und wie Sie verhindern, dass jeder Projektadministrator eigene, widersprüchliche Management-Filter baut, regelt die Seite zu Schulung und Governance für Jira-Automatisierungen.
Schritt 3: Termintreue messbar machen
Die fünfte Frage ist die schwierigste. In vielen Jira-Umgebungen lässt sie sich gar nicht beantworten, und zwar aus einem einfachen Grund: Wenn ein Termin verschoben wird, überschreibt jemand das Fälligkeitsdatum. Am Ende sieht jeder Vorgang pünktlich aus, weil der Termin mitgewandert ist.
Die Lösung ist ein zweites Datumsfeld, das ich „Plantermin (Basis)“ nenne. Es funktioniert so:
- Beim Start der Arbeit kopiert eine Automationsregel das Fälligkeitsdatum einmalig in den Plantermin. Danach ist das Feld für normale Nutzer nicht mehr bearbeitbar.
- Das Fälligkeitsdatum bleibt der aktuelle, bewegliche Termin. Es darf sich ändern, wenn sich die Lage ändert.
- Beim Abschluss vergleicht eine zweite Regel das Erledigungsdatum mit dem Plantermin und setzt eine Kennzeichnung, zum Beispiel das Label
termin-gehaltenodertermin-verfehlt.
Warum der Umweg über eine Kennzeichnung? JQL kann zwei Felder desselben Vorgangs nicht direkt miteinander vergleichen. Eine Abfrage wie „erledigt nach Plantermin“ ist in Standard-JQL nicht möglich. Die Automation übernimmt diesen Vergleich beim Abschluss, der Filter fragt danach nur noch die Kennzeichnung ab:
project = DEMO AND statusCategory = Done AND resolved >= startOfMonth(-1) AND resolved < startOfMonth() AND labels = termin-verfehlt
Diese Abfrage zeigt alle Vorgänge des Vormonats, die nach dem ursprünglich geplanten Termin fertig wurden. Mit einem zweiten Filter für termin-gehalten ergibt sich die Quote.
Bedenken Sie: Die Termintreue ist erst ab dem Zeitpunkt messbar, ab dem das Feld gefüllt wird. Für Altbestand gibt es keine verlässliche Basis. Planen Sie deshalb einige Wochen ein, bevor die Kennzahl aussagekräftig ist.
Schritt 4: Das Dashboard zusammensetzen
Erst jetzt kommt das Dashboard. Für eine Managementsicht reichen meist wenige Bausteine:
- Filterergebnisse für „Überfällig“ und „Fällig in fünf Tagen“, jeweils mit Spalten für Vorhaben, Verantwortung und Termin.
- Eine zweidimensionale Filterstatistik für „Blockiert oder pausiert“, aufgeteilt nach Projekt und Status.
- Eine Zahl oder ein Kreisdiagramm für die Termintreue des Vormonats.
- Eine Liste für „Ohne Verantwortlichen oder Termin“, damit Lücken sichtbar bleiben.
Ordnen Sie die Bausteine in der Reihenfolge der Steuerungsfragen an. Wer das Dashboard öffnet, soll von oben nach unten lesen können: Was brennt, was droht, was steht, was fehlt, wie gut waren wir.
Ein Dashboard mit vier Bausteinen, das jede Woche benutzt wird, ist wertvoller als eines mit zwölf, das niemand öffnet.
Schritt 5: Dafür sorgen, dass die Daten stimmen
Das beste Dashboard zeigt nur, was in den Vorgängen steht. Wenn Termine leer bleiben oder Verantwortliche fehlen, liefert es leere oder falsche Listen. Drei Voraussetzungen gehören deshalb dazu:
- Pflichtangaben beim Start der Arbeit, damit Verantwortung und Termin gesetzt sind.
- Ein klarer Status für Blockaden, damit stillstehende Arbeit nicht in „In Arbeit“ versteckt ist.
- Eine Frühwarnung vor Fälligkeit, damit die Verantwortlichen selbst reagieren, bevor der Vorgang im Dashboard rot wird.
Wie das im Workflow umgesetzt wird, beschreibe ich im Beitrag Jira-Workflow mit Pflichtfeldern und Frühwarnung. Für die Automationsregeln rund um Plantermin und Frühwarnung lohnt vorher ein Blick auf die neue Abrechnung: Jira-Automation ab 3. Dezember.
Und was ist mit der Geschäftsführung selbst?
Die Geschäftsführung sollte das Dashboard lesen, aber keine operativen Meldungen bekommen. Benachrichtigungen über einzelne Vorgänge gehören an die Verantwortlichen und an die Teamleitung. Wer die Geschäftsführung mit Einzelmeldungen versorgt, erzeugt eine Mailflut, die nach kurzer Zeit ungelesen bleibt. Eine Ausnahme kann eine kurze Wochenübersicht sein, die den Link zum Dashboard enthält.
Wie ich Steuerungsfilter, Management-Dashboards und Boards aufbaue und Termintreue messbar mache, steht ausführlich auf der Seite zu Jira-Dashboards.
Häufige Fragen
Wie viele Filter braucht ein Management-Dashboard?
Meist reichen fünf bis sieben gespeicherte Filter aus, jeder beantwortet genau eine Steuerungsfrage wie überfällig, blockiert oder ohne Verantwortung. Brauchen Sie deutlich mehr, sind die Fragen selbst vermutlich noch nicht klar genug abgegrenzt. Weniger, aber eindeutig benannte Filter lassen sich außerdem leichter für Boards und Dashboards wiederverwenden.
Kann Jira die Termintreue nicht selbst berechnen?
Nicht ohne Vorarbeit. JQL kann zwei Datumsfelder desselben Vorgangs nicht direkt vergleichen, und das aktuelle Fälligkeitsdatum wird bei jeder Verschiebung überschrieben. Mit einem zusätzlichen, unveränderlichen Plantermin und einer Automationsregel, die beim Abschluss vergleicht und eine Kennzeichnung setzt, lässt sich die Termintreue anschließend über einen einfachen Filter zuverlässig auswerten.
Sollte jedes Projekt ein eigenes Dashboard haben?
Für die Geschäftsführung ist ein gemeinsames Dashboard über alle Projekte sinnvoller, damit sich Projektstände ohne Wechsel vergleichen lassen. Einzelne Teams können daneben eigene Boards und Dashboards für ihre tägliche Arbeit nutzen, solange diese auf denselben gespeicherten Filtern und Steuerungsfragen aufbauen. So entstehen keine widersprüchlichen Zahlen zwischen Management- und Teamsicht.
Ihr nächster Schritt
Sie möchten ein Dashboard, das Ihre Projektbesprechung vorbereitet statt sie zu ersetzen? Im kostenlosen 30-Minuten-Erstgespräch klären wir, welche Fragen Ihre Übersicht beantworten muss und ob Ihre Daten dafür bereit sind.
Jira, Confluence und Rovo sind Marken der Atlassian Corporation. Keine Partnerschaft mit Atlassian.

Timo Rüdiger
Inhaber, Der Rüdiger Consulting
Über 25 Jahre unternehmerische Praxis in Führung, Marketing und Vertriebssteuerung. Ich schreibe hier über die Themen, die ich in meinen Beratungsmandaten tatsächlich bearbeite, keine zusammengefassten fremden Studien.
Mehr über michKlingt das nach Ihrer Situation?
Im kostenlosen Erstgespräch klären wir in 30 Minuten, wo Ihre größten Hebel liegen, unverbindlich und ohne Verkaufsdruck.
Kostenloses Erstgespräch buchen