Ein guter Workflow bildet die Arbeitsweise eines Teams bzw. Unternehmens ab. Er definiert die Prozessschritte und Status von Vorgängen und gibt Ihnen einen strukturierten Ablauf. Die Jira Workflow Engine ist ein sehr starkes Instrument, um sehr komplexe Arbeitsabläufe und Integrationen in andere Systeme zu realisieren. Insbesondere auf Atlassian Community Events bestätigen Kundenberichte, wie Drittsysteme eingebunden werden können.
Jira Workflow Design: Der gesamte Prozess auf einen Blick
Unter Workflow Design versteht man in erster Linie die visuelle Anordnung von verschiedenen Status. So entsteht ein Diagramm eines spezifischen Workflows, das die individuell angelegten Status abbildet. Die Status werden verknüpft durch Transitions (Übergänge), die später den Ablauf eines Issues bestimmen. Die unterschiedlichen Status-Kategorien, wie TO DO, IN PROGRESS oder DONE, unterscheiden sich farblich. So lassen sich individuelle Status sehr gut entsprechenden Kategorien zuordnen. Das sorgt für mehr Übersicht im Jira Workflow Design und trägt zur verbesserten Lesbarkeit bei. Und das führt zum einen zu mehr Verständnis, wie die Prozesse funktionieren. Zum anderen erhöht es die Akzeptanz für den Workflow – sowohl bei Benutzern als auch Administratoren.
Aufgrund meiner beruflichen Vergangenheit als Prozess Manager lege ich besonderes Augenmerk auf gut lesbare Workflows. Es gibt drei Varianten der Darstellungsmöglichkeit, um einen Workflow lesbar zu machen:
Ereignisgesteuerte Prozesskette (EPK)
Natürlich bauen wir keine ereignisgesteuerten Prozessketten in Jira. Jedoch ist die Darstellungsvariante eine der am häufigsten gewählten.
Der idealtypische Verlauf des Prozesses wird von oben nach unten gezeichnet Wichtige oder vom idealtypischen Verlauf abweichende Status werden links oder rechts neben dem Prozessstrang angeordnet.
Business Process Modelling Notation (BPMN)
In dieser Variante modellieren wir Prozesse ähnlich der EPK Diagramme, nur werden diese von links nach rechts gelesen und dienen m.E. mehr dem Verständnis, denn sie lassen sich gedanklich einfacher auf Kanban oder Scrum Boards übertragen.
Wasserfall Modell
In der Variante des “Wasserfall Modells” ordnen wir die Status stufenförmig an. Wir beginnen oben Links und arbeiten uns stufenförmig nach unten rechts. Diese Darstellungsform hat einen besonderen Vorteil: Transitionen können optisch sauber getrennt und Rückflüsse deutlicher kenntlich gemacht werden. Es kann als Mischform beider bisher genannten Diagramme gesehen werden, denn sie kombiniert die Vorteile von EPK und BPMN Diagrammen hinsichtlich der Lesbarkeit insbesondere bei komplexeren Workflows.
Für alle drei Varianten gilt: Es ist immer zu vermeiden, dass sich Transitionen kreuzen.
Workflow- und Unternehmensregeln
Aus meiner Sicht ein klares Muss, um das gemeinsame Arbeiten zu verbessern und zu vereinfachen: Die Definition unternehmensweiter Regeln für die Verwendung von Jira Workflows und den darin enthaltenen Konfigurationselementen. Dabei möchte ich betonen, dass es mir nicht um das Aufoktroyieren von Regeln geht. Sondern vielmehr sehe ich den Sinn in klar definierten Rahmenbedingungen, die jedem Benutzer und Administrator den Weg weisen.
Dieser Absatz ist mit Sicherheit der kontroverseste Punkt in der ganzen Atlassian Community, ich freue mich auf Euer Feedback und zu Einladungen zu Konferenzen und Podcasts
Status Namen: Einfach, global, wiederverwendbar
Wesentlicher Faktor für einen guten Jira Workflow ist die optimale Benennung der einzelnen Status. Doch wie findet man die richtigen Begriffe? Hierbei hilft es, sich das Ziel eines Status noch einmal bewusst zu machen: Er soll den Zustand (engl.: state, nicht status) eines Vorgangs beschreiben. Und zwar möglichst einfach und abstrakt. Die Benennung von Status ist ein häufiger Diskussionspunkt. Hier sind ein paar Tipps, um eine klare und nachvollziehbare Struktur in die Status-Benennung zu bringen:
Status, bestehend aus einem Wort wie Offen, Geschlossen, Wartend, beschreiben Vorgänge, in denen noch nicht aktiv gearbeitet wird. Status, in denen ein oder mehrere Personen aktiv arbeiten, heißen dann IN … Arbeit, Überprüfung, Test.
Ein weiterer wichtiger Punkt bei der Benennung von Status ist ihre Wiederverwendbarkeit. Status dürfen und sollen individuell sein, einen Zustand jedoch nicht zu kleinteilig definieren. Ganz nach dem Credo: So viel wie nötig, so wenig wie möglich. So sind bspw. sämtliche Projekte, die sich in verschiedenen Testphasen befinden, in testing. Denn um welchen Test es geht – ob E2E (End-toEnd) oder UAT (User Acceptance Test) –, erklärt nicht der Status. Wichtig ist, dass die globale Zuordnung für alle Vorgänge funktioniert und der Zustand deutlich wird. Außerdem sind gleiche oder ähnliche Status in unterschiedlichen Status-Kategorien zu vermeiden. Das sorgt für Struktur und hilft dabei, einen Vorgang ganz bewusst in den nächsten Status zu verschieben. Um den gerichteten Ablauf eines Vorgangs zu unterstützen, ist die Zuordnung in entsprechenden Kategorien wichtig. Sobald ein Status erreicht wird, der der Status Kategorie “In Progress” angehört, müssen alle weiteren ebenfalls dieser Kategorie angehören. Hier ist darauf zu achten, zwischen beeinflussbaren und nicht beeinflussbaren Leistungen zu unterscheiden. Wartet man beispielsweise sehr lange auf einen externen Dienstleister, sollte man sich fragen: Kann ich das selbst noch beeinflussen oder schließe ich das Ticket? Hier muss dann eine bewusste Entscheidung getroffen werden.
Status Regeln: Wann brauche ich einen Status?
Wann benötige ich einen Status? Habt ihr euch diese Frage auch schon einmal gestellt? Möglicherweise in Meetings, in denen die Fachabteilung einen weiteren Status nach dem anderen anfragt? Habt ihr euch auch gewünscht, ein Argument für und wider zu haben?
Vor vielen Jahren habe ich mir diese Fragen ebenfalls gestellt, habe recherchiert und mich mit unterschiedlichen Personen darüber ausgetauscht und Artikel gelesen. Ein Blogbeitrag, den ich damals gefunden habe, möchte ich an dieser Stelle besonders erwähnen: Jira Workflows: Best Practices und typische Fehler.
Für mich hat sich folgender Fragenkatalog ergeben, der mir bei der Argumentation hilft. Gleichermaßen unterstützt er das Verständnis der jeweiligen Abteilung oder Person, wofür man einen Status benötigt, und vermeidet somit mögliches Over Engineering:
1. Müssen Personen eine Benachrichtigung erhalten?
2. Dürfen nur gewisse Personen einen Übergang zu einem Status ausführen?
3. Ändert sich von dem vorherigen zum dem neuen Status die Verantwortlichkeit?
4. Müssen Personen diesen Status filtern können?
5. Müssen Personen diesen Status reporten (z. B. Zeit im Status)?
Können alle diese Fragen mit einem JA beantwortet werden, ist der neue Status vermutlich sinnvoll. Ein weiteres Thema sind die Warte-Halden. Sie sind noch einmal separat zu betrachten.
Warte-Halden
Warte-Halden sind für mich sogenannte Vor-Status, in denen nicht gearbeitet wird. Hier liegt der Vorgang und wartet darauf, dass man ihn in den entsprechenden nachfolgenden Status zieht. Einer der Gründe, warum diese Status benutzt werden – jedoch aus meiner Sicht zu einem schlechten Jira Workflow Design gehören – ist das immer wieder und viel zitierte Push- & Pull Prinzip.
Schauen wir uns das Ganze an folgendem Beispiel an.
In diesem Jira Workflow gibt es vor jedem In … Status eine Warte Halde (For … Status). Diese soll anzeigen, dass eine Aufgabe für den nächsten Arbeitsschritt zur Verfügung steht.
Entfernen wir die Warte-Halden und erweitern den Workflow um eine Folgefunktion die dafür sorgt, dass der Bearbeiter in einem Statusübergang z. B. von In Progress zu In Review zurückgesetzt wird, haben wir dasselbe Ergebnis.
Demnach sind in der Kanban Board Spalte zugewiesene und nicht zugewiesene Vorgänge zu sehen. Ein Mitarbeiter kann sich also AKTIV einen Vorgang NEHMEN (PULL). Hierbei sparen wir mindestens drei Status.
Versucht Warte-Halden zu vermeiden und nutzt Workflow Funktionalitäten um das Push- & Pull Prinzip einzuhalten.
Start und Ende Status
Meines Erachtens gibt es keinen guten Grund, dass in einem Unternehmen die Workflows unterschiedliche Start und Ende Status besitzen müssen. Um es einfach zu halten, gilt: Jeder Workflow beginnt mit dem Status Offen und endet mit dem Status Geschlossen.
Diese einfache Regel sorgt für mehr Klarheit und Verständnis – sowohl bei Administratoren als auch bei Mitarbeitern, die sich neue Workflows wünschen oder mit den Workflows arbeiten dürfen.
Status versus Lösung
Ein weiterer Punkt ist die Vermischung von Status und Lösungen (Resolutions). Wie erwähnt, sollte der letzte Status immer Geschlossen sein. Ein Status Fertig, Veraltet (Deprecated), Zurückgezogen (Withdrawn), existiert nicht, da es sich hierbei nicht um einen Zustand sondern um eine Information, also die Lösung, handelt.
Stellt also sicher, dass während der Vorgangsschließung die entsprechende Information (Lösung) gesetzt wird.
Der Status ist der Zustand eines Vorganges. Die Lösung die Information im Status Geschlossen.
Übergänge versus Informationen
Damit sich ein Vorgang zwischen zwei Status bewegen kann, muss ein Übergang oder Transition existieren. Ein Übergang ist eine einseitige Verbindung, wenn also ein Issue zwischen zwei Status hin und her bewegt werden muss, müssen zwei Übergänge erstellt werden.
Gerade in Software-Entwicklungsabteilungen fällt auf, dass es Status wie Prioritization, Preparation, Refinement gibt. Diese können tatsächlich in größeren Abteilungen oder Planning Boards notwendig und vernünftig sein. Jedoch sollte man sich die Frage stellen: Was passiert wirklich in diesen Status?
Häufig handelt es sich hierbei nämlich um Team-Meetings, um am Ende ein Feld wie Priorität oder Story Points zu befühlen. Hier gibt es deutlich einfachere und schönere Lösungen, zum Beispiel die Verwendung von Sprints oder Apps wie Structure. Status, wie die oben genannten, führen unnötigerweise zu einer erhöhten Workflow-Komplexität und dienen weniger dem Team als dem Produkt- oder Projektmanager.
All Transitions
Bei den sogenannten All Transitions bin ich geteilter Meinung. Denn ein Prozess ist ein gerichteter Ablauf eines Geschehens. All Transitions ermöglichen allerdings, Issues beliebig zwischen verschiedenen Status zu verschieben. Zum Beispiel können Issues aus mehreren Status auf on hold gezogen werden. Ein gerichteter Vorgang ist dann allerdings nicht mehr gewährleistet. Umso wichtiger ist hier, dass jede Statusänderung eine bewusste Entscheidung ist. Hier erhält ein Vorgang explizit oder implizit mehr Information.
Damit unterscheidet er sich von den anderen bzw. davor liegenden Status. All Transitions können daher für Verwirrung sorgen, wenn Issues zu schnell und unbedacht verschoben werden. Ich behaupte, dass sie gewissermaßen ein undiszipliniertes Verhalten fördern. Trotzdem: Gut eingesetzt und bewusst behandelt können sie einen Prozess beschleunigen und vereinfachen.
Zusammenfassung
Es gibt viele Punkte, die einen guten Jira Workflow ausmachen. Ein gut lesbares Workflow Design durch unterschiedliche Farben der Status sowie klar strukturierte Transitions bildet die Basis. Zusätzlich verbessern allgemeine Workflow- und Unternehmensregeln für Status-Namen sowie die klare Definition von Start- und Ende-Status den Workflow. Dass jede Status-Veränderung eine bewusste Entscheidung sein sollte, hilft beim Einhalten festgelegter Status-Regeln. So können Warte-Halden vermieden und All Transitions gezielt eingesetzt werden – beispielsweise für On-hold-Status.
Insgesamt sollte allerdings immer ein gerichteter Ablauf angestrebt werden. Was ich noch einmal betonen möchte: Es gibt viele Wege, um das Ganze umzusetzen. Deshalb geht es in meinem Blogartikel auch nicht darum, Regeln festzulegen und vorauszusetzen. Vielmehr möchte ich Möglichkeiten aufzeigen und Denkanstöße bieten. Ich finde es wichtig, dass in einer Organisation und Teamübergreifend ein Verständnis für Arbeitsabläufe existiert, auf dessen Basis man sich austauschen kann. Dazu gibt es einige Best Practices, die vor allem auch weniger technisch versierten Mitarbeitern die Arbeit erleichtern.
Du hast Fragen oder wünschst mehr Informationen? Kontaktiere uns einfach oder buche einen Termin mit unserem Consultant und CMO Jan Szczepanski:
