Agile Methoden sind im Software-Engineering Standard, im Mechatronik- und Embedded-Engineering noch Verhandlungssache. ISO 26262, ISO 14971 und DO-178C verlangen einen vorhersehbaren, nachweisbaren Prozess, Sprint-Backlogs sind das Gegenteil davon. Drei Apps der Engineering Intelligence Platform lösen diese Spannung auf: User Stories aus Anforderungen, Sprint Planning mit Engineering-Constraints und eine Roadmap, die Norm-Meilensteine mitführt.
Diese Seite behandelt die Produkt- und Sprint-Steuerung, nicht das klassische Projektmanagement mit Plan und Terminierung. Wenn Sie die Plan-Sicht auf Engineering-Projekte suchen, führt die Projektmanagement-Seite zum Projekt-Plan-Generator, Schedule Optimizer und Risk Manager. Beide Disziplinen ergänzen sich, sind aber methodisch unterschiedlich.
In Software-nahen Teams ist agiles Produktmanagement gelebte Praxis: Ein Product Owner pflegt das Backlog mit User Stories, das Team plant Sprints, eine Release-Roadmap kommuniziert nach außen. In Embedded-, Automotive- und Medical-Teams ist die Lage komplizierter. Eine Hardware-Komponente lässt sich nicht alle zwei Wochen neu ausliefern, ein Steuergerät muss eine ASIL-Argumentation tragen, ein Medizinprodukt unterliegt einer MDR-Konformitätsbewertung. Was diese Teams brauchen, ist eine hybride Form: agile Iteration dort, wo sie wertvoll ist, regulatorische Struktur dort, wo sie verlangt wird.
Diese Effekte sind keine Garantien. Sie hängen vom Reifegrad der eingebundenen Datenquellen ab und davon, dass das Team die KI-Vorschläge konsequent prüft.
Voraussetzung ist die gemeinsame Datenbasis: Anforderungen, Architektur, FMEA-Einträge, Safety-Argumente und Sprint-Tickets liegen im Product Knowledge Graph verknüpft vor. Alle drei Apps arbeiten bidirektional mit Jira, Azure DevOps und Confluence. Das Backlog bleibt dort, wo das Team es heute pflegt, gewinnt aber eine semantische Tiefenstruktur, die manuell nicht herstellbar wäre.
Jira oder Azure DevOps werden an den Knowledge Graph angebunden, die Anforderungen aus Polarion, DOORS, Codebeamer, Word oder Excel eingelesen und ontologisch verlinkt.
Der Epic & Story Generator zerlegt funktionale Anforderungen in arbeitbare User Stories und übergeordnete Epics, jede mit bleibender Verknüpfung zur Quell-Anforderung.
Der Sprint Planning Assistant macht ASIL-Bezüge, Hardware-Abhängigkeiten, Norm-Meilensteine und Konfliktrisiken sichtbar und schlägt Sprint-Kombinationen vor, die die Engineering-Realität respektieren.
Der Release Roadmap Builder strukturiert das Produkt über die Zeitachse und propagiert Änderungen an Anforderungen oder Sprint-Ergebnissen direkt in den Zeitplan.
Liest die strukturierten Anforderungen aus dem Knowledge Graph und schlägt passende User Stories und übergeordnete Epics vor. Eine Anforderung wie „System überwacht Sicherheitsabstand und bremst bei Unterschreitung" wird in mehrere Stories zerlegt, jede mit Verknüpfung zur Quell-Anforderung und direkter Anlage in Jira oder Azure DevOps. Der Mehrwert ist die bleibende Verknüpfung: Ändert sich die Anforderung, werden abgeleitete Stories als „potenziell betroffen" markiert.
Klassisches Sprint Planning konzentriert sich auf Kapazität und Priorität. Im Engineering kommen Dimensionen dazu: Welche Stories berühren ASIL-relevante Funktionen, welche hängen von Hardware-Lieferungen ab, welche müssen vor einem Norm-Meilenstein abgeschlossen sein. Der Assistant zieht diese Verknüpfungen aus dem Graphen und schlägt Sprint-Kombinationen vor. Er ersetzt nicht die Team-Diskussion, er bringt sie auf die richtige Faktenbasis.
Schließt die strategische Sicht ab: strukturiert die Roadmap über die Zeit, mit Verknüpfung zu konkreten Engineering-Meilensteinen (System-Integrationstest, Tool-Qualifikation, Norm-Audit, Marktzulassung). Besonders wertvoll, wenn die Roadmap mit den Norm-Meilensteinen aus der Compliance-App und regulatorischen Stichtagen verknüpft ist. So wird die Roadmap kein Wunschplan, sondern ein realistischer Spiegel der Engineering-Realität.
Auf der Anforderungsseite verbinden sich die Apps über dieselben Konnektoren wie das Anforderungsmanagement (Polarion, DOORS, Codebeamer, Jama, Word, Excel). Damit entsteht der Brückenschlag zwischen Anforderungs-Werkzeug und Agile-Werkzeug, der in klassischen Setups manuelle Arbeit verlangt.
Die ehrliche Frage: Ist agiles Arbeiten überhaupt vereinbar mit ISO 26262 oder MDR? Reine SAFe-mäßige Iteration ohne Strukturierung funktioniert in regulierten Branchen tatsächlich nicht. Eine hybride Form, in der die agile Iteration für die operative Umsetzung verwendet wird und die regulatorischen Strukturen (V-Modell-Stages, Reviews, Audit-Trails) parallel mitgeführt werden, funktioniert sehr wohl.
Die drei Apps machen genau diese hybride Form möglich. Ein Sprint setzt iterativ User Stories um, gleichzeitig wird jede Story im Knowledge Graph mit ASIL-Pflichten, Safety-Argumenten und Verifikations-Anforderungen verknüpft. Ein Sprint-Review wird zur agilen Routine, ein Norm-Audit zur abgeleiteten Sicht auf dieselben Daten. Mehr zur Compliance-Argumentation auf der Compliance-Seite, zur Safety-Methodik auf der Safety-Analyse-Seite.
Agiles Produktmanagement lebt von Priorisierung und strategischen Entscheidungen. Was als Nächstes wertvoll für den Markt ist, welches Risiko sich das Team in welchem Sprint zumutet, welche Kompromisse zwischen Funktion und Termin akzeptabel sind, das sind Entscheidungen mit Geschäfts- und Personalverantwortung. Sie lassen sich nicht an eine KI übergeben. Die drei Apps sind deshalb als Vorbereitungs- und Konsistenzwerkzeuge konzipiert: Sie generieren User-Story-Vorschläge, machen Sprint-Constraints sichtbar, propagieren Roadmap-Auswirkungen. Die Priorisierung trifft der Product Owner, die Sprint-Auswahl das Team, die strategische Roadmap das Produktmanagement. Jede KI-erzeugte oder KI-veränderte Aussage trägt im Graphen ihre Provenance, sodass die Audit-Argumentation auch in agilen Setups bestehen bleibt.
Voraussetzung ist weder ein bestimmtes Skalierungsmodell (Scrum, SAFe, LeSS) noch eine fertige Compliance-Argumentation. Die Apps fügen sich in den Methodik-Stand des Teams ein und entwickeln die Verknüpfung zur Engineering-Datenbasis schrittweise.
In den ersten Wochen werden Jira oder Azure DevOps an den Knowledge Graph angebunden, die Anforderungen aus dem aktuellen Werkzeug eingelesen, und der Epic & Story Generator liefert erste Übersetzungsvorschläge.
In den folgenden Wochen werden Sprint-Plannings mit dem Sprint Planning Assistant unterstützt und die Roadmap mit dem Release Roadmap Builder strukturiert.
Erst danach erweitert sich der Einsatz auf weitere Teams und tiefere Methodikunterstützung. Ein abgegrenzter Pilot liefert in der Regel innerhalb von vier bis sechs Wochen die ersten produktiv nutzbaren Ergebnisse.
Agiles Produktmanagement steuert den Produkt-Wert über die Zeit. Wer ein Vorhaben mit klarem Anfang und Ende plant und terminiert, findet auf der Projektmanagement-Seite den Projekt-Plan-Generator, Schedule Optimizer und Risk Manager. Beide Disziplinen teilen dieselbe Datenbasis im Knowledge Graph und laufen parallel.
Mehr zum ProjektmanagementBidirektional integriert sind Jira (Cloud und Self-Hosted), Azure DevOps Boards und Confluence. Auf der Anforderungsseite werden über dieselben Konnektoren wie im Anforderungsmanagement Polarion, DOORS, Codebeamer, Jama, Word und Excel angebunden.
Die Apps sind methodisch neutral. Sie unterstützen Scrum-Teams, SAFe-Trains und auch hybride Setups, in denen Teile agil und Teile klassisch geführt werden. Konkrete Anpassungen an das jeweilige Skalierungsmodell werden im Projekt-Setup hinterlegt.
Agiles Arbeiten und regulierte Entwicklung sind in der hybriden Form vereinbar, in der iterativ entwickelt wird und die regulatorischen Strukturen (Reviews, Audit-Trails, ASIL-Argumente) parallel im Graphen mitgeführt werden. Die Apps machen genau diese Parallelführung operativ.
Agiles Produktmanagement und klassisches Projektmanagement adressieren unterschiedliche Steuerungs-Sichten. Produktmanagement steuert den Produkt-Wert über die Zeit, Projektmanagement steuert ein Vorhaben mit klarem Anfang und Ende. Beide Disziplinen können parallel laufen, mit gemeinsamer Datenbasis im Knowledge Graph. Mehr zur Projekt-Sicht auf der Projektmanagement-Seite.
Ja. Jede KI-generierte User Story und jeder KI-erzeugte Roadmap-Eintrag trägt im Graphen seine Provenance: wer hat sie wann mit welcher Modellversion erzeugt, auf welcher Quelle basieren sie, wer hat sie freigegeben. Das ist die Voraussetzung für die Tool-Qualifikation in regulierten Setups und auch für interne Audit-Argumentation.
Ein abgegrenzter Pilot (ein Sprint-Team, ein Produkt-Bereich) liefert in der Regel innerhalb von vier bis sechs Wochen die ersten produktiv nutzbaren Ergebnisse. Die Erweiterung auf weitere Teams und tiefere Methodikunterstützung erfolgt anschließend schrittweise.
Sehen Sie in einer 30-minütigen Demo, wie Epic & Story Generator, Sprint Planning Assistant und Release Roadmap Builder in Ihrem agilen Setup zusammenarbeiten, gerne mit anonymisierten Beispielen aus Ihrem aktuellen Backlog oder Ihrer Release-Roadmap.