Wo staut sich die Arbeit? Ein Flussbericht braucht mehr als eine Auftragszahl

Eine aktuelle Aufgabenübersicht zeigt, wo Arbeit jetzt liegt. Sie erklärt nicht, ob die Prüfliste seit Wochen wächst oder erst heute Morgen voll geworden ist. Wenn Sie erkennen möchten, wo sich Arbeit ansammelt, benötigen Sie eine historische Flussauswertung mit klarer Auswahl und Phasenzuordnung statt einer größeren Kennzahl „offene Aufträge“.

Ein kumulatives Flussdiagramm kann diese Untersuchung unterstützen. Es ist weder eine persönliche Leistungsnote noch ein zugesagter Fertigstellungstermin. Auch beweist das breiteste Band nicht, dass die dort zuständigen Menschen die Verzögerung verursacht haben.

Bestand und Abschluss nicht verwechseln

In einem fiktiven Designstudio durchlaufen Anfragen etwa Vorbereitung, Prüfung und Übergabe. Der Bestand in der Prüfung beschreibt die wartende Arbeit zu einem bestimmten Zeitpunkt. Abgeschlossene Übergaben innerhalb eines Zeitraums sind eine andere Größe. Verwenden Sie dafür nicht dieselbe Beschriftung.

Die Jira-Cloud-Anleitung von Atlassian beschreibt Zeit auf der waagerechten Achse, Vorgänge auf der senkrechten und farbige Flächen für die Workflow-Status. Eine über die Zeit senkrecht breiter werdende Fläche weist demnach im Allgemeinen auf einen Engpass in der zugehörigen Spalte hin. Das ist ein Anlass zum Nachsehen, keine fertige Ursachenanalyse.

Vielleicht treffen mehr Aufträge ein, vielleicht fehlen Rückfragen oder eine nachgelagerte Übergabe ist blockiert. Aus dem Bild allein ergibt sich die Ursache nicht. Bestimmen Sie, wer die betroffenen Vorgänge untersucht, bevor Personal anders eingesetzt oder Kunden etwas versprochen wird.

Erst die Auswahl, dann die Farben

Laut Atlassian gilt die Auswertung für ein bestimmtes Board und dessen gespeicherten Filter. Auch die Spaltenzuordnung ist maßgeblich: Die äußerste linke und rechte Spalte bestimmen die Positionen To Do und Done. Die Berichtskonfiguration gehört damit zur Aussage und ist nicht bloß Gestaltung.

Benennen Sie für Ihre App Leistung, Team und Vorgangsart. Gehören ungeprüfte Anfragen in denselben Fluss wie verbindlich angenommene Aufträge? Ein großer Bestand unverbindlicher Eingänge darf nicht unbemerkt als zugesagte Produktionsarbeit erscheinen.

Definieren Sie die Zähleinheit. Ein Hauptauftrag mit mehreren Unteraufgaben soll nicht plötzlich als mehrere Kundenanfragen zählen, nur weil jemand die Ansicht wechselt. Werden Vorgänge bewusst geteilt oder zusammengeführt, braucht deren Wirkung eine vereinbarte Erklärung. Das sind Anforderungen an Ihre Auswertung, keine durch die Jira-Anleitung belegten Funktionen.

Kumulative Grenzen sind nicht automatisch aktuelle Warteschlangen

Lassen Sie erklären, was Fläche, Bandbreite und obere Begrenzung in der gewählten Umsetzung bedeuten. Im dokumentierten Jira-Beispiel bleiben frühere Spaltensummen erhalten, wenn Arbeit weiterwandert. Deshalb darf nicht jeder kumulative Wert als Zahl der aktuell in dieser Phase wartenden Vorgänge gelesen werden.

Eine ergänzende Tabelle oder zugängliche Erläuterung sollte Zeitpunkt, Phasenbestände und berücksichtigte Vorgänge erklären. Auch ohne Unterscheidung der Farben muss die Aussage verständlich bleiben. Tabelle und Diagramm brauchen dieselben Filter und denselben historischen Bezug.

Trennen Sie abgeschlossene Arbeit von Stornierungen. Vereinbaren Sie außerdem, wie ein wieder geöffneter Auftrag in den aktiven Fluss zurückkehrt und historisch dargestellt wird. Wiederöffnung ist nicht automatisch ein neuer Kundeneingang. Der Name des Diagramms entscheidet diese Regel nicht.

Vergangene Tage nicht aus heutigen Status erfinden

Heutige Statuswerte reichen nicht, um sämtliche früheren Zustände zu rekonstruieren. Fragen Sie, ob dokumentierte Übergänge, datierte Bestände oder ein anderes vereinbartes Verfahren die Historie liefern. Fehlende Vergangenheit muss als Lücke erkennbar sein, statt als überzeugende durchgehende Kurve zu erscheinen.

Was passiert bei einer Statusumbenennung, zusammengelegten Spalten oder einem Teamwechsel? Möglicherweise brauchen Sie eine sichtbare Definitionsversion oder einen markierten Bruch der Vergleichbarkeit. Heutige Filter rückwirkend anzuwenden beantwortet eine andere Frage als die damalige Zugehörigkeit. Treffen Sie diese Entscheidung ausdrücklich.

Auch historische Berichte unterliegen Zugriffsregeln. Eine erlaubte Gesamtzahl berechtigt nicht automatisch zur Ansicht aller vertraulichen Einzelaufträge. Vereinbaren Sie Zusammenfassung und Detailansicht getrennt.

Einen nachvollziehbaren Ablauf abnehmen

Verwenden Sie für Ihre Akzeptanzkriterien erfundene Anfragen: Eingang, Warten auf Prüfung, Fortschritt, Abschluss, Wiederöffnung und Stornierung. Prüfen Sie auch einen Zeitraum vor Beginn der verfügbaren Historie. Ändern Sie danach Filter oder Spaltenzuordnung und lassen Sie den vereinbarten Umgang mit früheren Punkten vorführen.

Vergleichen Sie die aktuelle Warteschlange mit der Auswertung zum selben Beobachtungszeitpunkt. Kumulative Grenzen müssen erklärt werden, statt sämtliche Werte als wartende Arbeit auszugeben. Tabelle, Diagramm und erlaubte Einzelansicht sollen dieselbe Auswahl beschreiben.

Bringen Sie zur Planung einer Workflow-Auswertung die Frage mit: „In welcher Phase sammelt sich Arbeit, und was prüfen wir als Nächstes?“ Ein guter Bericht unterstützt die Untersuchung, er ersetzt sie nicht.

Quelle und Grenzen

Die am 26. Oktober 2026 gelesene Jira-Cloud-Dokumentation belegt Diagrammaufbau, Engpasshinweis, Board-Filter, Spaltenzuordnung und die Warnung zur kumulativen Lesart anhand ihres Beispiels. Historische Regeln, Berechtigungen und Abnahmefälle sind Vorschläge für Ihre Anwendung, keine Prüfung eines produktiven Systems.