Jira-Workflow für die Softwareentwicklung: das beste Setup, Beispiele und Best Practices für 2026

Yury Pukhov CEO & Mobile Engineering Lead, YuSMP Group

Ein Jira-Workflow für die Softwareentwicklung ist der Weg, den jede Story, jeder Bug und jede Aufgabe von der Idee bis in die Produktion nimmt. Entspricht dieser Weg der tatsächlichen Arbeitsweise Ihres Teams, wird das Board zu einem verlässlichen Bild der Auslieferung: Jeder sieht, was blockiert ist, was auf ein Review wartet und was bereit für den Release ist. Entspricht er ihr nicht, verbringen Entwickler ihre Zeit mit dem Verschieben von Karten, Manager laufen Statusmeldungen hinterher und die Reports sagen nichts Brauchbares aus.

Die meisten Jira-Projekte, die wir von Kunden übernehmen, haben das zweite Problem. Workflows wachsen Status für Status, bis sie niemand mehr erklären kann, und derselbe Vorgangstyp verhält sich in verschiedenen Teams unterschiedlich. Wenn wir die Auslieferung im Rahmen gemanagter Product-Engineering-Teams übernehmen, gehört das Aufräumen des Jira-Workflows für die Softwareentwicklung meist zu den Aufgaben der ersten zwei Wochen, weil jede spätere Kennzahl davon abhängt.

Dieser Leitfaden erklärt, was ein Jira-Workflow ist, welcher Workflow zu den meisten Softwareteams passt, fünf Beispiele zum Übernehmen, wie Sie einen Workflow einrichten, wie Sie Übergänge aus GitHub, GitLab oder Bitbucket automatisieren und welche Best Practices und Fehler darüber entscheiden, ob Jira Ihnen hilft oder Sie ausbremst. Er gilt für Jira Cloud und Jira Data Center.

Was ist ein Jira-Workflow für die Softwareentwicklung?

Ein Jira-Workflow ist die Menge der Status, die ein Vorgang annehmen kann, und der Übergänge (Transitions), die ihn zwischen diesen Status bewegen. In der Softwareentwicklung bildet er den Lebenszyklus eines Arbeitspakets ab: vom Backlog über Programmierung, Code-Review und Test bis zum Release. Jedes Jira-Projekt nutzt einen Workflow – ob das Team ihn selbst entworfen oder den Standard übernommen hat.

Der Workflow ist nicht das Board. Der Workflow legt fest, welche Zustände es gibt und welche Wechsel erlaubt sind; das Board ist eine Ansicht, die diese Status Spalten zuordnet. Sie können mehrere Boards auf einem Workflow betreiben und Status in einer Spalte ausblenden oder zusammenfassen, ohne den zugrunde liegenden Workflow zu ändern.

Die Bausteine eines Jira-Workflows

Jeder Jira-Workflow besteht aus sechs Komponenten. Wer sie versteht, entwirft deutlich leichter einen sauberen Workflow.

Unternehmensverwaltete Projekte (company-managed) stellen Bedingungen, Validatoren und Post Functions direkt bereit. Teamverwaltete Projekte (team-managed) bieten einfachere Übergangsregeln zum Einschränken, Validieren und Auslösen von Aktionen. Beide lassen sich mit Jira Automation erweitern.

Workflow-Schemata und Vorgangstypen

Ein Workflow-Schema ordnet innerhalb eines Projekts Vorgangstypen bestimmten Workflows zu. So kann ein Projekt einen Workflow für Stories und Aufgaben und einen anderen für Bugs nutzen. Ein gemeinsames Schema über mehrere Projekte hinweg ist das wichtigste Werkzeug, um viele Teams konsistent zu halten – dazu mehr im Abschnitt zur Skalierung weiter unten.

Welcher Jira-Workflow ist der beste für die Softwareentwicklung?

Der beste Jira-Workflow für die Softwareentwicklung ist der einfachste, der dennoch zeigt, wo Arbeit wartet. Für die meisten Produktteams bedeutet das sechs Status: Backlog, Selected for Development, In Progress, In Review, In QA und Done. Jeder Status beantwortet genau eine Frage zur Arbeit, und jeder hat einen Verantwortlichen und eine Ausstiegsregel, auf die sich alle geeinigt haben.

Zwei Regeln lassen diesen Workflow funktionieren. Erstens: Erlauben Sie Rückwärtsschritte – Review und QA müssen einen Vorgang ohne Admin-Hilfe zurück auf In Progress setzen können. Zweitens: Lassen Sie „Blocked“ aus der Statusliste heraus und nutzen Sie stattdessen ein Flag. Ein Blocked-Status verschleiert, wo die Arbeit stand, als sie ins Stocken geriet; ein Flag belässt den Vorgang in seiner echten Spalte und macht das Problem trotzdem sichtbar.

Wie viele Status sollte ein Jira-Workflow haben?

Ein typisches Softwareteam braucht 5–7 Status. Weniger als fünf verbergen meist Review oder Test, sodass Arbeit tagelang „in Bearbeitung“ aussieht, ohne dass erkennbar ist, warum. Mehr als sieben bedeuten meist Status, die Personen oder Abteilungen beschreiben statt des Zustands der Arbeit. Ein nützlicher Test: Kann das Team einen Status nicht in einem Satz erklären oder lag im letzten Monat kein Vorgang darin, entfernen Sie ihn.

5 Jira-Workflow-Beispiele für die Softwareentwicklung

Unterschiedliche Arten von Arbeit brauchen leicht unterschiedliche Abläufe, sollten aber dasselbe Grundgerüst teilen. Diese fünf Jira-Workflow-Beispiele decken nahezu jedes Softwareteam ab; übernehmen Sie das, das Ihrem Prozess am nächsten kommt, und passen Sie nur an, was Sie begründen können.

1. Basis-Workflow für kleine Teams

To Do → In Progress → In Review → Done. Das kommt dem Jira-Standard nahe und funktioniert für Teams mit zwei bis fünf Entwicklern, die ihren Code selbst testen oder hinter Feature-Flags ausliefern. Fügen Sie einen QA-Status hinzu, sobald ein eigener Tester dazukommt – sonst wird das Testen unsichtbar.

2. Scrum-Workflow

Backlog → Selected for Development → In Progress → In Review → In QA → Done. Der Sprint-Umfang liegt in Selected for Development, und das Sprint-Board zeigt die vier Arbeitsstatus. Burndown- und Velocity-Reports setzen voraus, dass Done „erfüllt die Definition of Done“ bedeutet – lassen Sie Vorgänge daher nie vor der QA auf Done gelangen. Unser Leitfaden zur Scrum-Softwareentwicklung beschreibt die Rollen und Events hinter diesem Ablauf.

3. Kanban-Workflow

Backlog → Ready → In Progress → Review → Testing → Ready to Release → Done. Kanban-Teams geht es um den Fluss, deshalb fügen sie einen Puffer „Ready to Release“ hinzu und setzen WIP-Limits auf Board-Spalten, etwa drei Vorgänge pro Entwickler in Bearbeitung. Durchlaufzeit (Cycle Time) und das kumulative Flussdiagramm werden zu den wichtigsten Gesundheitssignalen. Hinweise zu WIP-Limits finden Sie unter Kanban-Softwareentwicklung.

4. Workflow für das Bug-Tracking

Open → Triaged → In Progress → In Review → Verified → Closed, mit Lösungen wie Fixed, Duplicate, Cannot Reproduce und Won’t Fix. Der zusätzliche Schritt Triaged stellt sicher, dass jemand Schweregrad und Reproduzierbarkeit prüft, bevor ein Entwickler den Bug übernimmt. Verified sollte vom Melder oder von der QA gesetzt werden, nicht von dem Entwickler, der den Fehler behoben hat.

5. Feature- und Release-Workflow mit UAT

Idea → Discovery → Ready → In Development → In QA → UAT → Released. Dieser Ablauf eignet sich für Epics oder kundenrelevante Features, bei denen ein fachlicher Verantwortlicher die Abnahme erteilt. Er läuft häufig auf Epic-Ebene, während die Stories darin den Scrum- oder Kanban-Ablauf nutzen. Der UAT-Schritt entspricht dem Prozess aus unserem Leitfaden zum User Acceptance Testing.

Jira-Workflow für die Softwareentwicklung in 8 Schritten einrichten

Die Konfiguration eines Jira-Workflows dauert einen Nachmittag, sollte aber mit einer Stunde am Whiteboard beginnen. Entwerfen Sie den Ablauf zuerst gemeinsam mit dem Team auf Papier, bauen Sie ihn dann in Jira und testen Sie ihn an einigen echten Vorgängen, bevor alle umsteigen.

1. Den echten Prozess abbilden. Fragen Sie das Team, wie eine Story heute tatsächlich durchläuft – einschließlich der Stellen, an denen sie wartet. Notieren Sie jede Übergabe: Entwickler an Reviewer, Reviewer an QA, QA an Release.
2. Status wählen, nicht Personen. Benennen Sie jeden Status nach dem Zustand der Arbeit („In Review“), niemals nach einer Person oder einem Team („Bei Anna“, „Backend“). Zielen Sie auf 5–7.
3. Statuskategorien zuweisen. Ordnen Sie jeden Status To Do, In Progress oder Done zu. Reports, Roadmaps und die Farbe des Vorgangs hängen davon ab.
4. Die Übergänge festlegen. Erlauben Sie jeden benötigten Vorwärtsschritt und die Rückwärtsschritte für Nacharbeit. Vermeiden Sie „jeder Status zu jedem Status“ – außer für einen Reset, der nur Admins vorbehalten ist.
5. Nur die nötigen Regeln hinzufügen. Typisch sind: ein Validator, der vor In Review einen verknüpften Pull Request verlangt, eine Bedingung, nach der nur die QA auf Done setzen darf, und eine Post Function, die bei Done die Lösung setzt und beim Wiedereröffnen löscht.
6. Das Workflow-Schema anlegen oder aktualisieren. Ordnen Sie Stories, Aufgaben und Unteraufgaben dem Haupt-Workflow und Bugs dem Bug-Workflow zu, falls Sie einen nutzen. Veröffentlichen Sie das Schema zuerst in einem Testprojekt.
7. Das Board konfigurieren. Ordnen Sie Status den Spalten zu, setzen Sie bei Kanban WIP-Limits und fügen Sie Schnellfilter wie „Flagged“ oder „Mir zugewiesen“ hinzu.
8. Pilotieren, dann ausrollen. Fahren Sie einen Sprint mit einem Team auf dem neuen Workflow, sammeln Sie Reibungspunkte, beheben Sie sie und migrieren Sie erst dann weitere Projekte. Schreiben Sie einen einseitigen Leitfaden, der jeden Status und jede Ausstiegsregel erklärt.

Wie sollte ein Jira-Workflow mit Git, Code-Review und CI/CD verbunden sein?

Ein Jira-Workflow für die Softwareentwicklung sollte von Entwicklungsereignissen gesteuert werden, nicht von manuellem Verschieben. Wenn Branches, Pull Requests, Builds und Deployments Vorgänge automatisch aktualisieren, bleibt das Board aktuell und die Entwickler bleiben in ihrem Editor.

• Alles über den Vorgangsschlüssel verknüpfen. Setzen Sie den Schlüssel, zum Beispiel PAY-142, in Branch-Namen, Commit-Nachrichten und Pull-Request-Titel. Jira zeigt dann im Vorgang das Entwicklungspanel mit Branches, Commits, Pull Requests, Builds und Deployments.
• Smart Commits sparsam einsetzen. Mit Bitbucket und anderen verbundenen Tools aktualisieren Commit-Nachrichten wie PAY-142 #comment fixed rounding oder PAY-142 #time 2h Jira direkt. Auch Übergangsbefehle funktionieren, Automatisierungsregeln lassen sich jedoch leichter steuern.
• GitHub oder GitLab über die offiziellen Apps anbinden. GitHub for Jira und GitLab for Jira Cloud senden Entwicklungsdaten und Deployment-Informationen an Jira, die auch die Deployment-Ansicht und das Release-Tracking speisen.
• Builds und Deployments melden. Wenn CI/CD Build- und Deployment-Status übermittelt, zeigt der Vorgang, ob sein Code auf Staging oder in Produktion ist, und Done kann „deployt“ statt „gemergt“ bedeuten.

Hier trifft der Workflow auch auf Ihre Delivery-Pipeline. Wenn Sie diese Pipeline noch aufbauen, erklärt unser Leitfaden zu CI/CD in der Softwareentwicklung, welche Stufen an Jira zurückmelden sollten.

Welche Übergänge im Jira-Workflow sollten Sie automatisieren?

Automatisieren Sie Übergänge, die auf ein vorhersehbares Ereignis folgen, und belassen Sie menschliches Urteil dort, wo eine Entscheidung nötig ist. Eine gute Faustregel: Passiert der Übergang immer dann, wenn etwas anderes passiert, sollte eine Regel ihn ausführen; muss jemand entscheiden, bleibt er manuell.

Belassen Sie Freigaben, QA-Abnahme und UAT manuell. Die integrierten KI-Funktionen von Atlassian können inzwischen Vorgänge zusammenfassen und nächste Schritte vorschlagen, doch ein Status, der für eine Qualitätsentscheidung steht, sollte weiterhin von der Person gesetzt werden, die dafür verantwortlich ist. Automatisierung wirkt am besten, wenn der Workflow selbst sauber ist; wer einen chaotischen Workflow automatisiert, beschleunigt nur das Chaos.

Best Practices für Jira-Workflows: eine Checkliste mit 7 Punkten

Die besten Jira-Workflows teilen dieselben Gewohnheiten: wenige Status, klare Verantwortlichkeiten und regelmäßige Überprüfung. Nutzen Sie diese Checkliste, wenn Sie einen neuen Workflow entwerfen oder einen alten prüfen.

1. Bleiben Sie bei 5–7 Status und benennen Sie sie nach dem Zustand der Arbeit.
2. Geben Sie jedem Status einen Verantwortlichen und eine Ausstiegsregel, festgehalten im einseitigen Leitfaden des Projekts.
3. Machen Sie Nacharbeit explizit – mit Rückwärtsübergängen statt wiedereröffneter Tickets oder Duplikate.
4. Nutzen Sie Flags und Labels für Nebenzustände wie blockiert, Design benötigt oder wartet auf Kunden, statt zusätzlicher Status.
5. Setzen Sie Lösungen korrekt: Jeder Vorgang in Done braucht eine Lösung, und das Wiedereröffnen muss sie löschen – sonst zählen Reports unfertige Arbeit als erledigt.
6. Teilen Sie ein Workflow-Schema zwischen Teams, die am selben Produkt arbeiten, und erlauben Sie lokale Abweichungen nur auf Board-Ebene.
7. Überprüfen Sie den Workflow jedes Quartal anhand von Durchlaufzeit, Zeit im Status und dem kumulativen Flussdiagramm.

Diese Gewohnheiten zählen, weil Reibung in Tools teuer ist. Der State of Developer Experience Report von Atlassian (2024) ergab, dass 69% der Entwickler acht oder mehr Stunden pro Woche durch Ineffizienzen verlieren – unklare Prozesse und lästige Statuspflege gehören zu dieser Rechnung. Weitere Tracking-Kennzahlen finden Sie in unserem Leitfaden zu KPIs in der Softwareentwicklung und DORA-Benchmarks.

Häufige Fehler in Jira-Workflows und wie Sie sie beheben

Die meisten kaputten Jira-Workflows scheitern auf dieselben wenigen Arten, und für jede gibt es eine einfache Lösung. Die folgende Tabelle listet die Probleme, die wir bei Audits von Kundenprojekten am häufigsten sehen.

Wie skalieren Sie Jira-Workflows über mehrere Teams?

Skalieren Sie Jira-Workflows mit einem gemeinsamen Grundgerüst und lokaler Freiheit nur dort, wo sie das Reporting nicht bricht. Alle Teams, die an einem Produkt arbeiten, sollten dieselben Status und Statuskategorien nutzen, damit eine Portfolio-Ansicht, ein Release-Plan oder ein teamübergreifendes Dashboard überall dasselbe bedeutet.

• Ein Workflow-Schema pro Produktlinie, geteilt von allen zugehörigen Projekten und verantwortet von einem Jira-Admin oder einer kleinen Arbeitsgruppe.
• Ein Projekt mit mehreren Boards, wenn Teams an derselben Codebasis arbeiten: Jedes Team filtert sein Board nach Komponente oder Team-Feld, während der Workflow gemeinsam bleibt.
• Lokale Abweichungen auf Board-Ebene: WIP-Limits, Swimlanes und Schnellfilter können sich pro Team unterscheiden, ohne den Workflow anzutasten.
• Ein Änderungsprozess: Workflow-Änderungen laufen über einen kurzen Antrag mit Begründung, werden in einem Sandbox-Projekt getestet und vor der Einführung angekündigt.
• Regelmäßiges Aufräumen ungenutzter Status, benutzerdefinierter Felder und inaktiver Workflows, die Jira verlangsamen und neue Teammitglieder verwirren.

Dasselbe Prinzip gilt, wenn Sie mit einem externen Delivery-Partner oder einem erweiterten Team arbeiten: Es sollte innerhalb Ihres gemeinsamen Workflows arbeiten, nicht in einem parallelen. Unser Leitfaden zum Management von Softwareentwicklungsteams beschreibt den Arbeitsrhythmus drumherum.

Wie prüfen Sie einen Jira-Workflow? Ein vierteljährlicher Gesundheitscheck

Prüfen Sie einen Jira-Workflow jedes Quartal, indem Sie messen, wo Vorgänge warten – nicht, wie viele Status es gibt. Drei integrierte Reports reichen aus, um die meisten Probleme zu finden, und der gesamte Check dauert etwa eine Stunde.

1. Kumulatives Flussdiagramm. Ein Band, das immer breiter wird, zeigt einen Engpass; ein breiter werdendes In-Review-Band etwa bedeutet, dass Reviews die Engstelle sind.
2. Control Chart oder Cycle-Time-Report. Betrachten Sie den Durchschnitt und die Ausreißer. Vorgänge, die dreimal so lange wie der Durchschnitt brauchen, decken meist unklare Anforderungen oder versteckte Abhängigkeiten auf.
3. Zeit im Status. Status, in denen Vorgänge tagelang ungenutzt liegen, sind Kandidaten für Automatisierung, WIP-Limits oder eine Prozessänderung.
4. Ungenutzte Status und Übergänge. Alles, was im letzten Quartal nicht genutzt wurde, kann entfernt werden.
5. Feedback des Teams. Fragen Sie, welche Übergänge umgangen werden. Workarounds sind das ehrlichste Signal dafür, dass ein Workflow nicht mehr passt.

Das Wichtigste in Kürze

• Ein Jira-Workflow ist eine Menge von Status und Übergängen; das Board ist nur eine Ansicht davon.
• Der beste Jira-Workflow für die Softwareentwicklung hat 5–7 Status, jeder mit einem Verantwortlichen und einer Ausstiegsregel.
• Übernehmen Sie eines von fünf bewährten Mustern: Basis, Scrum, Kanban, Bug-Tracking oder Feature mit UAT.
• Nutzen Sie Flags statt eines Blocked-Status und erlauben Sie immer Rückwärtsübergänge für Nacharbeit.
• Steuern Sie Übergänge mit Jira Automation über Branches, Pull Requests, Builds und Deployments.
• Teilen Sie ein Workflow-Schema zwischen Teams am selben Produkt und überprüfen Sie es jedes Quartal.

FAQ

Veröffentlicht am 30. Oktober 2026. Quellen: Atlassian Support, Arbeiten mit Workflows; Atlassian Support, Smart Commits; Atlassian, Jira Automation; Atlassian, State of Developer Experience Report 2024. Die Workflow-Muster spiegeln die Delivery-Praxis der YuSMP Group wider und sind Empfehlungen, keine Atlassian-Standards.