Agile-Softwareprojektmanagement: von Sprints zur Portfolio-Governance

Agile in der Softwareentwicklung: was sich gegenüber dem traditionellen PM ändert

Traditionelles Projektmanagement geht davon aus, dass ein Projekt vorab definiert werden kann: Umfang, Zeitplan, Budget, Ressourcen. Aufgabe des PM ist es, das Ganze zu planen, die Freigabe einzuholen und dann die Umsetzung gegen den Plan zu verfolgen. Agile geht vom Gegenteil aus: dass sich Anforderungen ändern, dass eine detaillierte Vorabplanung über die nächsten Wochen hinaus Fiktion ist und dass Wert dadurch entsteht, funktionierende Software in kurzen Zyklen zu liefern statt in einer großen Auslieferung am Ende. Für einen PM ist das eine echte Verschiebung, keine kosmetische. Der Plan wird rollierend statt fest, die Statusberichterstattung wöchentlich statt meilensteinbasiert, und Erfolg wird am gelieferten Wert gemessen statt an der Einhaltung des ursprünglichen Zeitplans.

Die Veränderungen fallen in drei Kategorien. Erstens verschiebt sich die Planung von umfassend zu schrittweise: Eine grobe Roadmap deckt mehrere Monate ab, aber die Detailplanung reicht nur bis zum nächsten Sprint oder zwei. Zweitens verschiebt sich die Steuerung von Terminabweichung hin zu Velocity und Durchsatz: Der PM fragt nicht mehr, ob wir im Gantt-Diagramm liegen, sondern wie viel Wert wir in diesem Sprint ausgeliefert haben. Drittens verschiebt sich die Kommunikation von formalen Statusberichten zu kontinuierlicher Transparenz: Sprint Review, Retrospektive und Daily Standup ersetzen wöchentliche PM-Meetings als primäre Informationskanäle. Keine dieser Veränderungen macht den PM überflüssig, aber sie verändern, was der PM tut. Wenn Sie eine ausführlichere Definition von Agile selbst benötigen, deckt unser Leitfaden Was ist Agile? die Grundlagen ab; der Rest dieses Artikels setzt diese Basis voraus und konzentriert sich auf die PM-Praxis.

Das Agile-PM-Betriebsmodell: Sprints, Zeremonien, Artefakte

Agile-PM-Arbeit findet innerhalb einer Sprint-Taktung statt, typischerweise zwei bis vier Wochen pro Iteration. Den Zyklus aus PM-Sicht (nicht aus Entwicklersicht) zu verstehen ist der Unterschied zwischen dem Führen eines Agile-Projekts und dem bloßen Teilnehmen an Zeremonien.

Sprint-Mechanik: Planung, Umsetzung, Review, Retrospektive

Der Sprint hat vier Punkte, an denen die Rolle des PM eigenständig ist. Sprint Planning ist der Moment, in dem sich das Team auf einen Satz von Stories festlegt, und die Aufgabe des PM ist es, sicherzustellen, dass die Zusage angesichts bekannter Abhängigkeiten, Kapazität und externer Einschränkungen realistisch ist. In der Umsetzung beseitigt der PM Hindernisse, die das Team nicht selbst bewältigen kann: Beschaffungsblockaden, nicht verfügbare Stakeholder, teamübergreifende Abhängigkeiten. Im Sprint Review führt das Team funktionierende Software den Stakeholdern vor, und die Aufgabe des PM ist es, technische Ergebnisse für den Sponsor in Geschäftssprache zu übersetzen. In der Retrospektive verbessert das Team seinen Prozess, und der PM steuert teamübergreifenden Kontext bei, den das Team möglicherweise nicht sieht. Velocity, gemessen als pro Sprint abgeschlossene Story Points, wird zur wichtigsten Prognosegrundlage des PM: Mit drei oder vier Sprints Historie wird die Prognose von Release-Terminen zu einer mathematischen Übung statt zu einer Vermutung.

Backlog-Management: von der Vision zum Sprint

Das Product Backlog ist die Gesamtliste all dessen, was das Team bauen könnte; das Sprint Backlog ist die für den aktuellen Sprint zugesagte Teilmenge. Der Product Owner verantwortet die Prioritäten im Product Backlog, aber der PM steuert Kontext bei, den der Product Owner möglicherweise nicht hat: projektübergreifende Abhängigkeiten, geschäftliche Meilensteine, die die Reihenfolge einschränken, regulatorische oder Compliance-Fristen. Story-Point-Schätzung ist der Mechanismus, mit dem das Team Arbeit relativ zu sich selbst statt in absoluter Zeit dimensioniert, und der PM sollte sie gut genug verstehen, um Schätzungen zu hinterfragen, die vom Muster abweichen, ohne selbst zu schätzen. Wenn das Team eine Story auf 13 Punkte schätzt und die Historie ähnliche Stories bei 5 zeigt, ist das ein Signal, dem man nachgehen sollte.

Artefakte und Reporting: Burndown, Velocity, Cumulative Flow

Drei Artefakte treiben das Agile-PM-Reporting an. Das Burndown-Diagramm zeigt die verbleibende Arbeit gegen die Zeit in einem Sprint, und seine Form verrät, ob das Team die Sprint-Zusage erfüllen wird. Velocity-Trends über mehrere Sprints hinweg zeigen Teamkapazität und Stabilität: steigende Velocity bedeutet oft, dass das Team im Umgang mit der Codebasis versierter wird, flache Velocity deutet auf einen stabilen Zustand hin, und fallende Velocity signalisiert oft technische Schulden oder Störungen im Team. Cumulative-Flow-Diagramme zeigen Arbeitselemente über verschiedene Zustände hinweg (Backlog, in Bearbeitung, Review, fertig) und decken Engpässe auf: Wenn die laufende Arbeit anschwillt, während der Anteil fertiger Arbeit gleich bleibt, hat das Team ein Flussproblem, das es zu lösen gilt. Aufgabe des PM ist es nicht, diese Artefakte zu erstellen (Agile-Tools erzeugen sie automatisch), sondern sie zu lesen und ihre Signale in ein sponsorgerechtes Reporting zu übersetzen.

Rollen und Verantwortlichkeiten in Agile-Softwareteams

Das am meisten missverstandene Element von Agile in der Softwareentwicklung ist, wo der Projektmanager hingehört. Scrum definiert drei Rollen (Product Owner, Scrum Master, Entwicklungsteam) und enthält keinen Projektmanager. In der Praxis haben die meisten Agile-Einführungen im Unternehmen weiterhin PMs, und zu verstehen, was sie tatsächlich tun, verhindert den häufigen Fehlermodus, bei dem sich PM und Scrum Master überschneiden oder in Konflikt geraten.

Die Rolle des Projektmanagers in Agile-Teams

Der PM in einem Agile-Team ist verantwortlich für Ergebnisse, die außerhalb des Teams sichtbar sind: Lieferung an Sponsoren, teamübergreifende Koordination, Reporting auf Portfolio-Ebene, Risiko-Eskalation und Geschäftsausrichtung. Der PM führt keine Sprint-Zeremonien durch (das ist Sache des Scrum Masters) und entscheidet nicht über Feature-Prioritäten (das ist Sache des Product Owners). Die Autorität des PM ist lieferorientiert: Er verantwortet den Liefertermin gegenüber dem Unternehmen, das ausgegebene Budget, die Abhängigkeiten mit anderen Teams und die Kommunikation mit Stakeholdern außerhalb des Teams. In der Praxis bedeutet das, dass der PM im Raum zwischen Team und Organisation lebt, in beide Richtungen übersetzt und organisatorische Hindernisse beseitigt, die das Team intern nicht lösen kann.

Product Owner, Scrum Master, Entwicklungsteam

Der Product Owner verantwortet das Product Backlog, priorisiert Features und vertritt den Kunden gegenüber dem Team. Der Scrum Master moderiert Zeremonien, beseitigt Hindernisse auf Teamebene und coacht das Team in der Agile-Praxis. Das Entwicklungsteam (typischerweise fünf bis neun Mitglieder) baut die Software, organisiert sich selbst rund um die Sprint-Zusage und verpflichtet sich pro Sprint auf bestimmte Stories. Diese Rollen werden in unserem Scrum-Master-Leitfaden und Product-Owner-Leitfaden ausführlicher behandelt; der Punkt für PMs ist, dass diese drei Rollen die teamgerichtete Arbeit übernehmen, während der PM die organisationsgerichtete Arbeit übernimmt.

Stakeholder und Steuerung: wie Agile-Projekte mit dem Geschäft verbunden sind

Ein Agile-Team liefert nicht an einen abstrakten Kunden; es liefert in einen Geschäftskontext mit Sponsoren, Lenkungsausschüssen und Business Ownern, die auf Basis des Teamfortschritts Entscheidungen treffen müssen. Der PM strukturiert diese Verbindung über drei Mechanismen: regelmäßige Sponsor-Updates, die Sprint-Ergebnisse in Geschäftsbegriffe übersetzen, eine Taktung des Lenkungsausschusses (meist monatlich), in der größere Entscheidungen getroffen werden, und eine Business-Owner-Beziehung, in der alltägliche Produktfragen beantwortet werden. Ohne diese Strukturen verschwindet das Team aus der organisatorischen Sichtbarkeit, und Organisationen reagieren, indem sie eine Wasserfall-artige Aufsicht hinzufügen, die die agile Flexibilität untergräbt. Aufgabe des PM ist es, Agile für die Organisation lesbar zu machen, ohne dass es aufhört, Agile zu sein.

Frameworks in der Softwareentwicklung: Scrum, Kanban, Scrumban, SAFe

Nicht jedes Agile-Team sollte Scrum verwenden. Die Framework-Auswahl ist eine PM-Entscheidung, die vom Arbeitsmuster des Teams, der Agile-Reife der Organisation und der Art der zu bauenden Software abhängt. Die vier folgenden Frameworks decken den Großteil der Agile-Softwareentwicklung im Unternehmen ab.

Scrum ist der sprintbasierte Klassiker. Iterationen fester Länge (typischerweise zwei Wochen), definierte Zeremonien und ein zugesagtes Sprint Backlog. Am besten geeignet für Teams, die neue Features in vorhersehbarer Taktung bauen, mit einem Product Owner, der sich auf einen stabilen Sprint-Umfang festlegen kann. Schwach für Teams mit viel Wartungsarbeit oder wenn unterbrechungsgetriebene Prioritäten dominieren. Ausführlich behandelt in unserer Einführung in die Scrum-Methodik.

Kanban ist kontinuierlicher Fluss statt sprintbasiert. Arbeitselemente wandern durch Spalten (Backlog, in Bearbeitung, Review, fertig), wobei WIP-Limits den Fluss steuern. Am besten für Support-Teams, Wartungsarbeit und Teams, deren Prioritäten sich häufiger als eine Sprint-Länge verschieben. Schwach für Teams, die eine vorhersehbare, an Sprint-Grenzen gebundene Release-Taktung benötigen. Siehe unseren Kanban-Workflow-Leitfaden und den Kanban-Board-Leitfaden.

Scrumban kombiniert beide: Scrum-Zeremonien für Planung und Review, Kanban-Board für das tägliche Arbeitsmanagement. Nützlich für Teams im Übergang von Scrum zu Kanban (meist wenn Scrum zu schwer wirkt) oder von Kanban zu Scrum (meist wenn das Team mehr Disziplin bei Zusagen braucht). Oft die pragmatische Wahl für Teams, die dem strikten Scrum entwachsen, ohne Iterationen ganz aufgeben zu wollen.

SAFe (Scaled Agile Framework) ist für Organisationen gedacht, die mehrere Agile-Teams an einem gemeinsamen Programm oder Produkt koordinieren. Es legt eine Planung auf Programmebene (Program-Increment-Planung, typischerweise vierteljährlich) über das Scrum auf Teamebene. Nützlich für Unternehmen mit dutzenden Agile-Teams am selben Produkt. Überdimensioniert für Organisationen mit weniger als 5-10 Teams; ziehen Sie LeSS oder Nexus als leichtere Alternativen in Betracht.

Die Auswahl ist nicht endgültig. Reife Agile-Organisationen wechseln oft zwischen Frameworks, wenn sich Teamzusammensetzung, Produktreife und organisatorischer Kontext ändern. Aufgabe des PM bei der Framework-Auswahl ist es, die Kompromisse sichtbar zu machen und die Wahl daran zu testen, wie das Team tatsächlich arbeitet, nicht daran, wie Agile-Puristen sagen, dass das Team arbeiten sollte.

Brücke zwischen Agile und PMO: Werkzeuge für gemischte Portfolios

Die meiste Softwareentwicklung im Unternehmen findet in Organisationen statt, die auch nicht-softwarebezogene Projekte betreiben: Geschäftsinitiativen, Marketingkampagnen, Investitionsvorhaben, Compliance-Programme. Das schafft ein Werkzeugproblem, das die meisten Agile-Texte ignorieren.

Das Problem des gemischten Portfolios: Entwickler in Jira, Business im PPM

Entwickler bevorzugen Jira (oder Azure DevOps) stark, weil es zu ihrem Arbeitsablauf passt: Verfolgung auf Story-Ebene, Sprint-Boards, Backlog-Pflege, Integration mit der Versionsverwaltung. Business-Teams bevorzugen PPM-Systeme (Projektportfoliomanagement), weil sie zu ihrem Arbeitsablauf passen: Meilenstein-Verfolgung, Budgetmanagement, Dashboards auf Portfolio-Ebene, Ressourcenkapazität über Projekte hinweg. Die Führung braucht eine einzige Sicht auf das gesamte Portfolio, Agile und Wasserfall zusammen. Wenn jede Domäne ihr eigenes Werkzeug nutzt, endet die Organisation mit drei Wahrheitsquellen: der Sicht der Entwickler in Jira, der Sicht der Business Owner im PPM und der Sicht der Führung, die für jeden Lenkungsausschuss manuell in Folien zusammengestellt wird. Das ist der Fehlermodus, den die meisten Unternehmen erreichen, wenn die Agile-Einführung ohne Werkzeugstrategie wächst.

Wie man Agile-Werkzeuge mit einem Projektportfoliosystem integriert

Die architektonisch saubere Antwort ist, die Arbeit auf Teamebene in Jira zu belassen (wo sie hingehört) und die Arbeit auf Portfolio-Ebene im PPM (wo sie hingehört), wobei eine Integration beide synchronisiert. Was synchronisiert werden sollte: Status auf Task-Ebene (offen, in Bearbeitung, fertig), Zuweisung des Verantwortlichen, Termine sowie Story Points oder Schätzungen. Was nicht synchronisiert werden sollte: tägliche Kommentare, Sub-Task-Granularität, entwicklerspezifische Felder. Über-Synchronisation erzeugt Rauschen; Unter-Synchronisation erzeugt Lücken. Das richtige Muster ist, dass Entwickler natürlich in Jira arbeiten, PMs und PMO die portfoliorelevante Teilmenge der Jira-Arbeit im PPM neben Nicht-Jira-Projekten sehen und niemand sich in ein Werkzeug einloggen muss, das nicht sein primärer Arbeitsbereich ist.

Die FlexiProject-Jira-Integration in der Praxis

FlexiProject setzt dieses Muster mit einer direkten Jira-Integration um, die Epics, Stories und Tasks aus Jira importiert und dabei Status, Verantwortlichen und Typ bewahrt. JQL-Filter erlauben es PMs, genau auszuwählen, welche Arbeitselemente in der FlexiProject-Sicht erscheinen, und Importe können für teamübergreifende Programme gleichzeitig aus mehreren Jira-Projekten ziehen. Das User-Mapping löst das häufige Problem, dass dieselbe Person unterschiedliche Kennungen in Jira und im PPM hat: Das Mapping wird einmal konfiguriert und läuft dann automatisch, sodass die Aufgabenverantwortung über beide Systeme hinweg konsistent bleibt. Das Ergebnis ist, dass Jira-Tasks im FlexiProject-Zeitplan neben Business-Tasks, Marketing-Tasks und anderer Nicht-Software-Arbeit erscheinen – Führung und PMO sehen das gesamte Portfolio, ohne sich jemals bei Jira anzumelden, während Entwickler weiter in ihrem bevorzugten Werkzeug arbeiten. Der eigene Artikel zur FlexiProject-Jira-Integration behandelt die technische Einrichtung ausführlicher.

Governance und Reporting für Agile-Projekte in einem PMO

PMOs steuern Agile-Projekte anders als Wasserfall-Projekte, und dies richtig zu machen ist der Punkt, an dem die meisten Unternehmen scheitern. Der Fehlermodus besteht darin, Wasserfall-Governance (detaillierte Zeitplanverfolgung, Meilenstein-Freigaben, Änderungskontrolle beim Umfang) auf Agile-Arbeit anzuwenden, was Reibung erzeugt, ohne Aufsichtswert hinzuzufügen.

Metriken, die für das Agile-PMO-Reporting zählen

Nicht jede Agile-Metrik gehört in einen PMO-Bericht. Burndown-Diagramme und Velocity sind Metriken auf Teamebene, die für das Team selbst nützlich sind; sie einem Sponsor zu zeigen lädt zum Mikromanagement ein, ohne Entscheidungswert hinzuzufügen. Die Metriken, die in das PMO-Reporting gehören, sind ergebnisorientiert: Durchlaufzeit (wie lange von der Zusage bis zur Lieferung), Durchsatz (pro Zeitraum gelieferte Features), Rate entwichener Defekte (Lieferqualität) und Erfolgsquote der Sprint-Ziele (ob Zusagen eingehalten werden). Diese Metriken beantworten die Fragen, die Sponsoren tatsächlich stellen: Liefern wir aus, hält die Qualität, sind die Zusagen realistisch. Sprint-interne Metriken bleiben beim Team; Metriken auf Portfolio-Ebene gehen an das PMO.

Sicht auf Portfolio-Ebene: Agile- und Wasserfall-Projekte mischen

Ein Agile-Projekt ohne harte Endtermine und ein Wasserfall-Projekt mit festen Meilensteinen müssen in derselben Portfolio-Sicht erscheinen, und ihre unterschiedlichen Rhythmen in Einklang zu bringen ist der Punkt, an dem sich PMO-Werkzeuge ihren Preis verdienen. Das pragmatische Muster ist Rolling Wave: Agile-Projekte zeigen eine zugesagte kurzfristige Welle (nächste ein bis drei Sprints) auf Detailebene und zukünftige Wellen auf Schätzebene. Wasserfall-Projekte zeigen Meilensteine und Abhängigkeiten mit demselben visuellen Gewicht wie Agile-Wellen. Die Portfolio-Sicht zeigt beide gleichzeitig, wobei der Sponsor sehen kann, dass das nächste Release des Agile-Teams mit dem Umstellungs-Meilenstein des Wasserfall-Projekts übereinstimmt (oder ihn verfehlt). Hybride Projektmanagement-Ansätze adressieren dasselbe Abstimmungsproblem auf Projektebene; Werkzeuge auf Portfolio-Ebene skalieren es über die Organisation hinweg.

Risikomanagement in Agile-Projekten

Agile-Projekte haben ihr eigenes Risikoprofil, das traditionelles Risikomanagement oft übersieht. Sprint-Versagen (das Team schafft die zugesagten Stories nicht) signalisiert Schätz- oder Planungsprobleme und rechtfertigt eine Untersuchung, keine Schuldzuweisung. Velocity-Schwankungen von Sprint zu Sprint signalisieren oft eine Störung im Team (neue Mitglieder, Krankheit, konkurrierende Prioritäten), die der PM angehen kann. Abhängigkeitsrisiko zwischen Teams ist die größte einzelne Verzögerungsquelle in skaliertem Agile: Wenn der Sprint von Team A von der fertigen Arbeit von Team B abhängt und B in Verzug gerät, blockiert A. Die Anhäufung technischer Schulden ist ein verstecktes Risiko, das die Velocity im Laufe der Zeit reduziert, ohne sichtbaren Defekt. PMO-Risikoregister sollten diese Agile-spezifischen Risiken neben traditionellen Projektrisiken erfassen, und die Überprüfungstaktung sollte sich an Sprint-Grenzen orientieren statt an monatlichen PM-Zyklen.

FAQ: Agile-Softwareprojektmanagement

Was ist der Unterschied zwischen einem Projektmanager und einem Scrum Master?

Der Scrum Master moderiert das Team intern: führt Zeremonien durch, coacht in der Agile-Praxis, beseitigt Hindernisse auf Teamebene. Der Projektmanager liefert extern an die Organisation: steuert die Sponsor-Kommunikation, teamübergreifende Abhängigkeiten, Budget, Portfolio-Reporting und organisatorische Hindernisse, die das Team nicht allein lösen kann. In kleinen Teams kann eine Person beide Rollen ausfüllen, aber im Unternehmens-Agile sind sie getrennt: Der Scrum Master verantwortet die Teamgesundheit, der PM verantwortet die Lieferverantwortung gegenüber dem Geschäft.

Wie plant man ein Release mit Agile-Teams?

Release-Planung kombiniert die Velocity des Teams (pro Sprint abgeschlossene Punkte) mit dem Release-Backlog (für den Release-Umfang geschätzte Punkte), um einen wahrscheinlichen Zeitraum für den Release-Termin zu ergeben. Drei Sprints Velocity-Historie ergeben eine brauchbare Prognose; zehn Sprints eine verlässliche. Release-Termine werden als Bereiche (P50 und P80) statt als Punkte ausgedrückt und mit dem Abschluss weiterer Sprints verfeinert. Releases mit festem Termin erfordern Flexibilität beim Umfang; Releases mit festem Umfang erfordern Flexibilität beim Termin.

Wie fügt sich Agile in ein Portfolio mit Wasserfall-Projekten ein?

Agile- und Wasserfall-Projekte koexistieren im Portfolio über ein Portfoliomanagement-System, das beide in angemessener Granularität zeigt. Agile-Projekte zeigen zugesagte kurzfristige Arbeit im Detail und zukünftige Arbeit auf Schätzebene; Wasserfall-Projekte zeigen Meilensteine und Abhängigkeiten. Die Portfolio-Sicht macht projektübergreifende Abhängigkeiten sichtbar (das Release des Agile-Teams blockiert den Go-live des Wasserfall-Projekts), sodass PMOs das gemischte Portfolio steuern können, ohne eine Methodik in die Form der anderen zu zwingen.

Welche Werkzeuge brauchen Agile-PMs über Jira hinaus?

Jira bewältigt Agile-Arbeit auf Teamebene gut, aber PPM auf Portfolio-Ebene nicht. Agile-PMs brauchen typischerweise ein PPM-System, das sich mit Jira integriert (Import von Tasks, Status und Schätzungen), für Reporting auf Portfolio-Ebene, Abhängigkeiten mit Nicht-Agile-Projekten, Budgetmanagement über das Projekt hinweg und Führungs-Dashboards. Ob das PPM FlexiProject, Planview oder eine andere Plattform ist, das Integrationsmuster ist dasselbe: Entwickler bleiben in Jira, PMs und PMO arbeiten im PPM, die Integration hält beide synchron.

Wie geht man mit Projekten mit festem Umfang und festem Termin agil um?

Rein umfang- und termingebundene Projekte passen nicht gut zu reinem Agile, sind aber in regulierten Branchen, Compliance-Projekten und Lieferantenverträgen verbreitet. Die pragmatische Antwort ist hybrid: Wasserfall-artige Umfang- und Terminzusage auf Projektebene, Agile-artige Umsetzung darin. Sprints liefern schrittweise auf den festen Termin hin, wobei frühe Sprints minimal brauchbare Funktionalität erzeugen und spätere Sprints den Feinschliff hinzufügen. Umfangs-Kompromisse erfolgen über explizite Änderungskontrolle statt kontinuierlicher Verfeinerung und schützen so die Terminzusage.

Agile-PM in der Praxis zum Funktionieren bringen

Agile-Softwareprojektmanagement bedeutet nicht, Sprint-Zeremonien durchzuführen oder Story Points zu schreiben. Es geht darum, Softwareprojekte erfolgreich in einer Organisation zu liefern, die auch nicht-agile Arbeit betreibt, wo der PM zwischen einem Scrum-Team und einem PMO sitzt, das Sichtbarkeit auf Portfolio-Ebene benötigt. Die Aufgabe des PM unterscheidet sich von der des Scrum Masters: Der Scrum Master verantwortet die Teamgesundheit, der PM verantwortet die Lieferverantwortung gegenüber dem Geschäft. Das Betriebsmodell des PM läuft in Sprint-Taktung, berichtet aber in Ergebnismetriken, nutzt Agile-Frameworks, die zum Arbeitsmuster des Teams passen, und integriert Jira-basierte Teamarbeit in eine PPM-basierte Portfolio-Sicht. Governance und Reporting passen sich dem Rhythmus von Agile an, statt Agile in Wasserfall-Berichtsmuster zu zwingen. Werkzeuge sind wichtig: ohne Integration zwischen Jira und einem PPM-System endet die Organisation mit drei Wahrheitsquellen, von denen keine vollständig ist. FlexiProject unterstützt dieses Muster durch eine direkte Jira-Integration, die Epics, Stories und Tasks mit erhaltenem Status, Verantwortlichem und Typ importiert, JQL-gefilterte Auswahl, User-Mapping über Systeme hinweg und eine einheitliche Zeitplan-Sicht, in der Jira-Arbeit neben nicht-agilen Projekten erscheint. Die Führung sieht das gesamte Portfolio, Entwickler bleiben in ihrem bevorzugten Werkzeug, und PMs bauen nicht mehr jede Woche dieselbe Sicht an drei Stellen neu auf. Die Aufgabe des Agile-PM ist es, dies in der Praxis zum Funktionieren zu bringen, nicht nur zu wissen, wie es in der Theorie funktionieren sollte.