Jira-Beratung — Dashboards und Reporting

Jira-Dashboard und Reporting für die Projektsteuerung

Ein Jira-Dashboard ist erst dann etwas wert, wenn es eine konkrete Steuerungsfrage beantwortet — nicht, wenn es möglichst viele Diagramme zeigt. Ich richte gespeicherte Filter, Boards und Dashboards so ein, dass Geschäftsführung, PMO und Mitarbeitende auf einen Blick sehen, was ansteht, was überfällig ist und wo eine Entscheidung fehlt.

  • Steuerungsfragen zuerst festgelegt, danach Filter, Boards und Dashboards gebaut
  • Termintreue messbar: geplanter Termin als Baseline, getrennt vom operativen Fälligkeitsdatum
  • Kartenfarben und Schnellfilter zeigen Zustand, nicht nur Zugehörigkeit
  • Datenqualität als Voraussetzung: ohne Pflichtangaben bleibt jede Übersicht eine Lücke
Kontrollraum mit einer Bildschirmwand aus unscharfen, abstrakten Diagrammkacheln in Grau- und Goldtönen
Ausgangslage

Dashboards gibt es meistens schon. Steuern lässt sich damit trotzdem nicht.

In gewachsenen Jira-Instanzen existieren oft mehrere Dashboards nebeneinander — von unterschiedlichen Personen zu unterschiedlichen Anlässen gebaut, mit Gadgets, die einmal sinnvoll waren und heute niemand mehr abbestellt. Wer eine Frage zum Projektstand hat, öffnet trotzdem eine Tabelle oder ruft an.

Der Grund liegt selten am Werkzeug. Er liegt daran, dass die Frage, die ein Dashboard beantworten soll, nie klar formuliert wurde. Ein Diagramm ohne Steuerungszweck ist Dekoration — es sieht nach Überblick aus, ohne einen zu geben.

Dazu kommt ein zweites Problem, das jede Auswertung verzerrt: Wenn das Fälligkeitsdatum bei jeder Verschiebung einfach überschrieben wird, war am Ende jede Aufgabe pünktlich. Termintreue lässt sich nur messen, wenn der ursprünglich geplante Termin irgendwo unverändert stehen bleibt.

Deshalb steht vor jedem Filter und jedem Dashboard dieselbe Übung: klären, welche Entscheidung eine Übersicht ermöglichen soll — und erst danach festlegen, mit welchem Feld, welcher Farbe oder welchem Schnellfilter sie das tut.

Steuerungsfragen

Was ein Dashboard beantworten muss, bevor es gebaut wird.

Diese vier Fragen entscheiden über Feldwahl, Filterlogik und Aufbau. Ohne sie entstehen Diagramme, die zwar Daten zeigen, aber keine Entscheidung vorbereiten.

  • Was ist überfällig?

    Welche Vorgänge haben ein Fälligkeitsdatum in der Vergangenheit und sind noch nicht abgeschlossen. Die Grundfrage jeder Steuerung — und meistens die am schlechtesten beantwortete.

  • Was ist blockiert?

    Welche Vorgänge stehen still, weil eine Entscheidung, eine Zulieferung oder eine externe Freigabe fehlt. Blockade ist ein eigener Zustand, kein Status unter vielen — sonst verschwindet sie im allgemeinen „In Bearbeitung“.

  • Wo fehlt Verantwortung?

    Welche Vorgänge haben keine zuständige Person oder eine, die erkennbar nicht mehr passt. Ohne diese Frage bleibt jede Verzögerung anonym.

  • Welche Vorhaben laufen aus dem Plan?

    Welche Vorhaben weichen von ihrem geplanten Termin ab, wenn man Baseline und aktuelles Fälligkeitsdatum nebeneinanderlegt. Diese Frage trägt die gesamte Managementsicht.

Beispiel

So sieht eine Managementsicht aus

Managementsicht: sechs Fragen, sechs Kacheln
Fiktives Beispiel
  • Was ist diese Woche fällig?12VorgängeInfo
  • Was ist überfällig?4VorgängeHandeln
  • Wo fehlt eine Verantwortung?2VorgängeKlären
  • Was steht seit 10 Werktagen still?3VorgängeNachfassen
  • Welche Entscheidungen stehen an?5FreigabenTermin
  • Wie termintreu war der letzte Monat?8 von 10pünktlichIm Plan

Fiktives Beispiel mit erfundenen Daten. Vereinfachte Darstellung, kein Kundenprojekt und keine Originalansicht von Jira.

Leistungen

Was ich für Ihre Dashboards und Boards einrichte

  • Gespeicherte Filter (JQL)

    Steuerungsfragen werden als benannte, gespeicherte Filter hinterlegt — überfällig, blockiert, ohne Verantwortung, Plantermin überschritten. Wiederverwendbar für Boards, Dashboards und Benachrichtigungen.

  • Management-Dashboard für Geschäftsführung und PMO

    Wenige Kacheln, jede mit einer Steuerungsfrage statt einem Selbstzweck-Diagramm. Für die Wochenrunde gedacht, nicht für die tägliche Detailarbeit.

  • „Meine Arbeitspakete“ für Mitarbeitende

    Ein persönliches Dashboard mit den eigenen offenen, überfälligen und demnächst fälligen Vorgängen — die operative Gegenseite zur Managementsicht.

  • Boards mit Kartenfarben und Schnellfiltern

    Kartenfarbe zeigt Zustand (etwa überfällig oder blockiert), nicht nur Vorgangstyp oder Priorität. Schnellfilter blenden auf demselben Board gezielt Teilmengen ein, statt ein zweites Board zu bauen.

  • Swimlanes nach Vorhaben

    Wenn ein Board mehrere Vorhaben gleichzeitig trägt, sortieren Swimlanes danach — so bleibt der Fortschritt je Vorhaben erkennbar, statt in einer gemeinsamen Kartenwand unterzugehen.

  • Termintreue messbar machen

    Ein eigenes Baseline-Feld hält den geplanten Termin fest, getrennt vom operativen Fälligkeitsdatum. Der Plantermin wird beim Abschluss nicht überschrieben — nur so zeigt eine Auswertung tatsächliche Verschiebungen.

JQL-Beispiele

So sehen die gespeicherten Filter aus

Vier fiktive Filter für das erfundene Beispielprojekt „KUP“ — syntaktisch korrekt, aber ohne Bezug zu einer echten Jira-Instanz. Feldnamen und Projektschlüssel weichen bei Ihnen ab.

Überfällig, aber noch offen
Fiktiv
project = KUP AND statusCategory != Done AND duedate < startOfDay() ORDER BY duedate ASC

Setzt ein gepflegtes Fälligkeitsdatum voraus. Ohne dieses Pflichtfeld liefert der Filter nur einen Ausschnitt der Wahrheit.

Blockiert und ohne Bewegung
Fiktiv
project = KUP AND status = "Blockiert" AND updated <= -5d ORDER BY updated ASC

Zeigt Vorgänge im eigenen Blockade-Status, an denen seit fünf Werktagen nichts passiert ist — der typische Kandidat für eine Eskalation.

Ohne zuständige Person
Fiktiv
project = KUP AND statusCategory = "In Progress" AND assignee is EMPTY

Vorgänge in Bearbeitung ohne zugewiesene Person. Ein Feld, das eigentlich beim Statuswechsel Pflicht sein sollte.

Plantermin überschritten (Baseline vs. Fälligkeit)
Fiktiv
project = KUP AND "Plantermin" is not EMPTY AND duedate > "Plantermin"

Vergleicht ein eigenes, unveränderliches Baseline-Feld mit dem operativen Fälligkeitsdatum. Nur so lässt sich eine Verschiebung überhaupt erkennen, statt sie stillschweigend zu überschreiben.

Beispiel

Wie eine Vorhaben-Übersicht aus denselben Feldern entsteht

Welche Projekte brauchen Aufmerksamkeit?
Fiktives Beispiel
  • KundenportalTest läuft
    Verantwortung
    Projektleitung
    Offenes Hindernis
    Testzugänge fehlen
    Nächster Schritt
    Zugänge mit der IT klären
  • WissensdatenbankIn Bearbeitung
    Verantwortung
    Fachbereich
    Offenes Hindernis
    Kein Hindernis gemeldet
    Nächster Schritt
    Pilotinhalte prüfen
  • FreigabeprozessAbstimmung offen
    Verantwortung
    Noch zu klären
    Offenes Hindernis
    Entscheidung ohne zuständige Person
    Nächster Schritt
    Verantwortung festlegen

Fiktives Beispiel mit erfundenen Daten. Vereinfachte Darstellung, kein Kundenprojekt und keine Originalansicht von Jira.

Voraussetzung

Ein Dashboard ist nur so ehrlich wie die Daten dahinter.

Jedes Dashboard und jeder Filter greift auf Felder zu, die jemand ausfüllen muss. Fehlt das Fälligkeitsdatum, zeigt der Überfällig-Filter zu wenig an. Bleibt die zuständige Person leer, verschwindet die Verantwortung aus jeder Auswertung. Diagramme werden dadurch nicht falsch — sie werden unvollständig, und das sieht man ihnen nicht an.

Deshalb gehört die Festlegung von Pflichtangaben zur Dashboard-Arbeit dazu, nicht davor: Welche Felder muss ein Vorgang beim Anlegen oder beim Statuswechsel tragen, damit die vereinbarten Filter überhaupt etwas Verlässliches zeigen. Das betrifft insbesondere Fälligkeitsdatum, zuständige Person und die Zuordnung zum übergeordneten Vorhaben.

Diese Pflichtangaben werden an denselben Stellen durchgesetzt, an denen Ihr Team ohnehin arbeitet — über Maskenfelder und Übergangsbedingungen im Workflow, nicht über eine zusätzliche Kontrollliste, die niemand pflegt.

Ablauf

Von der Steuerungsfrage zum fertigen Dashboard

Sechs Schritte, in denen Filter, Boards und Dashboards aus denselben abgestimmten Feldern entstehen.

  1. Schritt 01

    Steuerungsfragen klären

    Mit Geschäftsführung, PMO und den Teams besprechen, welche Entscheidungen ein Dashboard vorbereiten soll — überfällig, blockiert, ohne Verantwortung, abweichende Vorhaben.

  2. Schritt 02

    Datenqualität prüfen

    Welche Felder heute fehlen oder unzuverlässig gepflegt sind, insbesondere Fälligkeitsdatum, Zuständigkeit und Zuordnung zum Vorhaben.

  3. Schritt 03

    Baseline-Feld für den Plantermin einrichten

    Ein eigenes Feld hält den ursprünglich geplanten Termin fest, getrennt vom operativen Fälligkeitsdatum, und wird beim Abschluss nicht überschrieben.

  4. Schritt 04

    Gespeicherte Filter bauen

    Jede Steuerungsfrage wird als benannter, gespeicherter Filter hinterlegt und mit dem betroffenen Team abgestimmt.

  5. Schritt 05

    Boards, Kartenfarben, Schnellfilter, Swimlanes

    Die Filter fließen in Boards ein: Zustand über Kartenfarbe, gezielte Teilmengen über Schnellfilter, Vorhaben über Swimlanes.

  6. Schritt 06

    Dashboards zusammenstellen und testen

    Managementsicht und „Meine Arbeitspakete“ entstehen aus denselben Filtern. Ein Nutzertest mit Nicht-Admins prüft, ob die Kacheln verständlich sind und die Filter tatsächlich das zeigen, was sie sollen.

Passt das zu Ihnen?

Wann sich Dashboards und Reporting lohnen und wann nicht

Das passt, wenn …

  • In der Wochenrunde werden Projektstände noch mündlich zusammengetragen
  • Ein Fälligkeitsdatum existiert, wird aber bei jeder Verschiebung einfach überschrieben
  • Es gibt bereits Dashboards, aber niemand verlässt sich mehr auf sie
  • Verantwortlichkeiten für einzelne Vorgänge sind im Zweifel unklar

Das passt eher nicht, wenn …

  • Es fehlt noch ein grundlegender, funktionierender Ablauf mit Status und Pflichtfeldern
  • Gesucht wird ein fertiges Standard-Dashboard ohne Abstimmung der Steuerungsfragen
  • Es geht um eine einzelne Kennzahl für eine einmalige Präsentation
  • Die Zuständigkeiten für Jira als Werkzeug sind im Haus selbst noch ungeklärt

Wenn Sie unsicher sind, klären wir das im Erstgespräch.

FAQ

Häufige Fragen zu Jira-Dashboards und Reporting

  • Als Ausgangspunkt oft schon, als Steuerungsinstrument selten. Ein Standard-Dashboard zeigt, was das jeweilige Gadget kann — nicht zwingend, was Ihre Geschäftsführung oder Ihr PMO tatsächlich entscheiden muss. Deshalb steht die Steuerungsfrage am Anfang, und das Dashboard wird darauf zugeschnitten.

  • Der geplante Termin eines Vorgangs wird in einem eigenen Feld festgehalten, sobald er feststeht, und bleibt dort unverändert liegen — das ist die Baseline. Das operative Fälligkeitsdatum darf sich im Projektverlauf ändern. Erst der Vergleich beider Felder zeigt, ob und wie stark sich ein Termin verschoben hat.

  • Weil er dann seinen Zweck verliert. Eine Baseline, die bei jeder Verzögerung nachgezogen wird, zeigt am Ende ausschließlich pünktliche Vorgänge — unabhängig davon, wie oft ein Termin tatsächlich verschoben wurde. Der Plantermin wird einmal gesetzt und danach nur in begründeten, dokumentierten Ausnahmen geändert.

  • Am wichtigsten sind ein gepflegtes Fälligkeitsdatum, eine eindeutige zuständige Person und die Zuordnung zum übergeordneten Vorhaben. Fehlt eines dieser Felder, zeigt der passende Filter zu wenig oder verzerrt an, ohne dass man es dem Dashboard ansieht. Welche weiteren Felder je Vorgangstyp sinnvoll sind, klären wir im Audit anhand Ihrer tatsächlichen Steuerungsfragen.

  • Ja, über Swimlanes je Vorhaben und Schnellfilter je Team oder Zustand auf demselben Board. Wichtig ist, dass die Kartenfarbe für alle Beteiligten denselben Zustand bedeutet, etwa überfällig oder blockiert, und nicht je Team unterschiedlich ausgelegt wird. Sonst wirkt ein gemeinsames Board schnell überladen statt übersichtlich, und niemand verlässt sich mehr darauf.

  • Nein, sie sind fiktiv und dienen der Veranschaulichung der Syntax anhand eines erfundenen Beispielprojekts. Feldnamen, Projektschlüssel und Statuswerte weichen in jeder Jira-Instanz voneinander ab, deshalb lassen sie sich nicht unverändert übernehmen. Die tatsächlichen Filter entstehen im Projekt anhand Ihrer eigenen Felder, Status und Steuerungsfragen aus dem Audit.

  • Ein Dashboard zeigt einen Zustand, wenn jemand aktiv hinschaut, etwa in der Wochenrunde. Eine Automatisierung kann zusätzlich von sich aus auf einen Zustand hinweisen, etwa mit einer Frühwarnung kurz vor einer Fälligkeit, ohne dass jemand das Dashboard öffnen muss. Beides beruht auf denselben Feldern und denselben Filtern, deshalb stimme ich sie aufeinander ab.

  • Für die Ersteinschätzung reichen ein paar Sätze zu Ihrer aktuellen Ausgangslage und den Fragen, die Ihr Dashboard beantworten soll. Zugänge zu Ihrer Jira-Instanz, Passwörter oder API-Token gehören nicht in ein Kontaktformular und werden erst nach Beauftragung über einen gesonderten, abgestimmten Weg eingerichtet.

Nächster Schritt

Welche Frage soll Ihr nächstes Dashboard beantworten?

Im Erstgespräch klären wir, welche Steuerungsfragen für Geschäftsführung, PMO und Teams tatsächlich relevant sind, wie es um die Datenqualität dahinter steht und ob ein Klarheits-Audit oder ein direkter Pilot der sinnvollere nächste Schritt ist. 30 Minuten, unverbindlich.

Dashboard anfragen

Zwei Sätze zu Ihrer Steuerungsfrage genügen.

Beschreiben Sie kurz, welche Übersicht Ihnen heute fehlt und wer sie braucht. Den Rest klären wir im Erstgespräch. Bitte keine Zugangsdaten senden.

  • Timo RüdigerPersönliche Begleitung durch Timo Rüdiger
  • Unverbindliche Anfrage
  • Förderprüfung möglich

Lieber direkt Kontakt aufnehmen?

* Pflichtfeld

Ohne das optionale Häkchen verwenden wir Ihre Angaben nur zur Bearbeitung Ihrer Anfrage. Eine Weitergabe zu Werbezwecken an Dritte findet nicht statt.

Jira, Confluence und Rovo sind Marken der Atlassian Corporation. Keine Partnerschaft mit Atlassian.

ErstgesprächAnrufenWhatsApp(öffnet WhatsApp in neuem Tab)