So richtet ihr einen guten Jira-Workflow ein

Jira-Workflow-Design: Den gesamten Prozess auf einen Blick

Aufgrund meines beruflichen Hintergrunds als Prozessmanager achte ich besonders auf gut lesbare Workflows. Es gibt drei Visualisierungsvarianten, die einen Workflow verständlicher machen und die wir im Folgenden betrachten.

Ereignisgesteuerte Prozesskette (EPK)

Natürlich erstellen wir in Jira keine ereignisgesteuerten Prozessketten, aber diese Art der Visualisierung gehört zu den am häufigsten verwendeten.

Der ideale Ablauf des Prozesses wird von oben nach unten dargestellt. Wichtige oder abweichende Status werden links oder rechts des Prozessablaufs platziert.

Business Process Modeling Notation (BPMN)

In dieser Variante erstellen wir Prozesse ähnlich wie EPK-Diagramme, lesen sie jedoch von links nach rechts. Meiner Meinung nach sind sie leichter verständlich, weil sie sich einfacher auf Kanban- oder Scrum-Boards übertragen lassen – sowohl praktisch als auch gedanklich.

Wasserfallmodell

Mit dem Wasserfallmodell ordnen wir Status schrittweise an. Wir beginnen oben links und arbeiten uns nach unten rechts vor. Diese Darstellungsform bietet einen besonderen Vorteil: Übergänge lassen sich optisch trennen und Rückflüsse klar erkennbar darstellen.

Es kann als Hybrid der beiden zuvor genannten Diagramme betrachtet werden, da es die Vorteile der ereignisgesteuerten Prozesskette und von BPMN-Diagrammen hinsichtlich der Lesbarkeit kombiniert – insbesondere bei komplexeren Workflows.

Workflow- und Geschäftsregeln

Ich möchte betonen, dass es mir nicht darum geht, Regeln vorzuschreiben. Vielmehr geht es um klar definierte Bedingungen, die jeden Benutzer und Administrator leiten.

Hinweis: Dieser Absatz ist der kontroverseste Punkt in der gesamten Atlassian-Community. Ich freue mich auf euer Feedback und Einladungen zu Konferenzen und Podcasts!

Statusnamen: Einfach, global, wiederverwendbar

Ein wesentlicher Faktor für einen guten Jira-Workflow ist die optimale Benennung der einzelnen Status. Doch wie findet ihr die richtigen Namen? Hilfreich ist, sich an das Ziel zu erinnern: den Zustand eines Issues zu beschreiben – nicht den Status. Dabei sollte die Bezeichnung so einfach und abstrakt wie möglich sein.

Die Benennung von Status ist ein häufiger Diskussionspunkt in Unternehmen und Communities. Hier sind einige Tipps, um eine klare und verständliche Struktur für Statusnamen zu schaffen:

Status, die aus einem Wort bestehen, wie Open, Closed oder Waiting, beschreiben Issues, an denen niemand arbeitet. Status, bei denen eine oder mehrere Personen aktiv arbeiten, heißen In Progress, Review oder Test.

Ein weiterer wichtiger Punkt bei der Benennung von Status ist die Wiederverwendbarkeit. Status dürfen und sollten individuell sein, ohne sie zu detailliert zu definieren. Denkt dabei: „So viel wie nötig, so wenig wie möglich.“

Alle Projekte mit unterschiedlichen Testphasen verwenden In Testing. Dieser Status erklärt nicht, welcher Test gemeint ist, ob E2E (End-to-End) oder UAT (User Acceptance Test). Das ist auch nicht unbedingt wichtig, insbesondere wenn mehrere Testarten stattfinden. Entscheidend ist, dass die globale Zuordnung für alle Vorgänge funktioniert und der Status definiert ist.

Außerdem sollten gleiche oder ähnliche Status in verschiedenen Kategorien vermieden werden. Das schafft Struktur und hilft dabei, ein Issue bewusst in den nächsten Status zu überführen. Um den gerichteten Workflow eines Issues zu unterstützen, ist es wichtig, es den passenden Kategorien zuzuordnen.

Sobald ein Status erreicht ist, der zur Statuskategorie In Progress gehört, müssen auch alle weiteren Status dieser Kategorie angehören. Wichtig ist, zwischen beeinflussbaren und nicht beeinflussbaren Aktionen zu unterscheiden.

Wenn ihr lange auf einen externen Dienstleister wartet, solltet ihr euch fragen: „Kann ich dies noch selbst beeinflussen oder schließe ich das Ticket?“ Dann muss bewusst eine Entscheidung getroffen werden.

Statusregeln: Wann brauche ich einen Status?

Wann brauche ich einen (neuen) Status? Habt ihr euch diese Frage schon einmal gestellt? Vielleicht in Meetings, in denen der Fachbereich einen Status nach dem anderen verlangt? Habt ihr euch auch schon ein Argument dafür oder dagegen gewünscht? Vor vielen Jahren habe ich mir genau diese Fragen gestellt, recherchiert, mit verschiedenen Menschen darüber gesprochen und Artikel gelesen. Daraus entstand die folgende Fragenliste:

1. Müssen Personen eine Nachricht erhalten? 2. Dürfen nur bestimmte Personen einen Übergang zu einem Status vornehmen? 3. Ändert sich die Verantwortung vom vorherigen zum neuen Status? 4. Müssen Personen nach diesem Status filtern können? 5. Müssen Personen über diesen Status berichten können, z. B. über die Zeit in diesem Status?

Wenn all diese Fragen mit JA beantwortet werden können, sind Warteschlangen (Lager) ein weiteres Thema, das separat betrachtet werden muss.

Warteschlangen

Für mich sind Warteschlangen Zwischenstatus, in denen nicht gearbeitet wird. Hier liegt der Vorgang und wartet darauf, in den entsprechenden Folgestatus gezogen zu werden. Einer der Gründe für die Verwendung dieser Status liegt meiner Meinung nach in einem schlechten Workflow-Design – häufig in der Vermischung von Push- und Pull-Prinzip.

Sehen wir uns das folgende Beispiel an:

In diesem Workflow gibt es einen Zwischenstatus. Er soll anzeigen, dass ein Vorgang für den nächsten Arbeitsschritt verfügbar ist.

Wenn wir diese Status entfernen und den Workflow um eine Postfunktion erweitern, die sicherstellt, dass der Bearbeiter bei einem Statusübergang zurückgesetzt wird, zum Beispiel von In progress zu In review , erzielen wir dasselbe Ergebnis.

Die Kanban-Board-Spalte zeigt entsprechend zugewiesene und nicht zugewiesene Vorgänge an. Ein Mitarbeiter kann einen Vorgang also AKTIV ÜBERNEHMEN (PULL). Damit sparen wir mindestens drei Status.

Tipp: Vermeidet Warteschlangen und nutzt Workflow-Funktionen, um das Push- und Pull-Prinzip beizubehalten.

Start- und Endstatus

Meiner Meinung nach gibt es keinen guten Grund, warum Workflows in einem Unternehmen unterschiedliche Start- und Endstatus haben sollten. Um es einfach zu halten, gilt die Regel: Jeder Workflow beginnt mit dem Status Open und endet mit dem Status Closed.

Diese einfache Regel schafft Klarheit – sowohl für Administratoren als auch für Benutzer, die neue Workflows benötigen oder mit bestehenden arbeiten dürfen.

Status versus Lösung

Eine weitere Herausforderung ist die Vermischung von Status und Lösungen. Wie bereits erwähnt, sollte der letzte Status immer Closed sein. Ein Status wie Done, Deprecated oder Withdrawn existiert nicht, denn dabei handelt es sich nicht um einen Status, sondern um eine Information – also die Lösung.

Tipp: Stellt sicher, dass beim Schließen die entsprechende Information (Lösung) gesetzt wird.

Übergänge versus Informationen

Damit ein Vorgang zwischen zwei Status wechseln kann, muss ein Übergang bestehen. Ein Übergang ist eine Einwegverbindung. Soll ein Vorgang also zwischen zwei Status hin- und herwechseln, müssen zwei Übergänge erstellt werden.

In Softwareentwicklungsteams begegnet man Status wie Prioritization, preparation und refinement. In größeren Organisationen oder auf Planungsboards können diese notwendig und sinnvoll sein. Ihr solltet euch jedoch fragen, was in diesen Status tatsächlich passiert.

Häufig füllen wir in Team-Meetings Felder wie Priority oder Story points erst am Ende aus. Dafür gibt es deutlich einfachere und bessere Lösungen, zum Beispiel mit Sprints oder Apps wie Structure. Status wie die oben genannten erhöhen die Komplexität des Workflows und bringen dem Team weniger Nutzen als dem Produkt- oder Projektmanager.

All Transitions

Bei den sogenannten All Transitions bin ich zwiegespalten. Ein Prozess ist ein gerichteter Ablauf von Aktionen, doch All Transitions ermöglichen es, Vorgänge zwischen Status hin- und herzuschieben. Beispielsweise können Vorgänge aus mehreren Status in On Hold verschoben werden. In diesem Fall ist ein gerichteter Prozess nicht mehr gewährleistet. Umso wichtiger ist es, dass jede Statusänderung eine bewusste Entscheidung ist.

Da ein Übergang einem Vorgang explizit oder implizit weitere Informationen hinzufügt, unterscheidet er sich von den vorherigen Status. All Transitions können daher Verwirrung stiften, wenn Vorgänge zu schnell und unbedacht verschoben werden. Bis zu einem gewissen Grad würde ich sagen, dass sie Disziplin untergraben. Richtig eingesetzt und bewusst gehandhabt können sie einen Workflow jedoch beschleunigen und vereinfachen.

Viele Faktoren machen einen guten Jira-Workflow aus

Ein gut lesbares Workflow-Design mit unterschiedlichen Statusfarben und klar strukturierten Übergängen bildet die Grundlage. Darüber hinaus verbessern allgemeine Workflow- und Geschäftsregeln für Statusnamen sowie eine klare Definition von Start- und Endstatus den Workflow.

Dass jede Statusänderung eine bewusste Entscheidung sein sollte, hilft dabei, definierte Statusregeln einzuhalten. So lassen sich Warteschlangen vermeiden und All Transitions gezielt einsetzen. Das Ziel sollte immer ein gerichteter Prozess sein.

Abschließend möchte ich noch einmal betonen, dass es viele Möglichkeiten gibt, einen guten Jira-Workflow umzusetzen. Deshalb geht es in diesem Artikel nicht darum, Regeln festzulegen und durchzusetzen, sondern um die Möglichkeiten.