The Three Phases of RTE Maturity
If you're a Release Train Engineer managing multiple teams, you've probably noticed something: the problems you're solving in month six look nothing like the ones you're tackling in year three.
That shift isn't random. Through conversations with RTEs across automotive, finance, and tech sectors, we've seen a clear pattern emerge. RTE needs evolve through three distinct phases as organisations mature with SAFe.
I spoke to Daniel Rozen, an experienced RTE in the automotive industry, who shows how understanding these phases helps you set realistic expectations, choose the right tools, and build practices that actually stick.
Phase 1: Establishment
"The first phase is the hardest one. It's establishing the routines, establishing the processes, establishing the tools. That takes a lot of energy and a lot of conflicts. That's the first year."
This is the building-from-scratch phase. Teams haven't worked together before. People are sceptical about SAFe ceremonies. Every PI planning feels like herding cats.
You're simultaneously getting teams to adopt new practices, resolving conflicts about process, building trust across groups with competing priorities, and trying to align everyone on what "done" actually means.
What success looks like:
Teams show up prepared. Basic ceremonies happen consistently. Tools get adopted. Cross-team collaboration starts emerging. Conflicts decrease.
What to focus on:
Simple processes teams can follow. Tools that reduce friction and make new practices tangible. Building relationships. Celebrating small wins.
Phase 2: Consolidation
"The second year is consolidation. Okay, now we understand each other and now we're working with the same tools. And in the consolidation part, as an RTE, you start to let go more—let the Scrum Masters take more charge into their work."
The routines work. Teams know what's expected. Scrum Masters lead their teams through planning. You're not constantly firefighting anymore.
This is where "making it happen" becomes "making it sustainable." You're letting go of day-to-day facilitation, empowering Scrum Masters to own their planning, standardising approaches, tracking delivery metrics, and building confidence the system runs smoothly.
What success looks like:
Teams self-organise during planning with minimal guidance. Dependencies get managed by teams themselves. You're consistently delivering meaningful percentages of planned work. Scrum Masters are confident. You have time to think beyond the current PI.
What to focus on:
Consistency across teams. Metrics showing delivery against plans. Dependency practices teams can execute themselves. Coaching Scrum Masters. Creating systems that work without you.
Phase 3: Strategic Optimisation
"Then the third stage—that's where I am right now—which is, okay, now everyone knows what to do. Things are working, they're delivering 70%-75% of what they're planning... Then I like challenges, you know. So I start looking into things that will add value."
The system hums. Teams deliver 70-80% of planned work. PI planning runs smoothly. Dependencies get managed proactively. Scrum Masters lead confidently.
Then leadership starts asking different questions. What should we plan three PIs ahead? How much will strategic initiatives cost in people and time? How do we prioritise competing objectives? What's our capacity next quarter? How do our Agile Release Trains connect at solution level?
Your role shifts from operational facilitation to strategic planning. You're planning multiple PIs ahead, connecting ART work to portfolio strategy, estimating resource needs, optimising value delivery, and thinking about cost, capacity, and strategic alignment.
What success looks like:
Sustained 75-80% delivery. Proactive capacity planning for future PIs. Clear connection between team work and business strategy. Data-driven programme decisions. Teams improving without your intervention.
What to focus on:
Strategic roadmap planning beyond current PI. Understanding business value and cost of ART objectives. Capacity planning across multiple PIs. Connecting ART planning to portfolio decisions. Evolving tools and practices for strategic work.
Don't Judge Phase 1 by Phase 3 Standards
New RTEs sometimes get frustrated their teams aren't delivering predictably in the first six months. But establishing foundations takes time.
If you're getting teams to show up, collaborate, and start following the process, that is success in Phase 1.
"The first phase is the hardest one... That takes a lot of energy and a lot of conflicts."
The consolidation phase builds trust. Teams learn they can deliver what they commit to. Leadership learns the system works. You learn it runs without constant firefighting.
When teams deliver consistently and mechanics work smoothly, organisations naturally ask for strategic thinking. That's not a failure of earlier practices. It's evidence they're working well enough that leadership wants to leverage them strategically.
How Programs Supports This Journey
We built Easy Agile Programs specifically to help teams and RTEs through establishment and consolidation, where sustainable practices get built.
Making Cross-Team Planning Tangible
When teams start planning together at scale, abstract concepts need concrete expression.
"It's a different view that Jira doesn't provide."
Teams see how their work connects to others. Dependencies become visible. PI planning stops being theoretical and becomes something they can actually do.
The biggest barrier to adoption is tool friction. When teams maintain epics in Jira and recreate them in planning boards, they resist the process.
"We decided to look for a tool that will allow us to connect to Jira directly and not do double booking—one booking in Jira and then creating post-its, which is useless."
Programs eliminates this. Teams plan once, in a tool already integrated with their daily workflow.
Building Consistency and Confidence
As teams mature, standardisation becomes critical.
"Standardisation. That each team can put their epics quite easily, plan their user stories, plan their story points. They can explain the objectives that they have committed to, what they have not committed to."
Every team plans the same way. This consistency makes it easier to see patterns, compare performance, and build organisational muscle memory.
"It helps them to plan according to their capacity, which is super important."
Teams learn realistic planning. Over time, this builds the predictability that defines Phase 2 success.
"It really helps them to collaborate between the different teams at the same time."
As Scrum Masters take ownership, they need tools enabling collaboration without constant RTE facilitation. Programs provides the visibility and structure making team-led planning possible.
Why This Foundation Matters
Daniel has used Programs for five years. When asked what would happen if it disappeared:
"No, then I'm completely lost... it will require a lot more of my time to work on things that don't add value, because that's what Easy Agile gives us—I mean, the facility of visualisation and transparency. So it will demand much more time from my perspective and for the Scrum Masters."
The value isn't just individual features. It's building sustainable practices that free RTEs from operational firefighting so they can focus on strategic work in Phase 3.
What Phase 3 Brings
As RTEs move into Phase 3, needs naturally evolve beyond team-level planning.
RTEs think 2-3 PIs ahead, connecting current work to long-term strategy. Questions shift from "are teams planning well?" to "are we delivering the right work across the entire ART?"
Leadership wants to understand not just what teams can do this PI, but what's possible over the next year given available capacity. ART planning needs connecting to solution and portfolio-level strategy.
These are natural evolutions as organisations mature. The practices and tools getting you to Phase 3 become the foundation for solving these new challenges.
We're committed to understanding how RTE needs evolve and building capabilities serving teams and RTEs at every maturity phase.
Lessons from Experienced RTEs
Build End-to-End Teams from the Start
"Build end-to-end teams, really looking to the flows. Not to change from a line perspective to this way of working without actually asking yourself, 'What is the end-to-end?' Many companies do that in the beginning, and then they realise that we just changed from our line to some groups, and we didn't fix anything."
Team structure determines coordination overhead. Well-structured end-to-end teams reduce dependencies and enable faster delivery.
See the Big Picture Before You Divide
"Always see the big picture, the strategic—where are we heading—and start dividing the different Agile Release Trains from that perspective and implement. So even though there are good examples at the bottom, it's better—let's see the big picture of the whole company and how to transform the whole company."
Bottom-up adoption can work, but top-down strategic thinking about how ARTs fit together prevents future restructuring pain.
Give Teams the Right Tools
"If we want to work in this way, we need to provide the right tools that will actually motivate the people to plan."
Process changes without tooling support create frustration and resistance. The right tools make new ways of working easier, not harder.
Expect the Journey to Take Time
Establishment to consolidation to strategic optimisation takes years, not months. Sustainable change happens through consistent practice over time. It’s a process of building solid foundations in Phase 1, consolidated your position in Phase 2, and optimising continuously in Phase 3.
What Phase Are You In?
Phase 1:
Focus on adoption and routines. Celebrate progress, not perfection. Choose tools reducing friction. Invest in training and relationships. Be patient.
Phase 2:
Standardise approaches. Empower Scrum Masters. Track delivery metrics. Create systems working without constant intervention. Look ahead to strategic needs.
Phase 3:
Think strategically about capacity and roadmaps. Connect ART work to portfolio strategy. Evolve tooling for programme-level visibility. Focus on value optimisation. Consider how practices scale to solution level.
Your phase determines what success looks like. Don't judge Phase 1 performance against Phase 3 expectations.
Building for Years, Not Quarters
The three-phase framework shows RTE success is a journey, not a destination.
Practices and tools serving you brilliantly in Phase 1 become the foundation for Phase 2. Consistency and predictability built in Phase 2 enable Phase 3's strategic thinking. Phase 3 brings new challenges driving further evolution.
Programs helps teams and RTEs establish sustainable practices, build consistency and confidence, and create foundations for long-term success.
We know needs evolve. We're listening to experienced RTEs about what comes next. We're building with the understanding your success is measured in years, not quarters.
Ready to see how Programs supports your phase? Learn more about Easy Agile Programs
Verwandte Artikel
Agile Best Practice5 Schritte, um die Weichen für deinen Agile Release Train zu stellen
Ihr Unternehmen hat sich endlich dazu verpflichtet, Scrum zu praktizieren. SCHREI!! 🎉 Das gelobte Land liegt vor dir — selbstorganisierte Teams, nachhaltiges Liefertempo und Autonomie, um das Richtige für das Produkt und das Team zu tun. Du kannst es kaum erwarten, loszulegen! (Spoiler-Alarm: In deiner Zukunft gibt es einen agilen Release-Train.)
Das war vor drei Monaten. Heute ist Ihre Produktentwicklungsorganisation ein großes Durcheinander. Die Teams liefern die falsche Arbeit zur richtigen Zeit. Der Code steckt in einem Regal fest und wartet darauf, dass ein anderes Team eine Abhängigkeit bereitstellt. Und das obere Management denkt darüber nach, den Stecker zu ziehen und zu den alten Wasserfallzeiten zurückzukehren.
Wenn Sie in einer großen Organisation mit mehr als 50 Softwareentwicklern und Ingenieuren arbeiten, kann Scrum eine harte Nuss sein. Je größer das Unternehmen, desto wahrscheinlicher sind teamübergreifende Abhängigkeiten, Planungskonflikte und Herausforderungen, die für Transparenz zwischen den Geschäfts-, Produkt- und Entwicklungsteams sorgen. Aber keine Angst...
SAFe zur Rettung! SAFe ist die Abkürzung für skaliertes agiles Framework. SAFe soll großen Unternehmen bei der Implementierung von Scrum helfen und bietet einen Rahmen für die Koordination der Arbeit vieler Scrum-Teams.
Teil des SAFe-Frameworks ist das Konzept eines Agile Release Trains (ART). Wenn Sie mit ARTs nicht vertraut sind, sind Sie hier richtig. Wir erklären, was eine ART ist, warum sie großen Unternehmen hilft, Softwarelösungen effizienter bereitzustellen, und wie Sie eine ART in Ihrem Unternehmen starten können.
Möchten Sie Ihr Team befähigen, das Scaled Agile Framework (SAFe) zu implementieren?
Probieren Sie einfache Agile-Programme aus
Also, was ist ein Agile Release Train?
Lassen Sie uns zunächst die Zug-Metapher erklären. Ein Zug fährt die Gleise hinunter, um ein bestimmtes Ziel zu erreichen. Unterwegs kann der Zug an mehreren Depots anhalten und neue Fracht oder Passagiere aufnehmen. Ihre Softwarelösung sind die Bahngleise. Der Beitrag des Teams zu dieser Lösung ist die neue Fracht, die Sie in den Depots abholen. Und das Ziel ist der Geschäftswert, den Sie Ihren Benutzern bieten. Einfach genug, oder?
ARTs helfen einer Gruppe von Teams, sich auf den Geschäftszweck ihrer Arbeit zu konzentrieren und die Bereitstellung von Lösungen zu koordinieren. Ihre Teams sind wahrscheinlich nach Funktionen oder Wertströmen organisiert. Ein ART identifiziert den Input und den Zeitpunkt der Beiträge der einzelnen Teams, die zur Erreichung des Geschäftsziels für den Wertstrom beitragen. Stellen Sie sich das als funktionsübergreifende Koordination bei der Einnahme von Steroiden vor.
Hier sind einige grundlegende Anforderungen für eine ART:
- Der Zeitplan ist fest, sodass der Umfang variabel ist. Aber keine Panik — sobald Ihre Teams ein gleichbleibendes Tempo erreicht haben, wird das Vertrauen in den Umfang zunehmen.
- Alle Teams müssen den gleichen Sprint- und Release-Rhythmus einhalten.
- Jedes Team folgt den Werten und Prinzipien der Agiles Manifest.
- ARTs nehmen an Planungsveranstaltungen für Programminkremente (PIs) und Inspektions- und Anpassungszeremonien (I&A) teil, die Retrospektiven und Systemdemos ähneln.
- Zwischen den Programminkrementen müssen regelmäßig Iterationen für Innovation und Planung (IP) geplant werden. Dies gibt Ihrem großen Team aus einzelnen agilen Teams Zeit, um Innovationen zu entwickeln, die Infrastruktur zu aktualisieren oder an speziellen Schulungen oder einer Hot-Tech-Konferenz teilzunehmen. IP-Iterationen bieten auch einen guten Puffer für den Fall, dass Ihr PI hinter dem Zeitplan zurückbleibt.
Wenn Ihr Unternehmen groß genug ist, benötigen Sie möglicherweise mehrere Agile Release Trains, die sich auf unabhängige Wertströme konzentrieren. Wenn das der Fall ist, benötigen Sie möglicherweise eine zusätzliche Koordinationsebene, die in einer Lösungszug. Aber lassen Sie uns nicht überholen.
Prinzipien eines agilen Release-Trains
Ein Agile Release Train (ART) orientiert sich am Scaled Agile Framework (SAFe), um sicherzustellen, dass mehrere agile Teams sich aufeinander abstimmen und nahtlos zusammenarbeiten können. Hier sind die Kernprinzipien, die einem Agile Release Train zugrunde liegen:
Fester Zeitplan
ARTs halten sich an einen vordefinierten Zeitplan, um die Arbeit konsistent abzuliefern. Dieser Zeitplan ist in Form von Programminkrementen (PIs) organisiert, die in der Regel 12 Wochen lang sind. Der feste Rhythmus hilft den Teams, ihre Arbeit effizient zu planen und durchzuführen.
Zweiwöchentliche Trittfrequenz
Ähnlich wie einzelne agile Teams in Sprints arbeiten, arbeiten ARTs in zweiwöchigen Segmenten, den sogenannten Systeminkrementen. Dieser regelmäßige Rhythmus ermöglicht kontinuierlichen Fortschritt und schnelle Feedback-Zyklen.
Bekannte Geschwindigkeit
Die Kapazität des Zuges, Arbeit mit einem bestimmten Pi — der sogenannten Geschwindigkeit — zu produzieren, wird aus historischen Leistungsdaten abgeleitet. Durch die Aufteilung von Projekten in kleinere Aufgaben können Teams Prioritäten setzen und wichtige Funktionen effektiver bereitstellen.
Schrittweise entwickeln, auf Abruf veröffentlichen
Während die Entwicklung einem starren Zeitplan folgt, ist das Veröffentlichungsdatum flexibel und hängt vom Projektabschluss ab. Dieser Ansatz ermöglicht es den Teams, den Kunden kontinuierlich einen Mehrwert zu bieten, ohne durch feste Veröffentlichungsdaten eingeschränkt zu sein.
Planung der Programminkremente
Die PI-Planung ist ein Eckpfeiler, bei dem alle agilen Teams innerhalb der ART zusammenkommen, in der Regel persönlich, um strategische Ziele für das bevorstehende Inkrement festzulegen. Diese kollaborative Planung stellt sicher, dass alle an einem Strang ziehen und auf gemeinsame Ziele hinarbeiten.
Innovation und Planung
Am Ende jedes PI nehmen die Teams an einer Innovations- und Planungsveranstaltung (IP) teil. Dieser Zeitraum ist der Planung der nächsten Stufe, der Durchführung von Bildungsaktivitäten und der Erfüllung der Infrastrukturanforderungen gewidmet.
Prüfen und anpassen
Um die kontinuierliche Verbesserung zu fördern, veranstalten ARTs am Ende jedes PI eine Veranstaltung zur Überprüfung und Anpassung (IA). Die Teams bewerten ihre Fortschritte und identifizieren Verbesserungsmöglichkeiten im Rahmen eines Workshops zur Problemlösung. So stellen sie sicher, dass sie ihre Prozesse ständig verfeinern und bessere Ergebnisse erzielen.
Rollen in einem SAFe Agile Release Train
Im Allgemeinen verwenden Teams eine ART in einer Scrum-Umgebung, aber SAFe- und agile Release-Train-Konzepte können auf jede agile Methodik angewendet werden, einschließlich Extreme Programming (XP), Lean oder Kanban. Unabhängig von der von Ihnen gewählten agilen Methode sind bestimmte Rollen erforderlich, um eine ART durchzuführen.
Agile Teams
Ohne agile Teams kann es keine ART geben. Danke, Captain Obvious. 🙄
Ein Unterschied zwischen SAFe und traditionellem Scrum besteht darin, dass ARTs es Ihnen ermöglichen, mit Teams zusammenzuarbeiten, die sich einer bestimmten Funktion widmen, wie Frontend- oder Backend-Entwicklung, Qualitätssicherung, DevOps, Sicherheit sowie Geschäfts- oder Produktfunktionen. ART selbst ist funktionsübergreifend, sodass Ihre Teams dies nicht tun müssen.
Jedes Team muss einen Scrum Master und Product Owner haben, genau wie in Scrum.
Release Train Engineers (RTEs)
So wie Scrum Master ihren Teammitgliedern helfen, die Scrum-Prinzipien und Best Practices zu befolgen, sind Release Train Engineers dienende Führungskräfte, die dasselbe für den agilen Release Train tun. RTEs helfen dabei, die korrekte Ausführung von Programminkrementen sicherzustellen, Blockaden zu beseitigen, Risiken zu managen und mit den Teams an Verbesserungen zu arbeiten.
Release Train Engineers berichten in der Regel an ein Agile Management Office oder im Fall von Lean an das Portfoliomanagement-Team.
Produktmanager
Während einige traditionelle Scrum-Teams beide verwenden Produktmanager SAFe arbeitet in einer solchen Größenordnung, dass beide Rollen erforderlich sind. Der Produktmanager bestimmt die Vision, die Roadmap und den Feature-Backlog, während der Product Owner dafür verantwortlich ist, das PI-Ziel mit dem Team zu definieren und die Funktionalität auszuführen.
Einfache agile Programme ermöglicht es Release Train-Ingenieuren und Programmmanagern, Programme effektiv zu verwalten, um eine Abstimmung im großen Maßstab zu gewährleisten.
Probieren Sie einfache Agile-Programme aus
Systemarchitekten
Auch hier ist aufgrund der Größe, in der SAFe-Teams arbeiten, ein Systemarchitekt erforderlich, um die übergeordnete Struktur des Gesamtsystems zu entwerfen, zu bestimmen, wie jedes Teil in das Puzzle passt, und stabile Integrationspunkte zu schaffen, um Daten und Prozesse in ein zentralisiertes ERP zu integrieren.
Geschäftsinhaber
Die Geschäftsinhaber sind dafür verantwortlich, Geschäftsergebnisse wie Umsatz- oder Kundengewinnungsziele zu erreichen. Als Hauptakteur von ARTS agieren Geschäftsinhaber auf strategischer Ebene und werden an Diskussionen über Vision, Roadmap und Programminkrementierung teilnehmen. Ihre Aufgabe besteht darin, sicherzustellen, dass die Produkte so gebaut werden, dass sie bestimmte Geschäftsziele erfüllen.
Kunden
Kunden sind die ultimativen wirtschaftlichen Käufer oder werthaltigen Nutzer der Lösung. Ihr Feedback und ihre Bedürfnisse sind entscheidend für den Erfolg der ART.
Systemteams
Systemteams helfen in der Regel beim Aufbau und der Wartung von Entwicklungs-, kontinuierlichen Integrations- und Testumgebungen. Sie spielen eine entscheidende Rolle dabei, sicherzustellen, dass die Infrastruktur die ART effektiv unterstützt.
Geteilte Dienste
Zu den gemeinsamen Diensten gehören Spezialisten, die für den Erfolg einer ART erforderlich sind, die aber nicht einem bestimmten Zug gewidmet werden können. Dazu gehören häufig Datensicherheitsexperten, Informationsarchitekten, Site Reliability Engineers (SRE), Datenbankadministratoren (DBAs) und viele mehr.
Starte mit deinem Agile Release Train
Also, du bist bereit, auf die ART zu springen! Großartig! Lassen Sie uns die Schritte durchgehen, um Ihnen den Einstieg in Ihre Reise zu erleichtern.
1. Beginne mit dem Training
Sparen Sie nicht an diesem. Sie haben Ihre agilen Praktiken wahrscheinlich mit etwas Training begonnen. Machen Sie das Gleiche hier. All die harte Arbeit und die besten Absichten der Welt können dir nicht helfen, wenn du kein solides Verständnis der Grundlagen hast.
Neben der Schulung der Teams sollten Sie auch Ihre Führungsteams und Führungskräfte schulen. Genau wie zu der Zeit, als Ihr Unternehmen agile Prinzipien eingeführt hat, sollten Sie sicherstellen, dass Sie die Zustimmung dazu haben, ein Verständnis dafür haben, wie agile Release Trains funktionieren und welche Rollen zu ihrer Unterstützung erforderlich sind.
2. Identifizieren Sie Ihre Wertströme
In SAFe gibt es zwei Arten von Wertströmen: betriebliche und entwicklungsorientierte. Ein operativer Wertstrom konzentriert sich darauf, den Endnutzern den Wert zu bieten, der durch den Wertstrom aus der Entwicklung geschaffen wurde. Ein Beispiel könnte die Erfüllung einer Bestellung von einer E-Commerce-Website sein.
Ein Entwicklungswertstrom konzentriert sich auf die Entwicklung der Geschäftslösung, beispielsweise auf den Aufbau einer E-Commerce-Website.
Die Identifizierung Ihrer Wertströme ist wichtig, bevor Sie Personen und Teams auswählen, die an dem Wertstrom arbeiten, und die zusätzlichen Rollen besetzen, die für die ART erforderlich sind. Sobald die Spieler ausgewählt wurden, können Sie mit der Planung beginnen.
3. Bereiten Sie das Programm Increment Backlog vor
Es ist Zeit, deine zu verfeinern Programm-Rückstand und machen Sie sich bereit für die PI-Planung. Planung und Verfeinerung ist am besten, wenn Sie sich persönlich treffen können, aber manchmal ist das in großen Organisationen unmöglich. Wenn Sie ein verteiltes Team haben, stellen Sie sicher, dass Sie einen guten Backlog haben Tool wie Jira um virtuelle Besprechungen zu ermöglichen.
🚨 Auf der Suche nach der kompletten PI Planning-Lösung für Jira?
Probieren Sie einfache Agile-Programme aus
Ideal für die dezentrale, ferngesteuerte oder persönliche Planung von Programminkrementen.
Nehmen Sie an einer Demo teil!
Erstellen Sie Ihre User Stories auf Programmebene, damit sie in eine zweiwöchige Timebox passen, und planen Sie Ihre erste Veröffentlichung. Lassen Sie in der Iteration etwas Spielraum, bis Ihre Teams eine vorhersehbare Geschwindigkeit erreicht haben.
4. Starten Sie das Programm Increment
Jetzt ist es wie immer Scrum. Sie haben Ihren Sprint startklar — führen Sie ihn einfach wie gewohnt aus. Am Ende des Sprints kannst du den Beitrag deiner Teams zum Release Train hinzufügen.
5. Spülen und wiederholen
Agile Release Trains sind ein kontinuierlicher, iterativer Bereitstellungsmechanismus. Genau wie bei traditionellem Scrum werden Ihre Teams etwas entwickeln, veröffentlichen, lernen und dann wieder mit der Entwicklung beginnen. Vergessen Sie nicht, eine Innovations- und Planungsiteration einzuplanen, um dem Team eine Pause vom Trubel zu geben und Zeit zu geben, ihre Systeme oder ihr Team zu verbessern.
Bist du bereit, an Bord zu springen?
SAFe- und Agile Release Trains helfen Teams dabei, agile Entwicklungspraktiken beizubehalten, wenn sie an Größe zunehmen. Was auf den ersten Blick kompliziert erscheinen mag, ist in Wirklichkeit ein gut orchestrierter Prozess, der für die Teamsynchronisierung gemäß den Geschäftswertströmen konzipiert ist.
Nutze das Scrum-Wissen, das du in den einzelnen Teams hast, und trainiere dann in SAFe-Praktiken und bereite dich darauf vor, deinen ersten agilen Release-Train zu erstellen. Sie lernen, indem Sie es tun, aber ersparen Sie sich und Ihrem Unternehmen einige Kopfschmerzen und Geld und investieren Sie zuerst in Schulungen.
Wir haben in diesem Artikel auf einige großartige Lernartikel verlinkt, aber hier sind noch ein paar weitere, die Ihnen helfen sollen, Ihr SAFe-Lernen zu beschleunigen:
- Der ultimative Leitfaden zur PI-Planung [2021 SAFe Edition]
- SAFe Program Board 101: Alles, was Sie wissen müssen
- Scaled Agile Framework (SAFe) 5.0 — Der einfache Agile Review
- Optimieren Sie Ihre Arbeitsabläufe mit einer besseren PI-Planungssoftware
- So bereiten Sie sich auf die verteilte PI-Planung vor
Viel Glück auf deiner agilen Reise und bleib SAFe! (Zu kitschig? 🤦🏽 ♀️)
Agile Best PracticeSo gehen Sie Ihren agilen Release-Plan für eine erfolgreiche Entwicklung an
Scrum-Teams erstellen Release-Pläne, um erfolgreiche Produktveröffentlichungen zu unterstützen. Dies hilft ihnen, sich weiterhin auf die Produktvision und die zu erbringenden Funktionen zu konzentrieren.
Hier werden wir die agile Release-Planung untersuchen, warum sie wichtig ist und welche Best Practices für erfolgreiche Releases gelten.
Was ist agile Releaseplanung?
Da Softwareprojekte unvorhersehbar sind, hilft die Release-Planung den Teammitgliedern, ihren Arbeitsablauf zu priorisieren. Ein Release-Plan konzentriert sich darauf, bestimmte Produktfunktionen marktreif zu machen. Er sollte den Produktumfang, das Veröffentlichungsdatum für die Fertigstellung der Funktionen und die für jede Version benötigten Ressourcen berücksichtigen.
Das Entwicklungsteam verwendet Feedback aus früheren Produktiterationen als Grundlage für seine Planung. Product Owner und Scrum-Teams treffen sich, um den agilen Release-Plan zu besprechen und sicherzustellen, dass jeder die erforderliche Produktfunktionalität und den Aufwand versteht, der für jedes einzelne Inkrement erforderlich ist.
Anstatt eine signifikante Produktveröffentlichung zu planen, teilen die Teams den Projektumfang in kurze Sprints auf. Viele Scrum-Teams verwenden Jira um ihnen zu helfen, ihre Sprints zu visualisieren und den Projektstatus in Echtzeit zu verfolgen.
Warum ist Release-Planung wichtig?
Eine agile Release-Planung ist aus mehreren Gründen von entscheidender Bedeutung:
- Strategische Ausrichtung: Es hilft dabei, die Entwicklungsaktivitäten an den allgemeinen Geschäftszielen und Kundenerwartungen auszurichten, sodass die wertvollsten Funktionen zuerst bereitgestellt werden
- Berechenbarkeit: Ein klarer Release-Plan sorgt für Berechenbarkeit, setzt realistische Erwartungen für die Beteiligten und verbessert die allgemeine Projekttransparenz
- Risikomanagement: Die frühzeitige Identifizierung potenzieller Risiken und Abhängigkeiten hilft dem Team, diese proaktiv anzugehen und die Wahrscheinlichkeit erheblicher Verzögerungen oder Rückschläge zu verringern
- Verbesserte Zusammenarbeit: Es fördert die Zusammenarbeit zwischen Teammitgliedern und Stakeholdern und fördert eine klare Kommunikation und ein gemeinsames Verständnis der Projektziele
- Trennung von Produkt-Roadmaps: Während eine Produkt-Roadmap eine allgemeine Strategie für das Produkt vorgibt, konzentriert sich ein Release-Plan auf die Umsetzung. Wenn Teams diesen Unterschied verstehen, können sie beide Tools effektiv nutzen.
Die Planung von Projektversionen hilft Softwareentwicklungsteams dabei, jedes Projekt schrittweise zu planen, zu leiten und zu veröffentlichen, um das Kundenerlebnis zu verbessern. Teams verwenden diese Methode häufig für kurze Sprints der Produktentwicklung.
Die Release-Planung bietet Agile- und Scrum-Teams eine solide Richtung für den Abschluss ihrer Projekte. Die Teammitglieder nutzen diese Gelegenheit auch, um Sprint-Feedback zu nutzen, um Schritte zu erstellen, die auf die Projekt-Roadmap der nächsten Version abgestimmt sind.
Den Produktplan zusammenstellen
Die Release-Planung scheint komplex zu sein, aber mit etwas Weitblick kann sie einfach sein. Lassen Sie uns jeden Teil des Prozesses überprüfen.
1. Wer leitet den Release-Plan?
In der Regel orientiert sich das Produktentwicklungsteam an der Scrum Master oder der Product Owner. Während des Treffens wird dieser Leiter Fragen zu den Produkt-Backlog um sicherzustellen, dass die Sprint-Diskussionen mit dem Endprodukt übereinstimmen.
Alle Produktbeteiligten sollten am Veröffentlichungsplan teilnehmen, um sicherzustellen, dass ihr Feedback berücksichtigt wird. Ohne den Input aller an der Produktentwicklung Beteiligten riskiert das Team, wichtige Informationen zu verpassen, um die Produkt-Roadmap auf Kurs zu halten.
2. Aspekte des agilen Release-Plans
Der Release-Plan soll zwar agil sein, folgt aber auch einem strengen Prozess, um sicherzustellen, dass die Teams die Produkt-Roadmap im Auge behalten.
Agile Teams nehmen alle Diskussionen zur Sprint-Planung auf und werten diese aus, um die Ergebnisse neuer Produkte detailliert zu beschreiben. Die meisten Unternehmen verwenden in ihrem Release-Planungsprozess zwar unterschiedliche Ansätze, aber Sprint-Überprüfung sollte die folgenden Aspekte beinhalten:
- Die vereinbarte Produktentwicklung wird in jeder Phase des Sprints veröffentlicht
- Eine Richtung für jede neue Produktveröffentlichung
- Spezifische aktuelle und zukünftige Iterationen sind in jeder kommenden Version fällig
- Welche Merkmale und Funktionen sollten die Iteration begleiten
- Spezifische Aufgabenanforderungen für jede Feature-Bereitstellung, um das Veröffentlichungsziel zu erreichen
Durch einen eingehenden Release-Planungsprozess nutzen Softwareentwicklungsteams den Wert dieser Sprint-Besprechungen. Die Fähigkeit, bei Bedarf schnell die Richtung zu ändern, stellt sicher, dass das Team das bestmögliche Produkt veröffentlicht.
Diese ständige Wiederholung bei jedem Sprint-Review ist auch im dynamischen Umfeld der Produktentwicklung wertvoll.
Dieses Maß an Planung, kombiniert mit einem iterativen Zeitplan, um der Dynamik von Software Rechnung zu tragen, macht die agile Produktentwicklung so wertvoll.
3. Diskussionen im Sprint-Meeting
Die Diskussionen in Sprint-Meetings drehen sich um Benutzerberichte, Produkt-Backlog und Produkt-Backlog-Elemente. Bei der Scrum-Versionsplanung werden auch andere Themen wie Abhängigkeiten und Produktfunktionen berücksichtigt. Andere Aspekte, über die das Team spricht, betreffen das nächste Release und die Anzahl der Sprints, die sie abschließen und liefern müssen.
Im Wesentlichen müssen die Teammitglieder die Produktvision im Auge behalten, um eine effektive Release-Planung zu ermöglichen. Diese Vision hilft den Teammitgliedern dabei, die Mindestanzahl von Markt-Sprint-Funktionen und deren Veröffentlichungsdaten zu ermitteln.
Die Diskussionen im Sprint-Meeting sollten Folgendes beinhalten:
- Priorisierung des Release-Plans für bevorstehende neue Produktmerkmale und Funktionen
- Bewertung und Einbeziehung von Stakeholder-Feedback für jeden Sprint
- Detaillierte Beschreibungen der Sprint-Ergebnisse und ob diese in die Kategorie der kurzfristigen Produktanpassungen oder der größeren längerfristigen Releases fallen
- Welche Produktversion wird zur Veröffentlichung bereit sein und die ideale Reihenfolge der Produktversionen, um jedes Veröffentlichungsziel zu erreichen
Entwicklungsteams erstellen mehrere Produktversionen. Nachdem sie diese Versionen erstellt haben, priorisieren sie sie, um die wichtigsten Versionen für die Benutzer freizugeben.
Ein Teil des Zwecks der Versionsplanung besteht darin, sicherzustellen, dass sich alle Beteiligten auf derselben Produktentwicklungsseite befinden. Ein weiteres Element dieser Besprechungen zur Sprint-Planung besteht darin, Eigenverantwortung und Akzeptanz für die Produktvision zu fördern.
Entwicklung des Release-Plans
Es gibt vier Schritte, die Softwareentwicklungsteams befolgen, um ihren Produktplan zu erstellen.
1. Die Vision schaffen
Zunächst müssen Sie die Vision für das Produkt definieren. Durch die Erstellung einer klaren Vision entsteht eine Roadmap, die das Team in jedem aufeinanderfolgenden Sprint befolgen muss. Diese Vision sollte mit der Marktnachfrage und den Zielen des Product Owners übereinstimmen.
Es ermutigt die Teammitglieder auch, zu prüfen, welche Funktionen sie priorisieren sollten. In ähnlicher Weise hilft die Produkt-Roadmap den Teams dabei, die Ressourcen zu bewerten, die sie während des Sprint-Reviews benötigen. Die Produktplanung ermöglicht es den Teams auch, flexibel zu sein. Planungsprüfungen stellen sicher, dass die Richtung geändert wird, um den laufenden Schritten Rechnung zu tragen und die allgemeinen Veröffentlichungsziele zu erreichen.
2. Priorisierung des Produkt-Backlogs
Nach der Definition der Vision konzentrieren sich die Teammitglieder darauf, Funktionen im Produkt-Backlog zu priorisieren. Hier müssen die Beiträge der Stakeholder mit der Vision übereinstimmen, um User Stories erfolgreich umzusetzen. Geschichten von Nutzern sind für den Prozess von entscheidender Bedeutung, da sie den Hintergrund für die detaillierte Beschreibung der Produktmerkmale oder Funktionen bilden.
Das Produktmanager gibt dem Team in dieser Phase Anweisungen, um einen tragfähigen Release-Plan zu entwerfen. Dieser Release-Plan muss die Ziele der Produktveröffentlichung, die Veröffentlichungsdaten und die Priorisierung der User Stories enthalten.
3. Richten Sie das Scrum Planungstreffen ein
Der nächste Schritt in der Planungssitzung besteht darin, dass die Interessengruppen den Plan überprüfen. Die Teammitglieder haben nun die Möglichkeit, die Ergebnisse an die Vision anzupassen.
Jeder muss zu diesem Zeitpunkt dem Release-Plan zustimmen, bevor er mit der nächsten Version fortfahren kann.
Tagesordnung der Sitzung
Das Einrichten einer Besprechungsagenda hilft bei der Verwaltung des Veröffentlichungsplans. Zu den wesentlichen Elementen der Agenda für das Scrum-Framework gehören:
1. Bewertung des Produktplans
Das Scrum-Team überprüft die Produkt-Roadmap um sicherzustellen, dass jeder die Produktvision und die Ziele akzeptiert.
2. Bewertung der Architektur
Bei jeder Veröffentlichung evaluieren das Scrum-Team und der Product Owner die Architektur des vorherigen Sprints. Sie untersuchen die technischen Details der Produktentwicklung und erörtern alle potenziellen Probleme, die sich auf die Produktveröffentlichung auswirken können.
Scrum-Teams besprechen den Umfang und die Schätzungen ihres Release-Plans. Die Teammitglieder entscheiden, ob ihre Planung das Risiko technischer Schulden beinhaltet und ob sie bestimmte Aufgabenaspekte erledigen können, z. B. die Dokumentation ihrer Arbeit, um Termine einzuhalten. Die Beteiligten überprüfen auch die Abhängigkeiten, die die Funktionalität der Produktversionen beeinflussen können.
3. Bewertung von Geschwindigkeit und Iteration
Scrum-Teams gehen frühere Iterationen durch, um ihre Geschwindigkeitsschätzungen zu überprüfen. Sie stimmen ihre Schätzungen mit dem vorgeschlagenen Iterationsplan ab, um sicherzustellen, dass sie alle wichtigen Elemente abdecken.
Der Produktmanager kontrolliert diese Bewertung, um sicherzustellen, dass den User Stories Punkte zugewiesen werden. Die Bewertung der Nutzerberichte und die Vergabe von Punkten zeigen, wie viel Aufwand das Team in jede Iteration investieren muss. Die Gesamtzahl der Story Points entspricht dann der Schätzung der Veröffentlichungstermine für jede Sprint-Version.
Das agile Team erstellt einen Iterationsplan, um während dieser Bewertung die Geschwindigkeit für den aktuellen und die nachfolgenden Sprints zu ermitteln.
Das Team erstellt den Release-Umfang, der alle notwendigen Releases beinhaltet. Der Scrum-Master weist jedem Teammitglied die Arbeit zu, und alle Beteiligten stimmen dem Plan zu, bevor sie mit dem nächsten Schritt fortfahren.
4. Einigung über die Definition von „Fertig“
Die Teammitglieder müssen nun besprechen, was für jede Feature-Veröffentlichung als erledigt gelten soll. Die Teammitglieder müssen abwägen, ob ihre Bewertung der User Stories alle Akzeptanzkriterien des Product Owners für die Veröffentlichung erfüllt. Sobald sie bei ihrer Bewertung nachweisen können, dass die Akzeptanzkriterien erfüllt sind, wissen sie, dass eine Veröffentlichung gültig ist.
Die Definition von erledigt muss bestätigen, dass die Teammitglieder alle ihnen zugewiesenen Aufgaben für die User Story abgeschlossen haben. Die Teammitglieder müssen außerdem jede Aufgabe aufzeichnen, damit der Product Owner ihre Arbeit beurteilen kann.
5. Füllen Sie den Zeitplan für die Produktveröffentlichung aus
Der Projektmanager kann jetzt den Zeitplan für den Versionsplan ausfüllen und abschließen. Alle Beteiligten sollten auf den Kalender zugreifen können, um den Fortschritt zu verfolgen. Dieser Zeitplan für die Veröffentlichung hilft allen Beteiligten, sich auf die Ergebnisse und Veröffentlichungstermine der Produkte zu konzentrieren.
Bewährte Methoden für eine agile Release-Planung
Um Ihre agile Release-Planung effektiv zu gestalten, folgen Sie diesen wichtigen Best Practices:
- Stellen Sie eine klare Produktvision auf: Definieren Sie eine klare, gemeinsame Vision, die den Bedürfnissen und Geschäftszielen Ihrer Kunden entspricht. Dies hilft Ihrem Team dabei, die Prioritäten und Entscheidungen während des gesamten Projekts zu steuern.
- Priorisieren Sie Funktionen nach Kundennutzen: Identifizieren und priorisieren Sie eindeutig die Funktionen, die Ihren Kunden und dem Unternehmen den größten Mehrwert bieten. Dies hilft Ihrem Team, sich darauf zu konzentrieren, wirkungsvolle Ergebnisse zu erzielen.
- Überprüfe regelmäßig deine Ziele und passe sie an: Agile Release-Pläne sind nicht in Stein gemeißelt. Regelmäßige Check-ins stellen sicher, dass die Ziele relevant bleiben, auch wenn sich die Prioritäten aufgrund von Kundenfeedback, Geschäftsanforderungen oder Marktveränderungen ändern.
- Rollen und Verantwortlichkeiten klären: Stellen Sie sicher, dass jeder im Team seine Rolle versteht und weiß, was von ihm erwartet wird. Klare Rollen erhöhen die Verantwortlichkeit und helfen, Missverständnisse oder Doppelarbeit zu vermeiden.
- Definieren Sie eine „Definition von Fertig“: Legen Sie klare Akzeptanzkriterien für das fest, was ein abgeschlossenes Feature oder eine abgeschlossene Version ausmacht. Dadurch wird die technische und funktionale Vollständigkeit vor der Bereitstellung gewährleistet.
- Integrieren Sie DevOps-Praktiken: Die Abstimmung der agilen Release-Planung mit den DevOps-Methoden verbessert die Zusammenarbeit zwischen Entwicklungs- und Betriebsteams und verbessert die Bereitstellungshäufigkeit und Zuverlässigkeit.
- Planen Sie kleine, inkrementelle Releases: Teilen Sie große Produktveröffentlichungen in kleinere Abschnitte auf. Mit diesem Ansatz kann Ihr Team regelmäßig Updates bereitstellen, frühzeitig Benutzerfeedback einholen und sich schnell an Kundenanforderungen anpassen.
Holen Sie sich Hilfe bei Ihrer Release-Planung
Agile Releaseplanung ist ein wichtiger Bestandteil des Erfolgs des Softwareentwicklungsteams. Erstellen Sie einen umfassenden agilen Release-Plan für kleinere oder größere Releases, und Sie machen sich das Leben für eine bevorstehende Veröffentlichung einfacher. Wenn Sie sich auf den Release-Plan-Kalender konzentrieren, können Sie die Produktverantwortlichen und Teammitglieder über die gesamte Produktvision auf dem Laufenden halten.
Bei Easy Agile bieten wir Tools an, die die agile Release-Planung direkt in Jira unterstützen. Einfacher agiler Teamrhythmus unterstützt die kollaborative Release-Planung in Jira. Das stark visuelle Story-Map-Format verwandelt das flache Jira-Backlog in ein aussagekräftiges Bild der Arbeit, was es einfacher macht, deinen Backlog zu verwalten und deine Veröffentlichung zu planen.
Agile Best PracticeEine einfache Anleitung zur Erstellung intelligenter PI-Ziele
Haben Ihre Teams eine klare Vorstellung davon, was getan werden muss — und warum?
Einer der Schlüssel zu Agilität besteht darin, sich auf die Arbeit zu konzentrieren, auf die es ankommt. Das bedeutet, an Projekten zu arbeiten, die dem Unternehmen einen Mehrwert bieten und zur Leistung beitragen. In vielen Unternehmen können sich Teams jedoch über die neuesten Funktionen oder Entwicklungen auf dem Laufenden halten, ohne zu verstehen, wie das mit dem Gesamtbild dessen zusammenhängt, was dem Unternehmen wichtig ist.
Damit sich Ihr Team auf das konzentrieren kann, was es sich vorgenommen hat, um Mehrwert zu schaffen und Geschäftsergebnisse zu erzielen, ist die Festlegung intelligenter PI-Ziele unerlässlich. Wir schauen uns an, warum sie so wichtig sind, was ein gutes PI-Ziel ausmacht und wie Sie sie in Ihrem Unternehmen einsetzen können.
Auf einen Blick:
- PI-Ziele helfen Teams zu verstehen, wie wichtig das, was sie tun, für das Unternehmen wichtig ist.
- Gute PI-Ziele sind SMART — spezifisch, messbar, erreichbar, relevant und zeitgebunden.
- Durch die Verknüpfung von Funktionen mit PI-Zielen innerhalb desselben Tools können Teams und Stakeholder leichter erkennen, wie die Arbeit die Geschäftsziele erreicht.
Was sind PI-Ziele?
Wenn sich ein agiles Team zu einem PI-Planungssitzung, es gibt zwei wichtige Ausgänge:
- Der Programmausschuss (ART-Planungstafel in SAFe 6.0) behandelt allgemeine Informationen wie Funktionen, Abhängigkeiten zwischen Teams und Meilensteine. A Merkmal ist eine vereinbarte Arbeit, die als wichtig für die Erfüllung der Geschäftsanforderungen eingestuft wurde. Für Softwareentwicklungsteams könnte dies eine neue Produktfunktion sein. Für Marketingteams kann es sich um eine Aktualisierung der Website oder eine Werbekampagne handeln.
- PI-Ziele verknüpfen Sie die geplanten Funktionen mit umfassenderen Geschäftszielen und -werten. Dies hilft dabei, die zu erledigenden Aufgaben mit den umfassenderen Geschäftszielen in Einklang zu bringen. Sie werden dann unterteilt in engagiert und nicht gebunden Ziele.
- Engagierte Ziele sind diejenigen, von denen das Team überzeugt ist, dass sie sie im Rahmen des Programminkrements erfüllen können. Diese Ziele wurden vom Team im Rahmen einer Vertrauensabstimmung festgelegt.
- Nicht festgelegte Ziele sind diejenigen, bei denen das Team wenig Vertrauen in die Umsetzung hat, die aber dabei helfen können, einen Puffer in den PI einzubauen. Dies liegt daran, dass das Ergebnis dieser Ziele zwar nicht sicher ist, sie jedoch in der Kapazität und dem Plan des Teams für den PI enthalten sind, falls die Kapazität nach der Erfüllung der zugesagten Ziele bestehen bleibt.
Die Vorteile intelligenter PI-Ziele
PI-Ziele verknüpfen, woran Teams arbeiten, mit dem, was dem Unternehmen wichtig ist. Sie sorgen für eine Abstimmung mit den Geschäftszielen, indem sie die Funktionen eindeutig mit dem Geschäftswert verknüpfen. Dadurch wissen die Teams, wie ihre Arbeit einen Mehrwert bietet.
Intelligente PI-Ziele bieten dafür einen Rahmen. Sie tragen dazu bei, Vertrauen aufzubauen, eine gemeinsame Sprache zu schaffen und eine klare Richtung vorzugeben. Jeder im Team kann dann verstehen, was er tut, warum er es tut und warum es wichtig ist.
Ohne intelligente PI-Ziele können Teams Zeit mit Aufgaben verbringen, die dem Unternehmen keinen Mehrwert bieten und die Agilität beeinträchtigen.
PI-Ziele sind für Ihre Fähigkeit, den Erfolg zu messen, von entscheidender Bedeutung. Die Fertigstellung von Funktionen allein reicht nicht aus — sie müssen zu einem Geschäftsergebnis führen. Sie helfen den Teams, sich darüber im Klaren zu sein, warum die von ihnen geleistete Arbeit wichtig ist, und definieren, wie Erfolg aussieht.
Was macht ein gutes PI-Ziel aus?
Wir haben darüber gesprochen warum PI-Ziele sind so wichtig, und jetzt erklären wir es was ist ein gutes PI-Ziel.
Gute PI-Ziele:
- Ermöglichen Sie dem Unternehmen, die Ergebnisse in einer Zeitrahmen festlegen
- Sorgen Sie für Klarheit darüber, wie die geplante Arbeit in die großes Bild
- Verbessern Sie die Kommunikation zwischen Teams und Stakeholdern
- Schließ nicht mehr ein als 7 bis 10 Ziele insgesamt
- Stimmt mit dem überein, was Das Geschäft kümmert sich um
- Sind sich darüber im Klaren, warum es wichtig ist und was es liefern wird
- sind von irgendjemandem verstanden wer holt sie ab
sind KLUG — das heißt, spezifisch, messbar, erreichbar, relevant und zeitgebunden
PI-Ziele müssen SMART sein
Wenn Sie das SMART-Framework zur Zielsetzung verwenden, um Ihre PI-Ziele zu schreiben, können Sie Ihre Ziele klar und präzise halten. In diesem Rahmen muss Ihr PI-Ziel wie folgt lauten:
- Spezifisch — Geben Sie klar und deutlich das beabsichtigte Ergebnis Ihres Ziels an.
- Messbar — Beschreiben Sie, was Ihr Team tun muss, um das Ziel zu erreichen, und wie es den Erfolg quantifizieren wird. Das Feedback der Stakeholder sollte Teil davon sein.
- Erreichbar — Stellen Sie sicher, dass das Ziel realistisch ist und in der Kontrolle und dem Einfluss Ihres Teams liegt.
- Relevant — Richten Sie das Ziel an den allgemeinen Geschäftszielen aus.
- Zeitgebunden — Legen Sie einen angemessenen Zeitrahmen fest, um das Ziel innerhalb des PI zu erreichen.
Team PI ObjectiveEnsure Easy Agile Server-Kunden haben eine nahtlose Option zur Migration in die Cloud, indem sie JCMA und den Import/Export von Websites bis Ende des dritten Quartals implementieren.
Tipps zum Schreiben von INTELLIGENTEN (und intelligenten) PI-Zielen
In der Regel führen viele Teams PI-Planungssitzungen in einem Tool durch und verwenden dann ein anderes Tool (wie Confluence), um die PI-Ziele aufzuzeichnen.
Die Trennung der PI-Ziele von den Planungssitzungen macht es für das Team und die Stakeholder jedoch schwierig zu erkennen, wie die Arbeit die Weichen für das Unternehmen verändert.
Mit dem Einfache agile Programme, Sie können Ihre Funktionen innerhalb desselben Tools direkt mit Ihren Zielen verknüpfen. Sie sind auch in der Lage, das Ziel in den Easy Agile-Programmen zu beschreiben und ihm einen Geschäftswert zuzuweisen:
Durch die Verknüpfung von Funktionen und PI-Zielen innerhalb desselben Tools erhalten Teams und Geschäftsbeteiligte einen klaren Überblick über die Arbeit. Sie können sehen, wie ihre Arbeit dazu beiträgt, Geschäftsziele zu erreichen.
Erfahre mehr
Die Verwendung des SMART-Frameworks zur Definition von PI-Zielen hilft Ihren Teams, sich auf die richtige Arbeit zu konzentrieren. Sie richten Projekte auf umfassendere Geschäftsziele aus und sorgen gleichzeitig für ein gemeinsames Verständnis aller Teams. Indem sie auf dasselbe Ziel hinarbeiten, tragen sie dazu bei, dass Ihre Teams und Ihr Unternehmen produktiv und agil bleiben.
Mit Easy Agile Programs ist das möglich
Bist du bereit, deine PI-Ziele in Jira zu integrieren?