Anforderungen mit Jira oder Azure DevOps verwalten – (k)eine gute Idee?

Anforderungen professionell verwalten ist kein optionaler Prozess

Ein verbreitetes Missverständnis lautet: „Wir machen kein Anforderungsmanagement.“ In der Realität ist das kaum jemals der Fall. Anforderungen entstehen in jedem Entwicklungsprojekt, unabhängig davon, ob sie formal so genannt werden oder nicht. Sie entstehen in Gesprächen mit Stakeholdern, in E-Mails, in Präsentationen, in Lasten- oder Pflichtenheften, in Tickets oder in Excel-Listen.

Auch ein Jira-Ticket mit der Beschreibung „Das System soll X tun“ ist nichts anderes als eine Anforderung. Die eigentliche Frage lautet daher nicht, ob Anforderungen existieren, sondern wie gut sie strukturiert, nachvollziehbar und belastbar dokumentiert sind. Genau an diesem Punkt entscheidet sich, ob ein Projekt langfristig stabil bleibt oder zunehmend ins Schwimmen gerät.

‍

Der ursprüngliche Zweck von Jira und Azure DevOps

Jira und Azure DevOps wurden nicht als Werkzeuge konzipiert, die Anforderungen professionell verwalten sollen. Ihr Ursprung liegt klar in der Organisation von Arbeit und Umsetzung. Sie sollen Teams dabei unterstützen, Aufgaben zu planen, Fortschritt sichtbar zu machen und Entwicklung effizient zu steuern. Tickets, Backlogs, Sprints, Boards und Workflows bilden dafür eine sehr leistungsfähige Grundlage.

Diese Stärke ist zugleich ihre größte Schwäche im Kontext der professionellen Anforderungsverwaltung. Denn Anforderungen sind nicht primär Arbeitseinheiten, sondern fachliche Festlegungen. Sie beschreiben, was ein System leisten soll, nicht, wie oder wann jemand daran arbeitet. Sobald diese Unterscheidung verwischt, entstehen Probleme, die zunächst klein wirken, sich aber über die Zeit massiv verstärken.

‍

Der pragmatische Einstieg und warum er oft überzeugt

In der frühen Phase eines Projekts wirkt der Einsatz von Jira oder Azure DevOps für Anforderungen oft überzeugend. Alles ist an einem Ort, die Teams kennen das Tool, und es entsteht schnell das Gefühl von Ordnung und Transparenz. Anforderungen lassen sich als Tickets erfassen, priorisieren und einem Sprint zuordnen. Fortschritt ist sichtbar, Diskussionen finden direkt am Ticket statt.

Gerade für kleine Teams oder frühe Produktphasen kann dieser Ansatz durchaus funktionieren. Er reduziert Hürden und ermöglicht einen schnellen Start. Problematisch wird es jedoch dann, wenn aus diesem pragmatischen Einstieg ein dauerhafter Standard wird, ohne zu hinterfragen, ob das Tool mit den wachsenden Anforderungen Schritt halten kann.

‍

Wenn Anforderungen ihre Rolle verlieren

Mit zunehmender Projektlaufzeit wächst die Zahl der Einträge im System. Neue Anforderungen kommen hinzu, bestehende werden angepasst, ergänzt oder relativiert. Gleichzeitig entstehen technische Aufgaben, Bugfixes, Refactorings und organisatorische Tätigkeiten. All das landet im selben System und häufig sogar im selben Artefakttyp.

Spätestens jetzt wird es schwierig, die fachliche Bedeutung einzelner Einträge klar einzuordnen. Was ist eine verbindliche Anforderung? Was ist eine Ableitung? Was ist lediglich eine Idee oder ein technischer Umsetzungsschritt? Zwar lassen sich diese Unterschiede theoretisch über Issue-Typen oder Felder modellieren, doch in der Praxis werden sie oft inkonsistent genutzt.

Die Folge ist ein schleichender Bedeutungsverlust von Anforderungen. Sie werden zu einem Ticket unter vielen, austauschbar, veränderbar, ohne klaren Status. Entscheidungen werden nicht mehr explizit getroffen, sondern implizit im Rahmen von Sprint-Planungen oder Ticket-Kommentaren.

‍

Fehlende Semantik in Beziehungen

Ein zentrales Element bei der professionellen Verwaltung von Anforderungen ist die klare Beschreibung von Zusammenhängen. Anforderungen entstehen nicht isoliert, sondern bauen aufeinander auf. Sie werden aus Stakeholder-Bedürfnissen abgeleitet, in Systemanforderungen überführt, weiter verfeinert und schließlich durch Tests überprüft.

In Jira und Azure DevOps lassen sich zwar Verknüpfungen zwischen Einträgen herstellen, doch diese bleiben bewusst allgemein. Eine Verlinkung sagt lediglich aus, dass zwei Elemente miteinander verbunden sind. Sie sagt jedoch nichts darüber aus, ob eine Anforderung aus einer anderen abgeleitet wurde, ob sie diese konkretisiert oder ob sie zu deren Verifikation dient.

Diese fehlende Semantik ist kein Detailproblem, sondern ein strukturelles Defizit. Denn ohne klar definierte Beziehungen kann ein Tool nicht unterstützen, wenn es wirklich darauf ankommt, etwa bei der Analyse von Änderungen oder bei der Beantwortung der Frage, welche Teile eines Systems von einer Anpassung betroffen sind.

‍

Änderungen ohne belastbare Impact-Analyse

Änderungen gehören zum Alltag jeder Produktentwicklung. Sie sind weder ungewöhnlich noch per se problematisch. Entscheidend ist, wie gut sie beherrscht werden. Jira und Azure DevOps dokumentieren Änderungen zuverlässig auf Ticket-Ebene. Sie zeigen, wann etwas angepasst wurde und wer beteiligt war.

Was sie jedoch kaum leisten können, ist eine strukturierte Impact-Analyse über mehrere Ebenen hinweg. Welche anderen Anforderungen sind betroffen? Welche Tests müssen angepasst werden? Welche Entscheidungen stehen infrage? Diese Fragen lassen sich zwar theoretisch beantworten, praktisch erfordern sie jedoch viel manuelle Denkarbeit und detailliertes Erfahrungswissen.

Je komplexer das Produkt wird, desto größer wird das Risiko, dass Auswirkungen übersehen werden. Fehler entstehen dann nicht durch mangelnde Sorgfalt, sondern durch fehlende strukturelle Unterstützung.

‍

Die zunehmende Fragmentierung der Informationsbasis

Ein weiterer Effekt zeigt sich häufig im Umgang mit Dokumentation. Anforderungen werden im Ticketsystem gepflegt, während Spezifikationen, Architekturbeschreibungen oder normative Bezüge in separaten Dokumenten oder Wikis liegen. Tests werden wiederum in anderen Werkzeugen verwaltet, Freigaben per E-Mail erteilt.

Diese Fragmentierung ist kein Zeichen schlechter Organisation, sondern eine direkte Folge davon, dass Jira und Azure DevOps nicht darauf ausgelegt sind, alle diese Aspekte integriert abzubilden. Mit der Zeit wird es immer schwieriger, den „Single Source of Truth“ zu identifizieren. Unterschiedliche Informationsstände existieren parallel, und Abstimmungsaufwand ersetzt systematische Klarheit.

‍

Wann Jira oder Azure DevOps dennoch ausreichend sein können

Trotz dieser Kritik wäre es falsch, Jira oder Azure DevOps pauschal als ungeeignet darzustellen. In bestimmten Szenarien können sie durchaus ausreichen. Dazu zählen etwa kleine, eingespielte Teams mit kurzen Entwicklungszyklen, überschaubaren Produkten und geringen regulatorischen Anforderungen.

In solchen Kontexten ist der pragmatische Umgang mit Anforderungen oft effizienter als ein formal stark ausgeprägter Prozess. Entscheidend ist jedoch, dass allen Beteiligten bewusst ist, dass sie sich damit für einen Kompromiss entscheiden und nicht für professionelles Anforderungsmanagement im engeren Sinne.

‍

Der Punkt, an dem es kritisch wird

Sobald Projekte wachsen, mehrere Abstraktionsebenen notwendig werden oder Anforderungen über längere Zeiträume stabil bleiben müssen, stoßen Jira und Azure DevOps an ihre Grenzen. Der organisatorische Aufwand steigt, Zusammenhänge werden unübersichtlich, und die Abhängigkeit von einzelnen Schlüsselpersonen nimmt zu.

An diesem Punkt kippt der Nutzen. Das Tool, das ursprünglich helfen sollte, wird zur Belastung. Nicht, weil es schlecht konfiguriert ist, sondern weil es für diese Aufgabe nie gedacht war.

‍

Trennung von Anforderungen und Umsetzung als bewährtes Muster

Viele Organisationen reagieren darauf mit einem klaren Schnitt. Anforderungen werden in spezialisierten Anforderungsmanagement-Werkzeugen gepflegt, das Struktur, Semantik und Nachvollziehbarkeit sicherstellt. Jira oder Azure DevOps bleiben weiterhin zentrale Werkzeuge für Planung und Umsetzung.

Diese Trennung ist kein Rückschritt, sondern ein Zeichen von Reife. Sie erlaubt es, Anforderungen stabil zu halten und gleichzeitig die Umsetzung flexibel zu gestalten. Beide Systeme erfüllen klar definierte Aufgaben und werden gezielt miteinander gekoppelt, statt ihre Grenzen gegenseitig zu überdecken.

‍

Fazit: Eine gute Idee oder nicht?

Anforderungsmanagement mit Jira oder Azure DevOps kann kurzfristig funktionieren und in bestimmten Kontexten ausreichend sein. Als dauerhafte Grundlage für systematisches, belastbares Requirements Engineering sind diese Tools jedoch konzeptionell nicht ausgelegt.

Die entscheidende Frage lautet daher nicht, ob man Anforderungen damit verwalten kann, sondern wie dieser Ansatz noch trägt, bevor er zum Risiko wird. Wer diese Frage ehrlich beantwortet, erkennt meist sehr klar, wann es Zeit ist, die Werkzeuge neu zu denken.

‍