Jira Bereiche (Projekte) richtig strukturieren – Wann brauche ich einen neuen Bereich und welcher ist der richtige?

Wer eine Jira-Instanz übernimmt, kann häufig bereits an der Anzahl der Bereiche erkennen, wie sich die Plattform entwickelt hat.

In jungen Umgebungen gibt es oft nur wenige Bereiche. Die Struktur ist nachvollziehbar, Verantwortlichkeiten sind klar und jeder weiß, wo neue Vorgänge angelegt werden sollen.

In gewachsenen Instanzen sieht das häufig anders aus. Für jedes Team wurde irgendwann ein eigener Bereich erstellt. Für neue Initiativen ebenfalls. Dann kamen Pilotprojekte, Fachbereiche und individuelle Anforderungen hinzu. Einige Jahre später existieren dutzende oder sogar hunderte Bereiche – viele davon mit nahezu identischen Prozessen und Konfigurationen.

Dabei entsteht die eigentliche Herausforderung meist nicht durch die Anzahl der Vorgänge, sondern durch die Anzahl der Bereiche.

Die Frage „Brauchen wir einen neuen Bereich?“ gehört deshalb zu den wichtigsten Architekturentscheidungen in Jira.

In diesem Beitrag betrachten wir die verschiedenen Bereichsarten, die Unterschiede zwischen Company Managed und Team Managed Bereichen sowie die Frage, wie eine sinnvolle Strukturierung in der Praxis aussehen kann.

Vom Projekt zum Bereich

Mit Jira Cloud hat Atlassian die bisherige Bezeichnung „Projekt“ zunehmend durch den Begriff „Bereich“ ersetzt.

Die Idee dahinter ist nachvollziehbar. Viele Anwender haben bei einem Projekt automatisch an ein zeitlich begrenztes Vorhaben gedacht. Tatsächlich werden in Jira jedoch längst nicht nur Projekte verwaltet.

Typische Beispiele sind:

• Produkte

• Services

• Supportorganisationen

• Abteilungen

• Plattformen

• kontinuierliche Verbesserungsprozesse

Der Begriff Bereich beschreibt daher besser, was diese Einheit in Jira tatsächlich darstellt: einen organisatorischen und konfigurativen Container für Arbeit.

Wer den grundsätzlichen Aufbau von Jira besser verstehen möchte, sollte sich zunächst mit der zugrundeliegenden Objekt- und Konfigurationsstruktur beschäftigen. Viele Entscheidungen rund um Bereiche werden verständlicher, wenn man die Zusammenhänge zwischen Projekten, Workflows, Feldern, Schemes und Berechtigungen kennt.

Weitere Hintergründe dazu finden Sie ind dem Beitrag zum Jira-Strukturaufbau und dem Beitrag zum Jira Service Management Strukturaufbau.

Die richtige Projektart ist wichtig – aber nicht die einzige Entscheidung

Bei der Erstellung eines neuen Bereichs steht zunächst die Auswahl der passenden Projektart an. Diese Entscheidung sollte bewusst getroffen werden, denn sie beeinflusst unmittelbar, welche Funktionen später zur Verfügung stehen.

Die Unterschiede sind keineswegs nur optischer Natur.

Ein Jira Service Management Projekt bringt beispielsweise Funktionen mit, die in Jira oder Jira Software nicht verfügbar sind:

• Serviceportale

• Kundenzugriffe und Kundenkommunikation

• Warteschlangen

• SLA-Messungen

• Formulare

• Genehmigungsprozesse

• Asset-Management-Integration

Wer Serviceprozesse, interne Dienstleistungen oder Supportanfragen abbilden möchte, sollte deshalb frühzeitig prüfen, ob Jira Service Management die bessere Grundlage darstellt.

Umgekehrt bietet Jira Software Funktionen, die speziell für Produkt- und Entwicklungsteams entwickelt wurden:

• Backlogs

• Sprintplanung

• Releases

• Entwicklungsintegrationen

• Agile Planungsfunktionen

Für klassische Projekt-, Aufgaben- oder Fachbereichsprozesse reicht dagegen häufig ein normales Jira-Projekt aus.

Die Wahl der Projektart entscheidet also darüber, welche Werkzeuge und Konzepte grundsätzlich zur Verfügung stehen.

Gleichzeitig beantwortet sie jedoch noch nicht die Frage, ob überhaupt ein neuer Bereich benötigt wird.

In Workshops erleben wir häufig Diskussionen darüber, welches Template ausgewählt werden soll, obwohl die eigentliche Architekturfrage noch gar nicht beantwortet wurde:

Soll die Arbeit in einem bestehenden Bereich stattfinden oder handelt es sich tatsächlich um einen eigenständigen fachlichen Kontext?

Denn auch das technisch passende Projekt kann langfristig zu Problemen führen, wenn für jeden Anwendungsfall ein neuer Bereich angelegt wird.

Die Auswahl der richtigen Projektart und die Entscheidung für oder gegen einen neuen Bereich gehören daher immer zusammen.

Erst wenn beide Fragen beantwortet sind, entsteht eine Struktur, die sowohl fachlich als auch technisch langfristig tragfähig ist.

Welche Bereichsarten gibt es überhaupt?

Viele Anwender nehmen die unterschiedlichen Vorlagen in Jira zunächst als rein optische Unterschiede wahr. Tatsächlich steckt jedoch deutlich mehr dahinter.

Die verfügbaren Bereichsarten orientieren sich an unterschiedlichen Arbeitsweisen und Anwendungsfällen.

Jira Bereiche

Jira (früher Jira Core und später Jira Work Management) richtet sich vor allem an Fachbereiche und Teams, die ihre Arbeit strukturieren und nachverfolgen möchten, ohne die typischen Funktionen eines Entwicklungsteams oder Service Desks zu benötigen.

Typische Einsatzgebiete sind:

• Task Management in Fachbereichen

• Projektmanagement

• Organisations- und Verwaltungsprozesse

• Einfaches Projektmanagement

Im Mittelpunkt stehen klassische Aufgaben- und Prozessabläufe. Viele Teams nutzen Jira beispielsweise zur Steuerung von Kampagnen, Freigaben, Beschaffungen oder internen Projekten.

Im Vergleich zu Jira Software fehlen hier Funktionen wie Sprintplanung oder Software-Releases. Gleichzeitig ist die Oberfläche häufig stärker auf die tägliche operative Arbeit von Fachbereichen ausgerichtet.

Aus technischer Sicht basiert Jira jedoch auf derselben Plattform wie Jira Software. Viele Konfigurationsmöglichkeiten, Workflows, Felder und Automatisierungen funktionieren identisch.

Jira Bereiche mit Software-Funktionen

Jira (früher Jira Software) Bereiche mit Software-Funktionen sind der klassische Bereich für Produkt-, Projekt- und Entwicklungsteams.

Typische Einsatzgebiete sind:

• Softwareentwicklung

• Produktmanagement

• Projektmanagement

• Agile Teams

• Kanban-Organisationen

Die zentrale Idee besteht darin, Arbeit zu planen, zu priorisieren und über längere Zeiträume zu steuern.

Dementsprechend stehen Funktionen wie folgende im Mittelpunkt:

• Backlogs

• Sprintplanung

• Releases

• Roadmaps

• Entwicklungsintegrationen

In vielen Unternehmen wird Jira Software heute längst nicht mehr ausschließlich von Entwicklungsteams genutzt. Auch PMOs, Produktorganisationen oder Transformationsprojekte setzen bewusst auf Jira Software, um von den erweiterten Planungsfunktionen zu profitieren.

Jira Service Management Bereiche

Jira Service Management verfolgt einen anderen Ansatz. Hier wird Arbeit nicht primär geplant, sondern angefragt.

Deshalb stehen andere Funktionen zur Verfügung:

• Serviceportale

• Kundenkommunikation (Portal und Mail)

• Formulare

• Warteschlangen

• SLA-Messungen

• Genehmigungen

• Wissensdatenbanken

• Asset Management

Typische Einsatzgebiete sind:

• IT Service Management

• HR Services

• Facility Management

• Kundenservice

• Interne Shared Services

Ein häufiger Fehler besteht darin, Support- oder Serviceprozesse in Jira Software abzubilden, obwohl die Anforderungen eigentlich klar in Richtung Service Management gehen. Ist beispielsweise eine Kundenkommunikation gewünscht, führt i.d.R. kein (sinnvoller) Weg an einem Service Management vorbei.

Warum gibt es überhaupt unterschiedliche Bereichsarten?

Aus technischer Sicht erfüllen die verschiedenen Bereichsarten drei Aufgaben.

Unterschiedliche Arbeitsmodelle

Ein Scrum-Team arbeitet anders als ein Servicedesk.

Ein Produktteam priorisiert Anforderungen.

Ein Serviceteam bearbeitet eingehende Anfragen.

Die verfügbaren Funktionen orientieren sich an diesen Arbeitsweisen.

Unterschiedliche Konfigurationen

Nicht jede Funktion ist in jedem Bereichstyp verfügbar.

Ein Jira Software Bereich benötigt beispielsweise keine SLAs.

Ein Service Management Bereich benötigt dagegen keine Sprintplanung.

Unterschiedliche Lizenzmodelle

Auch aus Lizenzsicht unterscheiden sich die Produkte.

Die verfügbaren Funktionen, Rollen und Benutzergruppen orientieren sich an den jeweiligen Anwendungsfällen.

Brauchen wir überhaupt einen neuen Bereich?

In vielen Unternehmen wird diese Frage erstaunlich selten gestellt.

Stattdessen wird ein neuer Bereich angelegt, sobald ein neues Team entsteht.

Genau an dieser Stelle entstehen jedoch viele spätere Probleme.

Ein Team ist nicht automatisch ein Bereich.

Eine Abteilung ist nicht automatisch ein Bereich.

Und auch ein neues Projekt benötigt nicht zwangsläufig einen eigenen Bereich.

Stattdessen sollte zunächst geprüft werden, ob tatsächlich ein eigenständiger organisatorischer oder fachlicher Kontext vorliegt.

Aus unserer Erfahrung rechtfertigen meist nur drei Gründe einen neuen Bereich.

1. Ein anderer Prozess

Wenn ein Team einen deutlich anderen Workflow benötigt, kann ein eigener Bereich sinnvoll sein.

Beispiele:

• Softwareentwicklung

• Incident Management

• HR-Anfragen

• Beschaffungsprozesse

Diese Prozesse unterscheiden sich häufig so stark, dass eine gemeinsame Abbildung unpraktisch wird.

2. Andere Berechtigungen

Wenn Informationen besonders geschützt werden müssen, spricht dies häufig für einen eigenen Bereich.

Typische Beispiele:

• Personalprozesse

• Managementanfragen

• Audit-Themen

• Compliance-Prozesse

3. Ein eigenständiger Service

Im Service Management ist dies besonders häufig der Fall.

Ein HR-Service und ein IT-Service besitzen:

• unterschiedliche Kunden

• unterschiedliche Formulare

• unterschiedliche SLAs

• unterschiedliche Verantwortliche

Hier ist eine Trennung meist sinnvoll.

Wann sollte kein neuer Bereich angelegt werden?

Diese Frage ist oft deutlich spannender.

Viele Anforderungen lassen sich innerhalb bestehender Bereiche lösen.

Zum Beispiel über:

Boards

Unterschiedliche Teams benötigen häufig lediglich unterschiedliche Sichten auf dieselben Vorgänge.

Dafür müssen keine neuen Bereiche entstehen.

Komponenten

Komponenten eignen sich hervorragend zur Strukturierung von Produkten, Modulen oder Verantwortlichkeiten innerhalb eines Bereichs.

Vorgangstypen

Nicht jede unterschiedliche Arbeitsart benötigt einen eigenen Bereich.

Häufig reicht ein zusätzlicher Vorgangstyp aus.

Filter

Viele Auswertungs- und Sichtbarkeitsanforderungen lassen sich bereits durch geeignete Filter lösen.

Rollen und Berechtigungen

Auch Zugriffsanforderungen können häufig innerhalb bestehender Bereiche umgesetzt werden.

Ein zusätzlicher Bereich sollte also nicht immer direkt, sondern erst nach Bewertung der genannten Faktoren erstellt werden.

Company Managed oder Team Managed?

Kaum eine Entscheidung wird in Jira Cloud häufiger diskutiert.

Beide Ansätze haben ihre Berechtigung.

Die langfristigen Auswirkungen unterscheiden sich jedoch erheblich.

Team Managed Bereiche

Team Managed Bereiche wurden eingeführt, damit Teams unabhängig arbeiten können.

Sie können eigenständig:

• Felder anlegen

• Workflows anpassen

• Vorgangstypen verwalten

• Konfigurationen verändern

Ohne Beteiligung eines Jira-Administrators.

Das funktioniert insbesondere bei kleinen Teams sehr gut.

Für Pilotprojekte oder schnelle Prototypen kann dies ein großer Vorteil sein.

Die Herausforderungen von Team Managed

Die Probleme entstehen selten am ersten Tag.

Sie entstehen häufig zwei oder drei Jahre später.

Dann existieren beispielsweise:

• mehrere Felder mit identischer Bedeutung

• unterschiedliche Statusmodelle

• verschiedene Namenskonventionen

• uneinheitliche Berichte

Die Ursache liegt nicht in falscher Nutzung, sondern in der fehlenden Standardisierung.

Company Managed Bereiche

Company Managed Bereiche verfolgen einen anderen Ansatz.

Konfigurationen werden zentral verwaltet und können von mehreren Bereichen gemeinsam genutzt werden.

Dazu gehören beispielsweise:

• Workflows

• Felder

• Screens

• Berechtigungsschemata

• Benachrichtigungsschemata

Der initiale Aufwand ist häufig etwas höher.

Dafür entstehen langfristig deutlich weniger Wartungs- und Governance-Probleme.

Unsere Empfehlung aus der Praxis

Für die meisten Unternehmensumgebungen ist Company Managed die bessere Wahl.

Team Managed Bereiche eignen sich vor allem für:

• Pilotprojekte

• temporäre Initiativen

• autonome Teams mit geringem Integrationsbedarf

Sobald mehrere Teams zusammenarbeiten oder bereichsübergreifende Auswertungen benötigt werden, überwiegen meist die Vorteile zentral verwalteter Bereiche.

Was kann innerhalb eines Bereichs konfiguriert werden?

Viele Anwender unterschätzen, wie viel Flexibilität bereits innerhalb eines einzelnen Bereichs möglich ist.

Typische bereichsspezifische Konfigurationen sind:

• Boards

• Automatisierungen

• Rollen

• Komponenten

• Versionen

• Formulare

• Dashboards

• Serviceportale

• Warteschlangen

• SLA-Konfigurationen

Nicht jede Anforderung benötigt daher automatisch eine neue Struktur.

Wie schneidet man Bereiche sinnvoll?

Eine Frage begegnet uns in Workshops regelmäßig:

„Sollen wir pro Team einen Bereich anlegen?“

Die Antwort lautet meistens: Nein.

Teams verändern sich.

Abteilungen werden umorganisiert.

Verantwortlichkeiten wechseln.

Produkte und Services sind häufig deutlich stabiler.

Deshalb hat sich in vielen Organisationen folgende Struktur bewährt:

Nicht nach Teams strukturieren:

• Team A

• Team B

• Team C

Sondern nach fachlichen Einheiten:

• Produkt A

• Produkt B

• Kundenportal

• IT Service

• HR Service

Die Struktur orientiert sich damit an der Wertschöpfung und nicht an der aktuellen Organisationsstruktur.

Fünf Strukturierungsfehler, die wir regelmäßig sehen

Die meisten Herausforderungen in Jira entstehen nicht durch fehlende Funktionen, sondern durch Strukturentscheidungen, die zu Beginn sinnvoll erschienen und später zur Belastung werden.

Fehler	Problem
Ein Bereich pro Team	Orientierung an Organisation statt Fachlichkeit
Für jedes Vorhaben ein neuer Bereich	Bereichs-Explosion
Team Managed als Standard	Fehlende Governance
Serviceprozesse in Jira statt JSM	Falsche Plattformwahl
Bereiche als Berechtigungskonzept	Technische Trennung statt sinnvoller Zugriffsteuerung

Diese fünf Muster begegnen uns in der Beratung, Optimierungsprojekten und Jira-Einführungen immer wieder, daher betrachten wir diese Themen einmal im Detail:

1. Ein Bereich pro Team

„Das Entwicklungsteam bekommt einen Bereich, das Marketingteam einen weiteren und der Support ebenfalls.“

Was zunächst logisch erscheint, führt häufig zu Problemen, sobald Teams umorganisiert werden oder gemeinsam an Produkten und Services arbeiten. Teams verändern sich, Produkte und Services dagegen meist deutlich seltener.

Unsere Empfehlung: Bereiche möglichst nach fachlichen Einheiten wie Produkten, Services oder Wertströmen strukturieren – nicht nach der aktuellen Organisationsstruktur.

2. Für jedes Projekt einen neuen Bereich

Besonders in Jira Cloud ist ein neuer Bereich schnell erstellt. Dadurch entsteht oft die Versuchung, für jedes Vorhaben einen eigenen Bereich anzulegen.

Nach einigen Jahren existieren dann zahlreiche Bereiche mit identischen Workflows, Feldern und Berechtigungen – lediglich der Name unterscheidet sich.

Unsere Empfehlung: Prüfen, ob das Vorhaben nicht innerhalb eines bestehenden Bereichs über Komponenten, Vorgangstypen, Labels oder Boards abgebildet werden kann.

3. Team Managed als Standard einsetzen

Team Managed Bereiche ermöglichen einen schnellen Start und viel Flexibilität. Genau deshalb werden sie häufig zum Standard erklärt.

Die Kehrseite zeigt sich oft erst später: ähnliche Felder werden mehrfach angelegt, Prozesse entwickeln sich auseinander und bereichsübergreifendes Reporting wird zunehmend aufwendiger.

Unsere Empfehlung: Team Managed gezielt für Pilotprojekte oder autonome Teams einsetzen. Für langfristig genutzte Unternehmensprozesse ist Company Managed häufig die nachhaltigere Wahl.

4. Serviceprozesse in Jira statt Jira Service Management abbilden

Viele Unternehmen starten Support- oder Serviceprozesse in einem klassischen Jira-Bereich, weil dieser bereits vorhanden ist.

Spätestens bei Anforderungen wie Serviceportalen, Kundenkommunikation, SLAs, Warteschlangen oder Kundenzugriffen stößt dieser Ansatz jedoch an seine Grenzen.

Unsere Empfehlung: Frühzeitig prüfen, ob es sich tatsächlich um einen Serviceprozess handelt. In diesem Fall bietet Jira Service Management meist die bessere Grundlage.

5. Bereiche als Berechtigungskonzept missbrauchen

Das sehen wir überraschend häufig.

Ein neuer Bereich wird angelegt, weil bestimmte Nutzergruppen nur einen Teil der Vorgänge sehen sollen. Dabei existieren bereits zahlreiche Möglichkeiten, Sichtbarkeit und Zugriffe innerhalb eines Bereichs zu steuern.

Die Folge sind zusätzliche Bereiche, die fachlich eigentlich zusammengehören, technisch aber getrennt verwaltet werden müssen.

Typische Beispiele:

• Interne und externe Teams arbeiten in getrennten Bereichen.

• Lieferanten erhalten einen eigenen Bereich.

• Einzelne Fachabteilungen werden ausgelagert.

Oft entsteht dadurch mehr Komplexität als Nutzen.

Unsere Empfehlung: Zuerst prüfen, ob Rollen, Berechtigungsschemata, Issue Security Levels oder JSM-Portale die Anforderung bereits lösen können. Ein neuer Bereich sollte nur entstehen, wenn tatsächlich eine fachliche oder organisatorische Trennung erforderlich ist.

Fazit

Bereiche gehören zu den wichtigsten Architekturentscheidungen innerhalb einer Jira-Instanz.

Sie beeinflussen Berechtigungen, Prozesse, Berichte, Automatisierungen und die langfristige Wartbarkeit der gesamten Plattform.

Wer für jede organisatorische Änderung einen neuen Bereich anlegt, schafft kurzfristig Ordnung, erhöht aber langfristig die Komplexität.

In der Praxis hat sich deshalb ein einfacher Grundsatz bewährt:

Ein neuer Bereich sollte entstehen, wenn ein eigenständiger Prozess, ein eigenständiger Service oder besondere Berechtigungsanforderungen dies notwendig machen.

Für unterschiedliche Sichten auf dieselbe Arbeit reichen häufig bereits Boards, Filter, Komponenten oder Rollen aus.

Die eigentliche Herausforderung besteht daher nicht darin, einen neuen Bereich anzulegen.

Die Herausforderung besteht darin, genau zu wissen, wann man darauf verzichten sollte.