Jira Workflow erstellen mit Frühwarnung

Viele Jira-Workflows sind über Jahre gewachsen. Jedes Team hat einen Status ergänzt, niemand hat einen entfernt. Das Ergebnis sind Abläufe mit zwanzig Status, von denen fünf genutzt werden, und Übergänge, die jeden Status mit jedem verbinden. Erledigt ist dann, was jemand auf „Erledigt“ gezogen hat, ob mit oder ohne Prüfung.

Wenn Sie einen Jira-Workflow erstellen oder überarbeiten, helfen vier Bausteine: schlanke Status, ein klares Konzept für angehaltene Arbeit, Pflichtangaben beim Start und ein Abschluss nur über eine Prüfung. Dazu kommt eine Frühwarnung, die rechtzeitig meldet, wenn ein Termin in Gefahr ist.

Baustein 1: Status schlank halten

Ein Status beschreibt, wo sich die Arbeit befindet. Er beschreibt nicht, wer gerade daran sitzt oder welche Abteilung zuständig ist. Dafür gibt es Felder. Für die meisten Teams im Mittelstand reicht diese Grundform:

Status	Kategorie	Bedeutung
Offen	Zu erledigen	Erfasst, noch nicht bereit
Bereit	Zu erledigen	Alle Angaben vorhanden, kann starten
In Arbeit	In Arbeit	Wird bearbeitet
In Prüfung	In Arbeit	Fertig, wartet auf Abnahme
Erledigt	Erledigt	Abgenommen

Die Kategorie ist wichtig. Filter, Boards und Auswertungen fragen häufig nach der Statuskategorie statt nach einzelnen Status. Ein Status in der falschen Kategorie lässt Arbeit aus allen Übersichten verschwinden.

Mein Grundsatz: So wenig Komplexität wie möglich, so viel Struktur wie nötig. Jeder zusätzliche Status muss eine Frage beantworten, die ohne ihn offenbleibt.

Baustein 2: Pausiert und Blockiert als eigenes Konzept

In vielen Workflows fehlt ein Ort für Arbeit, die gerade nicht weitergehen kann. Also bleibt sie in „In Arbeit“ und verfälscht jede Übersicht. Oder das Team erfindet Status wie „Wartet auf Kunde“, „Wartet auf Freigabe“ und „Wartet auf Lieferant“.

Besser sind zwei klar getrennte Zustände:

• Blockiert: Die Arbeit kann nicht weitergehen, weil etwas fehlt. Das ist ein Signal an die Teamleitung, das Hindernis zu lösen.
• Pausiert: Die Arbeit wurde bewusst zurückgestellt, etwa wegen einer anderen Priorität. Das ist eine Entscheidung, kein Problem.

Beide Status liegen in der Kategorie „In Arbeit“, damit die Vorgänge in offenen Auswertungen sichtbar bleiben. Beim Übergang nach „Blockiert“ fragt eine Maske nach dem Grund. So steht im Vorgang auch, woran es hängt.

Baustein 3: Pflichtangaben beim Start (Definition of Ready)

Pflichtfelder bei der Anlage eines Vorgangs sind ein häufiger Fehler. Wer eine Idee festhalten will, soll das in zehn Sekunden können. Muss er dafür erst Schätzung, Vorhaben und Termin angeben, schreibt er die Idee lieber in eine Mail.

Die Pflichtangaben gehören an den Übergang von „Offen“ nach „Bereit“ oder spätestens nach „In Arbeit“. Typisch sind:

• Verantwortlicher, bewusst gewählt statt automatisch gesetzt
• Fälligkeitsdatum
• Zuordnung zu einem übergeordneten Vorhaben
• Beschreibung mit erwartetem Ergebnis
• Schätzung, wenn das Team mit Schätzungen arbeitet

Technisch setzen Sie das im Workflow mit einem Validator am Übergang um, der die Felder als erforderlich prüft. Dazu kommt eine Maske am Übergang, die genau diese Felder abfragt. So sieht der Nutzer beim Klick auf „Starten“, was fehlt, und kann es direkt ergänzen.

Ein Punkt verdient besondere Aufmerksamkeit: Manche Workflows weisen beim Start automatisch den Nutzer zu, der den Übergang auslöst. Dann ist verantwortlich, wer zufällig geklickt hat. Prüfen Sie Ihre Nachbearbeitungen an den Übergängen und entfernen Sie diese Zuweisung, wenn Verantwortung bewusst vergeben werden soll.

Baustein 4: Abschluss nur über Prüfung (Definition of Done)

Wenn jeder Status direkt nach „Erledigt“ führt, ist die Prüfung freiwillig. In der Praxis wird sie dann übersprungen, sobald es eng wird. Die Folge sind Nacharbeiten, die niemand eingeplant hat.

Die Regel ist einfach: Nach „Erledigt“ führt nur ein Übergang, und zwar aus „In Prüfung“. Ergänzend helfen zwei Einstellungen:

• Eine Bedingung am Übergang, die festlegt, wer abnehmen darf. Zum Beispiel nur Mitglieder einer Prüfer-Rolle oder nicht die Person, die die Arbeit erledigt hat.
• Eine Checkliste in der Beschreibung oder als Feld, die festhält, was vor der Abnahme erfüllt sein muss, etwa Dokumentation aktualisiert oder Kunde informiert.

Für echte Ausnahmen, etwa doppelt erfasste Vorgänge, gibt es einen eigenen Übergang „Verwerfen“ mit eigener Lösung. So bleibt „Erledigt“ ehrlich.

Die Frühwarnung vor Fälligkeit

Ein guter Workflow sorgt für saubere Daten. Eine Frühwarnung sorgt dafür, dass jemand rechtzeitig darauf reagiert. Die Idee: Eine bestimmte Zahl von Arbeitstagen vor dem Fälligkeitsdatum bekommt der Verantwortliche einen Hinweis, solange der Vorgang nicht erledigt ist.

Eine sparsame Umsetzung als Automationsregel sieht so aus:

1. Auslöser: geplant, einmal pro Arbeitstag am frühen Morgen.
2. Suche: duedate >= startOfDay() AND duedate <= endOfDay("+5d") AND statusCategory != Done AND (labels is EMPTY OR labels != fruehwarnung)
3. Bedingung: Das Fälligkeitsdatum liegt höchstens drei Arbeitstage entfernt. JQL kennt keine Arbeitstage, die Automation schon: Ein erweiterter Vergleich mit dem Smart Value {{now.plusBusinessDays(3)}} erledigt das.
4. Aktionen: Kommentar mit Erwähnung des Verantwortlichen und Label fruehwarnung setzen, damit dieselbe Warnung nicht jeden Tag erneut kommt.

Die Zahl der Arbeitstage legen Sie mit den Teams fest. Drei Tage sind ein guter Ausgangswert. Überfällige Vorgänge behandelt eine zweite Regel mit eigener Eskalation an die Teamleitung.

Achten Sie auf zwei Punkte. Die Warnung geht an den Verantwortlichen, nicht an die Geschäftsführung. Und die Regel läuft einmal am Tag, nicht stündlich. Ab dem 3. Dezember 2026 rechnet Atlassian Automationen nach Schritten ab, und geplante Regeln mit breiter Suche verbrauchen schnell viel davon. Wie groß der Unterschied sein kann, rechne ich im Beitrag Jira-Automation ab 3. Dezember vor.

Hinweis zum neuen Workflow-Editor

Seit April 2026 ist in Jira Cloud der neue Workflow-Editor Standard. Der alte Editor wurde laut Atlassian-Ankündigung bis Ende Juli 2026 abgeschaltet. Validatoren, Bedingungen und Nachbearbeitungen heißen im neuen Editor teilweise anders und sitzen an anderer Stelle. Wer Anleitungen aus älteren Quellen nutzt, findet die Einstellungen deshalb nicht immer dort, wo sie beschrieben sind. Stand der Angaben: 27.09.2026.

Für die Überarbeitung empfehle ich außerdem, nicht das gemeinsam genutzte Schema direkt zu ändern. Legen Sie eine Kopie für ein Pilotprojekt an, testen Sie dort und übertragen Sie das Ergebnis erst danach auf weitere Projekte. So wirkt eine Änderung nicht sofort auf alle Teams.

Was ein solcher Workflow bewirkt

Mit diesen Bausteinen beantwortet Jira die Fragen, die in jeder Projektbesprechung gestellt werden: Wer ist verantwortlich, bis wann, woran hängt es, und ist es wirklich fertig. Die Filter und Dashboards darauf aufzubauen, beschreibe ich im Beitrag Jira-Dashboard für die Geschäftsführung. Wenn Ihr bestehender Workflow weit von dieser Grundform entfernt ist, finden Sie in Jira aufräumen: 8 Anzeichen für Wildwuchs eine Einordnung, wo Sie anfangen sollten.

Wie ich Workflows, Status, Vorgangstypen und Masken überarbeite, steht auf der Seite zu Jira-Workflows. Frühwarnung, Stillstandserkennung und Eskalation beschreibe ich auf der Seite zur Jira-Automatisierung.

Häufige Fragen

Wie viele Status sollte ein Jira-Workflow haben?

Für die meisten Teams im Mittelstand reichen fünf bis sieben Status, einschließlich eigener Zustände für „Blockiert“ und „Pausiert“. Entscheidend ist weniger die genaue Zahl als dass jeder Status eine eindeutige, allen bekannte Bedeutung hat und der richtigen Kategorie zugeordnet ist. Ein Status in der falschen Kategorie verschwindet sonst aus allen Auswertungen offener Arbeit.

Bremsen Pflichtfelder das Team nicht aus?

Nicht, wenn sie an der richtigen Stelle im Workflow stehen. Bei der Anlage eines Vorgangs bleibt das Erfassen einer Idee bewusst schnell und ohne Pflichtfelder. Erst beim Übergang in die Bearbeitung verlangt ein Validator die Angaben, die für Planung und Steuerung wirklich nötig sind, etwa Verantwortlicher, Termin und Vorhaben.

Kann die Frühwarnung Arbeitstage statt Kalendertage berücksichtigen?

Ja. JQL selbst rechnet nur in Kalendertagen, die Automation kennt aber eigene Funktionen für Arbeitstage. Mit einer Bedingung auf Basis des Smart Value plusBusinessDays lässt sich die Warnung so einstellen, dass ein Wochenende nicht als verlorener Vorlauf zählt. Das verhindert unnötig frühe oder zu späte Hinweise an die Verantwortlichen.

Ihr nächster Schritt

Sie möchten Ihren Workflow verschlanken, ohne den laufenden Betrieb zu stören? Im kostenlosen 30-Minuten-Erstgespräch sehen wir uns Ihren heutigen Ablauf an, und ich zeige Ihnen, wo ich ansetzen würde.

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