Azure DevOps ist die Plattform, auf der Software entwickelt und ausgeliefert wird. Boards verwalten den Backlog, Repos beherbergen den Code, Pipelines steuern die Builds, und Test Plans dokumentieren die Validierung. Für viele Entwicklungsteams ist ADO das zentrale Arbeitswerkzeug – vertraut, effizient und tief in den Lieferrhythmus integriert. ADO wurde jedoch für die Auslieferung konzipiert. Sobald Compliance-Anforderungen, Sicherheitsnormen oder teamübergreifende Rückverfolgbarkeitsanforderungen ins Spiel kommen, entsteht eine Lücke: Wie lässt sich verbinden, was Teams in ADO entwickeln, mit den Anforderungen, die dies begründen – und weiter zu den Nachweisen, die Testung und Validierung belegen? Genau deshalb wird Azure DevOps Traceability KI zu einem unverzichtbaren Bestandteil der Arbeitsweise regulierter Entwicklungsteams.

Wenn „Done“ nicht ausreicht

Stellen Sie sich folgendes Szenario vor: Ihr Team arbeitet seit zwei Jahren in Azure DevOps. Die Boards sind mit sorgfältig gepflegten User Stories gefüllt. Pipelines laufen grün. Test Plans sind befüllt. Dann kommt ein ASPICE-Assessment, ein Kunde fordert eine Traceability-Matrix, oder ein Auditor möchte wissen, welche Anforderungen durch welche Tests abgedeckt sind.

In diesem Moment wird deutlich: Work Items in ADO zu haben ist nicht dasselbe wie Traceability zu haben. Teams haben Verknüpfungen zwischen Epics, Features, User Stories und Testfällen inkonsistent angelegt – oder ganz darauf verzichtet. Upstream-Anforderungen wurden nicht formal mit dem ADO-Backlog verbunden. Und niemand kann mit Gewissheit sagen, welche Anforderungen tatsächlich validiert sind.

Wichtig: Dies ist kein Versagen von ADO. Es handelt sich um eine Traceability-Lücke, die die meisten Entwicklungsteams betrifft, die Azure DevOps in regulierten Branchen einsetzen. Es lohnt sich, die Ursachen zu verstehen, bevor man nach Lösungen sucht.

Warum Traceability in Azure DevOps echte Herausforderungen birgt

Azure DevOps wurde für agile Softwarelieferung entwickelt. Es eignet sich hervorragend für Backlog-Management, Sprint-Durchführung und Build-Automatisierung. Eine durchgängige Anforderungsnachverfolgung als erstklassiges Anliegen war jedoch nicht Teil des Designkonzepts – und diese Designentscheidung hat reale Konsequenzen für Teams unter Compliance-Druck.

Delivery-Hierarchie statt Anforderungsfluss

Die Standardhierarchie in ADO – Epic → Feature → User Story → Task – bildet die Zerlegung von Arbeit für die Umsetzung ab, nicht den Fluss von Systemanforderungen bis hin zum Verifikationsnachweis. Eine User Story ist eine Liefereinheit. Sie kann eine Anforderung vollständig, teilweise oder gar nicht abbilden.

In kleinen Projekten mit hoher Disziplin ist das handhabbar. In großen Programmen mit mehreren Teams, hunderten Sprints und tausenden Work Items wird daraus ein strukturelles Problem.

Manuelle Links verlieren an Konsistenz

ADO erlaubt das manuelle Verknüpfen von Work Items. Theoretisch lassen sich User Stories mit Test Cases verbinden und auf Systemanforderungen zurückführen. In der Praxis entstehen jedoch unterschiedliche Konventionen, inkonsistente Pflege und mit wachsendem Lieferdruck sinkende Disziplin.

Das Trace-Netzwerk wirkt in frühen Projektphasen vollständig, fragmentiert jedoch mit zunehmender Skalierung. Vor einem Audit wird die Erstellung einer belastbaren Traceability-Matrix schnell zu einem mehrwöchigen Kraftakt.

Die Werkzeuggrenze

Viele regulierte Programme verwalten Systemanforderungen in spezialisierten ALM-Systemen wie IBM Engineering Requirements Management DOORS Next, Polarion ALM oder Codebeamer, während Implementierung und Test in Azure DevOps erfolgen. Diese Aufteilung ist fachlich sinnvoll – erzeugt jedoch eine Traceability-Lücke an der Systemgrenze.

Ändert sich eine Anforderung im Upstream-ALM-Tool, gibt es in ADO keinen automatischen Mechanismus, der betroffene Work Items als potenziell betroffen kennzeichnet. Impact-Analysen erfolgen – wenn überhaupt – manuell.

---

PRAXISBEISPIEL:  Ein sicherheitskritisches Softwareteam nutzt ADO für die Umsetzung und DOORS NG für das Anforderungsmanagement. Zwei Wochen vor einem ISO 26262-Audit stellt sich heraus, dass 40 % der User Stories keiner Systemanforderung formal zugeordnet sind. Niemand fühlte sich zuständig – alle gingen davon aus, dass die Verlinkung bereits erfolgt sei.

---

Wie gute Traceability in ADO aussieht

Bevor über Werkzeuge gesprochen wird, sollte klar sein, was vollständige Traceability bedeutet.

Vertikale Abdeckung: Von der Anforderung bis zum Test

Jede Systemanforderung benötigt einen nachvollziehbaren Pfad nach unten durch die ADO-Hierarchie zu den Work Items, die sie implementieren, und weiter zu den Testfällen, die sie validieren. Diese vertikale Kette ist das Kernstück jedes Compliance-Arguments: Wir haben eine Anforderung identifiziert, etwas entwickelt, das sie erfüllt, und nachgewiesen, dass es funktioniert.

In ADO bedeutet dies, dass Teams Epics, Features und User Stories formal verknüpfen und diese User Stories mit Testfällen verbinden müssen, die ausgeführte und bestandene Ergebnisse aufweisen.

Horizontale Abdeckung: Über Teams und Sprints hinweg

In Mehrteam-Programmen kann dieselbe Systemanforderung durch mehrere User Stories umgesetzt werden, die auf verschiedene Teams und Sprints verteilt sind. Traceability muss alle diese Beiträge erfassen, nicht nur den jüngsten oder offensichtlichsten. Diese horizontale Dimension ist es, wo manuelle Ansätze am schnellsten versagen.

Änderungsabdeckung: Verdächtige Elemente und Auswirkungsanalyse

Traceability ist keine einmalige Übung. Anforderungen ändern sich. Designs entwickeln sich weiter. Wenn dies geschieht, muss die Trace-Kette die Auswirkungen widerspiegeln: Welche nachgelagerten Elemente hat die Änderung invalidiert, und welche erfordern nun eine erneute Prüfung oder Nachtestung? Dies ist das Konzept der „Suspect Links" – und dessen manuelle Verwaltung in einer großen ADO-Umgebung ist praktisch nicht möglich.

---

WUSSTEN SIE SCHON?  Bei ASPICE-Assessments zählt unvollständige oder nicht nachweisbare Traceability zu den häufigsten Befunden auf BP-Ebene. Es handelt sich nicht nur um ein Dokumentationsproblem – es ist ein Nachweis dafür, dass der Engineering-Prozess nicht unter Kontrolle ist.

---

Wie KI die Gleichung verändert

Die zentrale Herausforderung bei der Traceability in ADO besteht darin, dass manuelle Pflege nicht skaliert. Das Volumen der Work Items, das Liefertempo und die Komplexität von Cross-Tool-Abhängigkeiten wirken alle gegen menschliche Konsistenz. Hier wird Azure DevOps Traceability KI wirklich nützlich – nicht als Schlagwort, sondern als praktische Antwort auf ein strukturelles Problem.

KI kann leisten, was manuelle Prozesse nicht können:

1. Den semantischen Inhalt von Work Items – Titel, Beschreibungen, Akzeptanzkriterien – analysieren und logische Beziehungen erkennen, die Ingenieure nie formal verknüpft haben.
2. Das Trace-Netz kontinuierlich auf Lücken und Inkonsistenzen überwachen, anstatt zu warten, bis sie jemandem auffallen.
3. Nachgelagerte Elemente automatisch als verdächtig kennzeichnen, wenn sich eine übergeordnete Anforderung oder ein Designartefakt ändert.
4. Traceability-Matrizen und Abdeckungsberichte aus Live-Daten generieren, anstatt manuell zusammengestellte Momentaufnahmen zu erstellen.

In der Praxis verschiebt dies Teams von reaktiver Traceability – unter Druck kurz vor einem Audit zusammengestellt – hin zu proaktiver Traceability, die zu einem natürlichen Bestandteil des Engineering-Prozesses wird.

Wie AroTrace dies in Azure DevOps löst

Genau für dieses Problem wurde AroTrace entwickelt. Es integriert sich direkt in Azure DevOps und ergänzt die KI-gestützte Traceability-Schicht, die ADO nativ nicht bereitstellt – ohne die bereits etablierten Workflows der Teams zu ersetzen.

Automatisierte Verknüpfungserkennung

AroTrace – betrieben durch AroAgent – analysiert ADO-Work-Items mittels Natural Language Processing und schlägt Verknüpfungen zwischen semantisch verwandten, aber nicht formal verbundenen Elementen vor. Ingenieure prüfen und bestätigen die Vorschläge; die KI übernimmt die Erkennungsarbeit, die sonst manuelles Querverweisen erfordern würde.

Cross-Tool-Traceability

AroTrace verbindet vorgelagerte ALM-Systeme – DOORS NG, Polarion, Codebeamer – mit der ADO-Lieferumgebung und pflegt bidirektionale Trace-Links in Echtzeit. Wenn eine Systemanforderung im vorgelagerten System geändert wird, kennzeichnet AroTrace betroffene ADO-Work-Items sofort als verdächtig. Die Auswirkungen sind unmittelbar sichtbar, nicht erst Wochen später.

Kontinuierliche Lückenanalyse

AroTrace überwacht das ADO-Trace-Netz kontinuierlich und zeigt Abdeckungslücken auf: Anforderungen ohne verknüpfte Testfälle, User Stories ohne Implementierungs-Traceability oder Work Items, die von ihren übergeordneten Anforderungen getrennt sind. AroTrace kennzeichnet diese Lücken proaktiv, sodass Teams sie im Rahmen normaler Sprint-Arbeit beheben können – und nicht als Notfallaktion vor einem Audit.

Compliance-Reporting auf Abruf

Wenn ein Assessment oder Audit ansteht, generiert AroTrace Traceability-Matrizen und Abdeckungsberichte direkt aus Live-ADO-Daten – und gibt so den tatsächlichen Projektstatus zu jedem beliebigen Zeitpunkt wieder, keine manuell zusammengestellte Momentaufnahme aus der Woche zuvor.

Ein Praxisbeispiel

Ein Automotive-Softwareteam entwickelt eine Spurhaltewarnung. Die Systemanforderungen werden in einem vorgelagerten ALM-Werkzeug verwaltet. Implementierung und Testing erfolgen in Azure DevOps.

Ohne AroTrace müssen Ingenieure daran denken, Verknüpfungen zwischen Systemanforderungen und ADO-User-Stories manuell anzulegen – und diese Verknüpfungen bei jeder Anforderungsänderung zu aktualisieren.

AroTrace erstellt und pflegt die Trace-Kette automatisch:

1. Die Systemanforderung „Spurabweichung innerhalb von 200 ms erkennen" wird mit dem entsprechenden ADO-Epic verknüpft.
2. AroTrace erkennt, dass drei User Stories zweier Teams semantisch mit dieser Anforderung zusammenhängen, und schlägt die Trace-Links vor. Ingenieure bestätigen.
3. AroTrace ordnet Testfälle in ADO-Test-Plans den User Stories und zurück zur Systemanforderung zu. Die Abdeckung ist in Echtzeit sichtbar.
4. Als der Reaktionsschwellenwert von 200 ms auf 150 ms geändert wird, kennzeichnet AroTrace sofort das verknüpfte Epic, die User Stories und die Testfälle als verdächtig. Das Team weiß genau, was erneut geprüft werden muss – ohne manuelle Auswirkungsanalyse.

Das Team pflegt eine vertretbare, prüfungsfähige Trace-Kette kontinuierlich – nicht unter Druck zwei Wochen vor einem Assessment zusammengestellt.

Traceability in ADO ist kein Werkzeugproblem. Es ist ein Prozessproblem, das das richtige Werkzeug endlich handhabbar machen kann.

---