Jira Workflows: Best Practices und typische Fehler

Wenn ich in ein Unternehmen gehe, habe ich stets eine Liste mit Best Practices und typischen Anfängerfehlern für Jira dabei. Diese Liste wird von meinen Kunden sehr geschätzt, da sich die Fehler häufig vermeiden lassen und gerade in der Anfangsphase eines neuen Systems jeder Fehler kritisch beurteilt wird. In der folgenden Artikelserie werde ich einen Teil dieser Liste mit der Jira Community teilen und bin gespannt auf neue Anregungen und Kommentare.

Overengineering

Jira Workflows werden typischerweise den realen Arbeitsabläufen in einem Unternehmen nachempfunden. Dieser Ansatz ist soweit richtig – allerdings sollte eine sinnvolle Abwägung zwischen der Abbildung des realen Arbeitsablaufes und der letztendlichen Benutzerfreundlichkeit in Jira stattfinden. Dieser Schritt ist einer der komplexesten und bedarf einiger Erfahrung der Möglichkeiten und Grenzen von Jira. Meiner Erfahrung nach lautet die goldene Regel für Workflows in Jira:

So viel wie nötig, so wenig wie möglich!

(Oder auch das “KISS”-Prinzip: Keep it short and simple). Soll heißen: so viele Workflow-Schritte wie nötig, aber so wenig wie möglich. Welche der realen Arbeitsschritte als Workflow-Schritt in Jira benötigt werden, kann man nicht grundsätzlich beantworten, da man stets die konkreten Umstände des Unternehmens und der Mitarbeiter berücksichtigen muss. Es gibt allerdings einige Fragen, anhand derer man die Notwendigkeit eines Schrittes prüfen kann:

  • Findet ein Wechsel der Verantwortlichkeit statt?
  • Dürfen nur bestimmte Personen oder Benutzergruppen diesen Schritt durchführen?
  • Müssen Benachrichtigungen versendet werden?
  • Muss ich nach diesem Schritt filtern können, d.h. eine Übersicht aller Vorgänge im verknüpften Status sehen können?

Je mehr dieser Fragen mit “Ja” beantwortet werden, um so sicherer sollte dieser Schritt auch in Jira abgegildet werden. Häufig werden in der Konzeptionsphase zu viele Schritte in einen Workflow eingebaut, was das Eingangs erwähnte Overengineering zur Folge hat. Ein solcher Workflow ist zwar fachlich korrekt, stößt aber durch seine Komplexität bei den Benutzern auf Unverständnis – die Folge sind Fehlbedienungen und Ablehnung des neuen Werkzeugs. Ein Negativ-Beispiel:

Die fiktive Firma RequirementsUnlimited möchte das interne Anforderungsmanagement mit Jira umsetzen. Sie erstellt daher einen Workflow, der den fachlichen Prozess bei der Aufnahme einer Anforderung widerspiegelt. Die ersten 4 Schritte für den Vorgangstyp “Anforderung” lauten: Offen, In Abstimmung, Anerkannt, Eingeplant.

Klingt soweit ganz gut. Allerdings: um eine neue Anforderung aufzunehmen, werden bereits 4 Workflowschritte benötigt, durch die sich der Benutzer im Zweifel “durchklicken” muss. Hier sollte man also prüfen, ob wirklich alle Schritte notwendig sind. Bei RequirementsUnlimited besteht z.B. der einzige Unterschied zwischen den Status “Anerkannt” und “Eingeplant” darin, dass der Vorgang in diesem Statusübergang einem konkreten Release (in Jira also einer Lösungsversion) zugeordnet wird. Auf die Frage, warum dafür ein eigener Status notwendig ist, antwortet der Projektleiter: “Ich will filtern können, welche Vorgänge anerkannt, aber noch nicht eingeplant sind!“. Mit dieser Information kann man nun guten Gewissens empfehlen, den Schritt “Eingeplant” zu streichen: man kann per Filter auch alle Vorgänge anzeigen lassen, die im Status “Anerkannt” und keiner Lösungsversion zugeordnet sind. Sofern die Filtermöglichkeit also die einzige Notwendigkeit für den Schritt “Eingeplant” war, kann man diesen streichen und die vorhandenen Filter anpassen.

Im Beispiel mag es zunächst trivial klingen, ob der Workflow nun einen Schritt mehr oder weniger hat – bei größeren und komplexeren Workflows erzeugt jeder zusätzliche Schritt jedoch eine neue Stufe von Komplexität und Abhängigkeiten. Diese gering zu halten, ist das Ziel eines sauberen und benutzerfreundlichen Workflows.

Schlechte Namensgebung bei Statusübergängen

Eine beliebte Quelle für schlechte Benutzbarkeit von Workflows ist die Namensgebung der Statusübergänge. Beim fachlichen Erstellen eines Workflows ist man geneigt, Statusübergänge danach zu benennen, was im letzten Status passiert ist, anstatt danach, was im nächsten Status passieren wird. Dabei muss man wissen, dass die Namen der Statusübergänge dem Benutzer als verfügbare Workflow-Schritte angezeigt werden:

Anzeige der Statusübergänge in Jira

Die Benutzer von Jira wissen in den meisten Fällen, was gerade mit dem Vorgang passiert ist und wollen in der Anzeige der verfügbaren Schritte stattdessen sehen, in welchen Folgestatus der jeweilige Schritt führen wird. Ein Negativ-Beispiel:

Jira Workflow - Bad Practice

Ein Statusübergang “Abstimmung beendet” führt beim Benutzer unweigerlich zu den Fragen “Was bedeutet das?“, “Was passiert, wenn ich da jetzt draufklicke?“. Die Folge ist wiedereinmal Unsicherheit und Fehlbedienung. Der Statusübergang sollte in diesem Beispiel besser wie folgt lauten:

Jira Workflow - Best Practice

Durch die Bezeichnung “Vorgang bearbeiten” wird dem Nutzer sofort ersichtlich, in welchen Folgezustand ihn seine Aktion führen wird. Die Regel für die Benennung von Statusübergängen lautet demzufolge: aus dem Namen eines Statusübergang muss erkennbar sein, in welchen Folgestatus der Vorgang dabei geführt wird.

Dies waren nur zwei von zahlreichen Beispielen, die bei der Konzeption und Einrichtung von Workflows in Jira beachtet werden sollten (u.a. noch zu nennen: Verwendung der Status Gelöst und Geschlossen, Globale Statusübergänge, Vergabe von Workflow-Bedingungen uvm.). An dieser Stelle natürlich meine abschließende Frage: mit welchen Fehlern oder Problemen hatten Sie bei der Erstellung von Workflows zu kämpfen? Über Ihren Kommentar würde ich mich freuen!

28. November 2012 von Sebastian Höhne
Kategorien: Jira | Schlagwörter: , , | 3 Kommentare

Kommentare (3)

  1. Hallo Sebastian,

    danke für den guten Überblick, gerade das KISS-Prinzip bei Workflows, common Transitions, das verpflichtende Setzen von Lösungen in bestimmten Status sind auch immer wieder Dinge, die ich als sehr wichtig erachte.

    Ich würde mich freuen, wenn es zu solchen Themen also Admin-Best Practises mehr Tipps und Guides geben würde. Selber habe ich einige hiervon veröffentlicht (https://www.xing.com/topics/de/10-wertvolle-jira-tipps-fur-administratoren-102) und bislang ebenfalls gutes, weil dankbares Feedback bekommen. Ich plane es ebenfalls weiterzuführen.

    Ich habe meinem Netzwerk (einige JIRA-Admins) auf jeden Fall erst einmal Deinen Blog empfohlen.

    Weiter so!
    Kai

  2. Hallo!
    Mir gefällt dieser Beitrag sehr gut und ich kann aus persönlicher Erfahrung sagen, dass es für die Akzeptanz des Workflows sehr entscheidend ist, ihn schlank zu halten. Das angesprochene Overengineering habe ich in der Praxis mehrfach erlebt. Außerdem würde ich sehr dazu raten den Workflow gemeinsam mit den Hauptbeteiligten (idR die Entwickler) zu definieren.
    Viele Grüße
    Dominik Grusemann

    • Hallo Dominik,

      danke für das Feedback! Du hast Recht, die Beteiligten des Workflows sollten unbedingt mit einbezogen werden – schließlich sind es ja deren Arbeitsabläufe, die abgebildet werden sollen. Häufig wird dabei auch der Unterschied zwischen den theoretischen Unternehmensprozessen und gelebter Praxis deutlich. ;)

      Grüße,
      Sebastian

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert


feedback