PI Planning Header

PI Planning als Brücke zwischen Agile und Lean Portfoliomanagement

19 min Lesedauer

Spielen Sie derzeit mit dem Gedanken, PI Planning (das sogenannte Programm Inkrement Planning), in Ihrem Unternehmen einzuführen?

„Der Aufwand lohnt sich!“ Das zumindest würden Ihnen all jene Unternehmen sagen, die diesen Schritt bereits gegangen sind. Alles, was Sie brauchen, ist der richtige Zugang zum Thema und einen Weg, PI Planning auf Ihren Anwendungsfall anzuwenden.

In diesem Artikel wollen wir mit Ihnen über die Grundlagen von PI Planning sprechen, darüber, wie PI Planning in verschiedenen Anwendungsfällen hilft, was die Herausforderungen sind, wie Inkremente strukturiert sind, und vielleicht am wichtigsten: wie SIE damit anfangen können.

Inhaltsübersicht
  1. PI-Planung verstehen
  2. Bedeutung von Scaled Agile für Lean PPM
  3. Vorteile und Ziele des PI Planning
  4. Schlüsselelemente des PI Planning
  5. Die einzelnen PI Planning Events im Detail
  6. Typische Fehler und Herausforderungen im PI Planning
  7. Best Practices im PI Planning
  8. Fazit

PI-Planung verstehen

Kurzdefinition PI Planning:

Die Programm Inkrement Planung (PI) ist ein Ereignis aus dem SaFe Framework, das es zum Ziel hat, die Arbeit aller Teams auf eine gemeinsame Vision auszurichten. Das erlaubt es ihnen, die erforderlichen Abhängigkeiten zu identifizieren und zu planen.

Vielleicht fragen Sie sich an dieser Stelle, ob das dann überhaupt auf Ihre Arbeit anwendbar ist, was ein Inkrement ist, wie oft PI Planning gemacht wird oder was wir mit Vision meinen? Mit diesen Fragen sind Sie nicht allein, also lesen Sie weiter!

PI Planning hilft – unabhängig von Ihrer Arbeitsweise

Verfechter agilen Arbeitens haben in den letzten zwei Jahrzehnten dazu beigetragen, das Konzept zu verbreiten, und das aus gutem Grund. Scrum reichte für die Planung der Arbeit mit vielen Teams einfach nicht aus. Als die Scrum-Bewegung damals begonnen hat, feierte die IT-Welt das Agile Manifest. Jeder liebte die neue Freiheit, neue Anforderungen auf Basis empirischen Wissens zu entwickeln und Aufgaben “just in time” zu verteilen. Und das ist auch ein großartiger Weg, um bei der Arbeit, die unmittelbar ansteht, voranzukommen.

Warum also sollten Scrum-Teams PI Planning benötigen? Laut Stefan Schneider, Leiter des Produktmanagements bei Meisterplan, ist Scrum allein in der Regel nicht in der Lage, mehrere Teams effizient zu koordinieren, um die Ziele zu erreichen. Dies führte oft zu einer Art “Leerstelle”, einer “Lücke” zwischen den übergeordneten Unternehmenszielen, üblicherweise ist das eines pro Jahr, und dem, was die Sprints alle 2 Wochen erreichen würden. Diese Leerstelle kann mit PI Planning gefüllt werden.

Und wie hilft die PI-Planung bei anderen Arbeitsweisen? Wir wissen, dass dedizierte Scrum-Teams nicht für jede Art von Projekt möglich sind. Bei großen Projekten haben Sie wahrscheinlich oft eine Mischung von Methoden zur Durchführung der Arbeit oder beschäftigen auch Teams, die nicht speziell dafür abgestellt wurden. Zwar ist jedes Team hier meist sehr gut in der Lage, in seinem Bereich effektiv zu arbeiten, doch es wird schon schwierig, wenn man mehrere gleichzeitig koordinieren will.

Die Planung der Arbeit zwischen Teams, die sich gegenseitig beliefern, benötigt daher immer noch eine Koordinierungsebene, die bei Abhängigkeiten, Tests und der Release-Planung hilft. Andernfalls muss ein Team auf das andere warten und ehe man sich versieht, verzögert sich das ganze Projekt.

Geben Sie PI Planning also unbedingt eine Chance. Weiterlesen lohnt sich!

Bedeutung von Scaled Agile für Lean PPM

Wir haben viele Artikel darüber veröffentlicht, worum es bei Lean PPM geht. Zusammengefasst konzentriert sich Lean PPM auf:

  • die Wertschöpfung für das Portfolio,
  • bei gleichzeitiger Optimierung der Ressourcen (ohne Über- oder Unterlastung),
  • dem projektübergreifenden Managen von Abhängigkeiten und Risiken,
  • dem schnellstmöglichen Erreichen von Ergebnissen,
  • und der Vermeidung von Verschwendung entlang der ganzen Wertschöpfung.

Kurzum: Mit einem Lean PPM-Framework können Sie Ihre Kommunikation, Produktivität, Qualität und letztendlich die Time-to-Market verbessern.

Die Verbindung zwischen PI Planning und Lean PPM

Lassen Sie uns das Zusammenspiel von PI Planning und Lean PPM anhand einer kleinen Tabelle veranschaulichen.

Im Lean PPM hat man halbjährlich einen Strategieworkshop, bei dem die Strategie und die damit einhergehenden Bewertungskriterien für die Priorisierung von Projekten festgelegt werden. Pro Quartal findet ein Review der aktuellen Pipeline statt und noch etwas granularer, die PI-Planung alle 6 Wochen. Es gibt in unserem Beispiel also 8 Perioden oder eben Inkremente im Jahr, die eine Abstimmung erforderlich machen. (Natürlich können Sie diese Zeitspanne flexibel festlegen.)

Die Kadenz sollte in jedem Fall genügend “Kontrollpunkte” bieten, um schnell beurteilen zu können, ob es sich lohnt, die Projekte weiterzuführen und ob die Ziele dadurch erreicht werden können. Ohne die Lean-PPM-Ebene würden die Projekte weiterlaufen, und Sie würden zu spät feststellen, dass sie nicht zur Erreichung Ihrer Ziele beitragen.

 Q1Q2Q3Q4
 6 Wochen6 Wochen6 Wochen6 Wochen6 Wochen6 Wochen6 Wochen6 Wochen
Strategie-WorkshopReview der Ziele 1Review der Ziele 2
BacklogFortlaufend: neue Ideen/Projekte sammeln und mit den Zielen verknüpfen
Pipeline ReviewPipeline Review 1Pipeline Review 2Pipeline Review 3Pipeline Review 4
PI PlanningPI-1PI-2PI-3PI-4PI-5PI-6PI-7PI-8
Sprint PlanungSPSPSPSPSPSPSPSPSPSPSPSPSPSPSPSPSPSPSPSPSPSPSPSP

Wie Arbeit bewertet und priorisiert wird

Ehrlich gesagt ist dies ein längeres Thema und hängt wesentlich von der Art der Projekte ab, die durchgeführt werden. Um es kurz zu machen, kann ich ein paar Möglichkeiten aufzählen, wie Ihr Produkt, Ihre Projekte und Ihr Portfolio wahrscheinlich priorisiert werden.

#1 – Eine Person entscheidet

In der Vergangenheit wurden oft die Projekte der Person priorisiert, die am lautesten geschrien hat, die auf der Gehaltsliste ganz oben stand oder ganz stumpf danach, wer zuletzt bzw. zuerst die entsprechende Anfrage gestellt hat.

Wir können keine dieser Vorgehensweisen empfehlen!

#2 ROI

Der Return on Investment (ROI) wird traditionell für große Initiativen verwendet und ist Teil eines formellen Business Case. Er ist eine sehr beliebte Rentabilitätskennzahl und wird verwendet, um zu zeigen, wie gut sich eine Investition bewährt hat.

Der ROI wird als Prozentsatz ausgedrückt und errechnet sich, indem der Nettogewinn einer Investition durch die anfänglichen Kosten oder Ausgaben geteilt wird. 

Vorteile:

ROI kann verwendet werden, um Vergleiche anzustellen und eine Rangfolge der Investitionen in verschiedene Projekte oder Anlagen zu erstellen.

Nachteile:

  • ROI-Indikatoren sind zeitverzögert.
  • Sie basieren auf vorhersehbaren Risiken für gleichbleibende Systeme.
  • Sie lassen sich für eher strategische Arbeiten nur schwer quantifizieren.
#3 – Gewichteter Projektwert

Eine Projektbewertung nach gewichteten Kriterien kann einfach und flexibel auf Projekte angewandt werden und gibt bei der Festlegung von Prioritäten eine Richtung vor. Diese Richtung gibt Aufschluss darüber, warum ein Projekt wichtiger ist als ein anderes, und hilft, die lauten Stimmen einzelner argumentativ zu übertönen.

Die Bewertungskriterien können alles sein, was für Ihre Art von Arbeit sinnvoll ist. Jedem Projekt werden diese Punkte auf der Grundlage der gegebenen “Antwort” zugewiesen, und die Projektpunktzahl ergibt sich aus der Summe aller Antworten. Ein Beispiel:

  • Strategische Ausrichtung: Hoch bekommt 50 Punkte, mittel bekommt 25 Punkte, niedrig bekommt 0
  • Amortisationsdauer: 0-1 Jahr erhält 30 Punkte; 2-4 Jahre erhält 15 Punkte; und 5+ erhält 9 Punkte
  • Risiko bei Untätigkeit: Hohes Risiko erhält 20 Punkte; mittleres erhält 10 Punkte; geringes erhält 0
#4 – CoD und WSJF

Cost of Delay (CoD) und Weighted Shortest Job First (WSJF) ähneln dem Beispiel dem gewichteten Projektwert, nur dass die Gewichtung auf eine ganz bestimmte Weise erfolgt. Dieser Ansatz wurde aus dem Buch Principles of Product Development Flow von Don Reinerten übernommen. Er wurde in der agilen Entwicklung ausgiebig verwendet und ist eine schnelle Methode, um Prioritäten und Aufwand in Einklang zu bringen.

WSJF und CoD sind die einfachsten Methoden zum Vergleich von Merkmalen oder Epics bei der Entscheidung, was als nächstes getan werden sollte.

Die Berechnung lautet WSJF = CoD / Dauer (oder Auftragsgröße)

Was ist CoD? Es handelt sich um die Kosten, die durch die Verzögerung eines Projekts entstehen, d. h. durch verlorene Chancen. 

PI-Planning-CoD
Zur Bewertung sind folgende Faktoren wichtig:
  • Nutzer-Geschäftswert
    Relativer Wert für den Kunden oder das Unternehmen. 1 ist der niedrigste Wert für das Unternehmen, 20 ist der höchste Wert.
  • Zeitliche Dringlichkeit
    Gibt es eine bestimmte Deadline? 1 steht für die geringstmögliche Dringlichkeit und 20 für die höchste Dringlichkeit.
  • Risk Reduction and Opportunity Enablement (RR&OE)
    Hier wird unter anderem die Erschließung von Chancen berücksichtigt, die sich nach der Fertigstellung ergeben könnten. Auch hier vergibt man Punkte von 1-20.
  • Dauer
    Für die Berechnung ist die genaue Dauer nicht Teil der Berechnung (z.B. 5/12 Monate), sondern vielmehr, wie der Aufwand im Vergleich zu anderen Projekten geschätzt wird. Stellen Sie sich das als T-Shirt-Größe vor, wobei 1 XS und 20 Super-Duper XL ist.

Sie können zwar alle Werte von 1 bis 20 vergeben, doch ist es üblicher, für jeden der oben genannten Faktoren einen Fibonacci-Score (1, 2, 3, 5, 8, 13, 20) zu vergeben.

Anmerkungen:

  • WSJF ignoriert bereits investierte Aufwände; es handelt sich also um "verbleibende Zeit".
  • Manche argumentieren, dass die Dauer nicht immer ein geeigneter Faktor ist, da eher hohe Kosten im Fokus stehen. Passen Sie diese Bewertung einfach an Ihren Fall an.
  • Die Werte können sich im Laufe der Zeit ändern, wenn sich die geschäftlichen Bedingungen (zeitliche Dringlichkeit, Marktbedingungen, neu erkannte Risiken usw.) ändern.
  • Wenn Sie sich entscheiden, nur EINE Sache zu quantifizieren, quantifizieren Sie die Cost of Delay (nach Donald G. Reinertsen, Principles of Product Development Flow E3).

Vorteile und Ziele des PI Planning

Johannes Koppenhöfer, CEO von Meisterplan, ist der Meinung, dass PI Planning die einzige Möglichkeit für das Management ist, eine Roadmap zu erhalten, der man vertrauen kann. Vor der PI-Planung konnten Ressourcen nicht verlässlich für mehrere Wochen im Voraus verplant werden. Seit Einführung der PI-Planung fällt es den Leuten viel einfacher, eine verlässliche Roadmap vorherzusagen.

Der Leiter des Produktmanagements bei Meisterplan, Stefan Schneider, sieht den Hauptvorteil von PI Planning in dem schrittweisen Vorgehen, das sicherstellt, dass die Ziele des Unternehmens erreicht werden können. Die PI-Planung ermöglicht es dem Unternehmen, die Dinge inkrementell zu steuern und so den traditionellen jährlichen Planungszyklus flexibler zu gestalten.

Weitere Vorteile der PI-Planung sind:
  • Eine zuverlässigere Bereitstellung der Roadmap.
  • Validierung der Ressourcenkapazität und der Finanzmittel für die priorisierten Ziele.
  • Identifizieren des Portfoliorisikos im nächsten PI durch frühzeitiges Beachten aller Abhängigkeiten.
  • Einigkeit aller Stakeholder durch erhöhte Transparenz der Prioritäten. (Stakeholder können auch Führungskräfte, Kunden und Teammitglieder sein).
  • Herausarbeiten der Anforderungen für die Vorbereitung zukünftiger PIs und klare Verantwortlichkeiten.
  • Kontinuierliche Verbesserung der Teameffizienz, Aufwandsschätzungen und Ressourcenauslastung.

Schlüsselelemente des PI Planning

Bei der PI-Planung geht es darum, die “richtige Arbeit” zu erledigen und gleichzeitig die Kapazitäten und Abhängigkeiten zwischen den Teams zu managen. PI-Planung ist vor allem dann zielführend, wenn folgende Faktoren berücksichtigt werden: Komplexität der Arbeit, Anzahl der Ressourcen und Anzahl der Abhängigkeiten. [Weitere Informationen zu diesem Punkt finden Sie im Abschnitt über die Herausforderungen].

Das Meisterplan-Team verwendet den folgenden „PI-Planungsworkflow“, um den Fortschritt eines jeden Projekts zu verfolgen. In jeder dieser Phasen ist ein Kontrollpunkt vorgesehen, um weitere Arbeiten freizugeben, umzuverteilen oder abzulehnen

PI Planning Elemente
PI Planning Meetings

Das PI Planning erstreckt sich über mehrere Tage mit mehreren Meetings.

Tag 0Tag 1Tag 1Tag 1Tag 2+
PI Planning RetroPI Planning Part 1PI Planning Part 2PI Planning Part 3Follow-up
60-90 Min75 Min45 Min30 Minvariiert
Review des aktuellen Program Inkrements + Verbesserungsvorschläge.Planen der Features/Epics für das kommende Inkrement.Zuständigkeiten für das Erarbeiten von Lösungen verteilen.Zuständigkeiten für das Erarbeiten von Anforderungen verteilen.Plan an Stakeholder kommunizieren.
PI Planning Event Focus

Der zentrale Planungstag (Tag 1) ist sehr teamfokussiert, mit dem Ziel, in kurzer Zeit viel zu erreichen. Man konzentriert sich auf den bevorstehenden PI-Zeitraum, ehe die Anforderungen künftiger PI-Zeiträume untersucht werden.

Teil 1: Die Arbeit fürs kommende PI wird geplant

Alle genehmigten Lösungsvorschläge aus der vorherigen PI-Periode sollten nun verfeinert werden. Verfeinert bedeutet, dass die Arbeit in machbare Aufgaben aufgeteilt ist, Abhängigkeiten dokumentiert sind und jedes Team seinen Aufwand geschätzt hat. Bei diesem Treffen werden die Abhängigkeiten zwischen den Teams überprüft und es wird sichergestellt, dass die Reihenfolge der Arbeiten es ermöglicht, die Ziele dieser PI-Periode zu erreichen.

Teil 2: Der Lösungsvorschlag wird verfeinert

Teil 2 setzt voraus, dass die Lösungsvorschläge analysiert und genehmigt oder abgelehnt worden sind. Alle genehmigten Vorhaben werden in diesem zweiten Meeting Ownern zugewiesen. Nach der PI-Planung ist der Owner dafür verantwortlich, dass die Teams die Arbeit in Tasks und Stories verfeinern, damit sie für die nächste PI bereit sind. (In Agile erfolgt die Verfeinerung in jedem Sprint.) Wichtig ist, dass das gesamte Epic vor dem PI-Planungstag verfeinert und für die Entwicklung bereit ist.

Teil 3: Die Anforderungen werden geprüft

Teil 3 geht davon aus, dass die Anforderungen für künftige PIs immer noch angemessen erscheinen. Die fertiggestellten Anforderungen werden dann während des Meetings einem Verantwortlichen zugewiesen. Nach der PI-Planung ist dieser Owner dafür verantwortlich, Zeit mit Teammitgliedern zu planen, um passende Lösungsansätze zu entwerfen und zu analysieren. Das Team zieht bei Bedarf alternative Lösungen in Betracht, die in kürzerer Zeit und mit geringerem Risiko durchgeführt werden können.

Die einzelnen PI Planning Events im Detail

In diesem Kapitel werfen wir einen Blick auf die verschiedenen Tagesordnungspunkte sowie die relevanten Teilnehmer der einzelnen Events im PI Planning und erörtern, was deren Ziele sind.

Das Vokabular rund ums PI Planning stammt dabei eher aus der agilen Arbeit. Wenn Sie mit einigen der Begriffe nicht vertraut sind oder kein Interesse an einem „Deep-Dive“ haben, springen Sie gerne zum Kapitel „Herausforderungen im PI Planning“. Dort verknüpfen wir unter anderem die agilen Begriffe mit anderen Methoden.

PI-Planung Retrospektive: 1 Tag vor PI-Planung

Zweck: Review und Rückblick auf das aktuelle Programminkrement (PI). Hier wird über Verbesserungspotenziale nachgedacht, um vorhersehbarer, effizienter oder schneller werden können.

TagesordnungTeilnehmer und Verantwortlichkeiten
30 Minuten: Reviewen des Inkrements.

  • Wurden die PI-Ziele erreicht?
  • Wurde das Budget eingehalten?
  • Wurde der Veröffentlichungstermin eingehalten?
  • Wie nah war der tatsächliche Aufwand am geplanten?
  • Gab es Überraschungen, z. B. betroffene Teams oder Abhängigkeiten?
  • Produktmanagement
  • Fachexperten der einzelnen Teams, die sich zu Themen äußern können
90 Minuten: Brainstorming für Verbesserungsideen.

  • Was würde zu besseren Schätzungen führen oder helfen, Meilensteine zu erreichen?
  • Funktionieren die Prozesse gut oder müssen sie angepasst werden?
  • Müssen interne Unterlagen oder Teamvorlagen angepasst werden?
Output: Liste mit Verbesserungen, die zu den Prozessdokumenten, Vorlagen und Best Practices hinzugefügt werden.

PI Planning Teil 1

Alle genehmigten Lösungsvorschläge aus der vorherigen PI-Periode sollten nun verfeinert werden. Verfeinert bedeutet, dass am Ende die Arbeit in machbare Tasks unterteilt ist, Abhängigkeiten dokumentiert sind und jedes Team seine Aufwände geschätzt hat.

Bei diesem Treffen werden die Abhängigkeiten zwischen den Teams überprüft und es wird sichergestellt, dass die Reihenfolge der Arbeiten es ermöglicht, die Ziele der PI-Periode zu erreichen.

Zweck: Planung der Abfolge von Features/Epics für die kommende PI-Periode.

Input:

  • Priorisierte Liste der Lösungsvorschläge mit Angabe des Ziels, zu dem sie beitragen.
  • Alle Abhängigkeiten sind bekannt und für die taktische Planung transparent.
TagesordnungTeilnehmer und Verantwortlichkeiten
  • Festlegen, welche Arbeiten/Lösungen in der kommenden PI-Periode mit Blick auf die Kapazitäten der Teams, der Abhängigkeiten zwischen den Teams und der Prioritäten machbar sind.
  • Abfolge der Aufgaben, wenn mehrere Teams beteiligt sind.
  • Identifizieren von Abhängigkeiten zwischen Teams für die Sprintplanung.
  • Wählen der Ziele für die PI-Periode, sowie der Lösungsvorschläge, die erarbeitet werden sollen unter Ausschluss aller Themen, die nicht machbar sind.
  • Feststellen, ob der Plan realistisch ist und Festhalten des erwarteten Aufwands.
75 Min
  • Feststellen, ob der Plan realistisch ist und Festhalten des erwarteten Aufwands.
  • CPO/Moderator
Output:

  • Ein realistischer, aber ehrgeiziger Umsetzungsplan für alle beteiligten Teams für die nächsten 6 Wochen.
  • Ein Verständnis aller Teams für die Abhängigkeiten sowie eine festgelegte Reihenfolge der zu verrichtenden Arbeiten.
  • Ziele für das kommende Inkrement, die vollständig erreicht werden können.
PI Planning Meilensteine Abhängigkeiten

Meisterplan’s Beispiel für die Darstellung des Projektzeitplans und der Abhängigkeiten.

PI Planning Teil 2

Teil 2 setzt voraus, dass die Lösungsvorschläge analysiert und genehmigt oder abgelehnt worden sind. Alle genehmigten Vorhaben werden in diesem zweiten Meeting Ownern zugewiesen. Nach der PI-Planung ist der Owner dafür verantwortlich, dass die Teams die Arbeit in Tasks und Stories verfeinern, damit sie für die nächste PI bereit sind.

(In Agile erfolgt die Verfeinerung in jedem Sprint.) Wichtig ist, dass das gesamte Epic vor dem PI-Planungstag verfeinert und für die Entwicklung bereit ist.

Zweck: Auswahl der (bereits genehmigten) Lösungsvorschläge, die verfeinert werden müssen.

Input:

  • Priorisierte Liste der fertiggestellten und genehmigten Lösungsvorschläge (der CPO genehmigt und priorisiert)
TagesordnungTeilnehmer und Verantwortlichkeiten
  • Präsentation der analysierten und bereits priorisierten Lösungsvorschläge.
  • Auswahl der Lösungsvorschläge, die in das folgende PI passen und Zuweisung eines Owners.
  • Abgleich mit den betroffenen Product Ownern über die Machbarkeit des Plans.
  • Leiter Produktmanagement (CPO)
  • Owner der Lösungsvorschläge
  • Product Owners
  • Produktmanagement
  • Chief Scrum Master
  • UX
45 Min
Output:

  • Owner für die Umsetzung der Lösungsvorschläge (d.h. Feature/Epic) sind zugewiesen.
  • Owner stellen sicher, dass jedes Team den Plan vor der nächsten PI-Periode verfeinert.

PI Planning Teil 3

Teil 3 geht davon aus, dass die Anforderungen für künftige PIs immer noch angemessen erscheinen. Die fertiggestellten Anforderungen werden dann während des Meetings einem Verantwortlichen zugewiesen.

Nach der PI-Planung ist dieser Owner dafür verantwortlich, Zeit mit Teammitgliedern zu planen, um passende Lösungsansätze zu entwerfen und zu analysieren. Das Team zieht bei Bedarf alternative Lösungen in Betracht, die in kürzerer Zeit und mit geringerem Risiko durchgeführt werden können.

Zweck: Festlegen der Problemstellungen/Anforderungen, die für die Ausarbeitung neuer Lösungsvorschläge bereit sind.

Input:

  • Priorisierte Liste der fertiggestellten und genehmigten Problemstellungen (CPO genehmigt und priorisiert).
TagesordnungTeilnehmer und Verantwortlichkeiten
  • Präsentation der wichtigsten Problemstellungen
  • Überprüfen der Problemstellungen hinsichtlich ihrer Klarheit und Vollständigkeit
  • Leiter Produktmanagement (CPO)
  • Owner des „Problems“
  • Product Owners
  • Produktmanagement
  • Chief Scrum Master
  • UX
30 Min
Output:

  • Jedem Problem ist ein Owner zugewiesen.
  • Zur Lösung des Problems werden entsprechend Ressourcen verplant.
  • Die Problem-Owner vereinbaren einen Termin mit dem Lösungsteam, um die bestmögliche Lösung zu entwickeln.
Beispielhafter Workflow des Meisterplan-Teams:
PI Planning Board View Workflow
Schritt 1

Review der zu lösenden Probleme und Festlegen der groben Problemstellungen / Anforderungen. Ziel ist es nicht, eine Lösung anzubieten, sondern die Anforderungen festzulegen, die eine Lösung zu erfüllen hat. Hier empfiehlt es sich, eine “Vorlage” für das Team zu erstellen, die allen Projektverantwortlichen hilft, die wichtigsten Anforderungen und deren Aspekte kompakt festzuhalten.

Schritt 2

Analysieren und Entwerfen einer Lösung, die den formulierten Anforderungen gerecht wird. Auch hier lohnt es sich, mit Vorlagen zu arbeiten, die das Erfassen der wichtigsten Informationen vereinfacht.

Schritt 3

Refinement of Details (Ausarbeiten der Lösungsdetails)

  • 1-6 Wochen vor Beginn der PI-Periode müssen die Lösungsvorschläge in konkrete Aufgaben aufgebrochen werden. Dabei handelt es sich im Grunde um Tasks, auch wenn sie im agilen Kontext eher Stories, Tasks und Improvements genannt werden.
  • Das gesamte Feature/Epic wird in iterationsgroße Komponenten (d.h. User Stories oder Tasks) aufgeteilt. Das Aufteilen der Arbeit sollte für jedes Team möglich sein, das für das Feature/Epic benötigt wird, einschließlich der Enabler-Teams . Enabler-Teams sind die Teams, die einen Beitrag zu dem Feature leisten müssen, wie Infrastruktur, Sicherheit, Datenbanken usw.
  • Das Team schätzt den Aufwand der Stories/Tasks/Improvements.
Schritt 4

Ready for Development (Bereit für die Entwicklung)

  • Wenn alle Teams mit dem Aufteilen der Arbeit und der Schätzung der Aufwände fertig sind, werden die “verfeinerten” Schätzungen mit den zuvor angestellten groben Schätzungen verglichen.
  • Hier wird geprüft, ob das Projekt für eine zukünftige PI-Periode genehmigt oder abgelehnt werden sollte. Im Falle einer Genehmigung wird der Status auf “Bereit” gesetzt.
Maßnahmen nach der PI-Planung
MaßnahmeTeilnehmer und VerantwortlichkeitenOutput
Abschließende Prüfung mit den anderen Stakeholdern, die zur Unterstützung der Umsetzung erforderlich sind.ProduktmanagementAktualisierte Confluence Seiten
Veröffentlichen der PI-Planung sowie der Deliverables für die anderen Stakeholder.ProduktmanagementAktualisiertes Kanban Board

Typische Fehler und Herausforderungen im PI Planning

Herausforderung

Nicht dieselbe Sprache sprechen

Wenn Unternehmen mehrere unterschiedliche Methoden in ihren Teams verwenden, d. h. einige Teams arbeiten nach einem Wasserfallmodell, während andere Teams mit Agile/Scrum arbeiten, ist jedes Team daran gewöhnt, seine “Sprache” zu sprechen.

Wenn sich diese Teams in derselben Besprechung oder im selben Raum befinden, ist es wichtig, eine gemeinsame Kommunikations-Grundlage zu haben, damit es nicht zu Verwirrungen kommt. Um dem vorzubeugen, empfehlen wir, dass Sie allen Teilnehmern beibringen, die gleiche “Sprache” zu sprechen, bevor sich die Projektteams treffen. Am besten teilen Sie dieses Wissen immer schon dann, wenn ein neues Teammitglied ge-onboarded wird.

So könnte das aussehen:

PI Planning Vokabular
Herausforderung

Nicht wissen, wer an Meetings teilnehmen soll (wenn mehrere Methoden zur Anwendung kommen).

Ähnlich wie bei den sprachlichen Unklarheiten, kann es sein, dass nicht immer klar ist, wen man zu gewissen Meetings einladen soll. Stellen Sie sich einfach die Frage, welches Fachwissen oder welche “Rolle” Sie für die anstehenden Entscheidungen im Meeting brauchen.

Erforderliches FachwissenTypische Rollen bei der WasserfallmethodeTypische Scrum-Rollen
Experte für Strategie und VisionDirektoren, Manager von Themen/BereichenLeiter Produktmanagement (CPO)
Koordinations-Verantwortlicher

  • Besteht Einigkeit und sind wir „on track“?
  • Gibt es Hürden?
  • Haben wir alles, was wir brauchen?
Programm Manager, ProjektleiterProduktmanagement, Chief Scrum Master
Definitions-Verantwortlicher

  • Warum tun wir das?
  • Für wen tun wir das?
  • Was braucht die Zielgruppe?
Projekt Sponsoren, Business Program Owners, Stellvertretende Geschäftsinhaber, GeschäftsanalystenProduct Owners, Epic Owner
Umsetzungs-Verantwortlicher

  • Wie können wir das umsetzen?
  • Wohin soll es gehen?
  • Wann kann das Projekt durchgeführt werden?
Systemarchitekten, Lösungs-Architekten, ProgrammarchitektenLösungs-Architekten, Technischer Koordinator

Jede Expertengruppe innerhalb des Projekts sollte sich mit den wichtigsten Stakeholdern außerhalb des Kernprojektteams absprechen. Diese Stakeholder sind wichtig für den Erfolg des Projekts, nehmen aber wahrscheinlich nicht an den Sitzungen des Projektteams teil.

Experte, der an Meetings teilnimmt …… muss folgende Themen an wichtige Stakeholder kommunizieren
Koordinations-RolleCompliance, Release Management, Audit, Change Management
Definitions-RolleUser Research, Agent Review Boards, Regional User Groups, Customer Success Managers, Legal
Umsetzungs-RolleEnterprise Architecture, Data Governance, Security, Solution Design, User Experience Design
Herausforderung

Nicht wissen, wie PI Planning für mehrere Produkte/Wertströme funktioniert.

Viele Unternehmen bieten unterschiedliche Produkte oder Dienstleistungen an. Eine häufige Herausforderung besteht darin, zu verstehen, wann PI Planning sinnvoll ist und wann nicht.

Wenn Sie unabhängig voneinander geplante Produkte oder unabhängig voneinander geplante Wertströme haben, sollte jeder sein eigenes PI Planning haben. Zumindest unter der Voraussetzung, dass das Produkt oder der Wertstrom ein bestimmtes Maß an Komplexität, eine bestimmte Anzahl der Ressourcen/Teams und eine bestimmte Anzahl an Abhängigkeiten überschreitet.

Beispiele:

  • Wenn es Teams gibt, die an mehreren Produkten oder Wertströme beteiligt sind, wie z. B. Enabling-Teams, ist es wahrscheinlich, dass die "Koordinationsrolle" an mehreren PI-Planungsveranstaltungen teilnimmt. Wenn das Enabling Team aber nur kleine Rolle spielt, übernimmt der Koordinator des Programms/Produkts/Wertstroms auch die Rolle des Koordinators außerhalb des PI-Meetings.
  • Der Koordinator für die Programm- und/oder Teamebene würde, falls nicht bereits vertreten, an der Wertstrom-PI-Veranstaltung teilnehmen. In diesem Fall konzentriert sich das Wertstrom-PI-Event in erster Linie auf den Fortschritt mit Blick auf die Ziele/Ergebnisse und stellt sicher, dass programmübergreifende Abhängigkeiten überprüft werden.
  • Empfohlen wird ein Global PI Planning Event. Ein globales Portfolio-Meeting, bei dem alle Produkte/Wertströme gemeinsam betrachtet werden. Bei dieser globalen Portfoliobesprechung ist es das wichtigste Transparenz über den Fortschritt bei den Produkten/Wertschöpfungsströmen zu schaffen. Hier reicht es, wenn die Koordinatoren der verschiedenen Ebenen zugegen sind.
Das könnte in etwa so aussehen:
PI Planning Wertströme
Typischer Fehler

PI-Planungszeiträume liegen zu nah oder zu weit auseinander.

Normalerweise planen Wasserfall-Teams für zwei- bis viermonatige Meilensteine. Scrum-Teams verpflichten sich in der Regel nur zu zwei- bis vierwöchigen Planungszyklen und XP-Teams zu zwei Wochen oder weniger.

Diese Unterschiede führen zu Problemen, da die unterschiedlichen Teams Schwierigkeiten haben, ad hoc Änderungen an der eigenen Planung vorzunehmen, wenn sich die Prioritäten der anderen Teams ändern. Orientieren Sie sich beim PI Planning also immer an längsten Planungshorizont.

  • Wenn Wasserfallteams beteiligt sind, kann die PI-Planung 8-16 Wochen umfassen.
  • Wenn nur Scrum-Teams beteiligt sind, hängt es davon ab, wie lange die Fertigstellung eines Epics im Durchschnitt dauert. Brauchen Ihre Epics eher 6 oder eher 12 Wochen?

Entkoppeln Sie die Planung also von der Frequenz, in der Teams abliefern können. So kann jedes Team weiterhin nach im eigenen Rhythmus arbeiten, müssen aber unabhängig davon vorläufige Pläne bereitstellen, um die Planung der kommenden PI-Perioden zu ermöglichen.

Typischer Fehler

PI-Planung ohne Retrospektive, um Zeit zu sparen

Die Einführung von PI Planning bedeutet Veränderung, und das bringt immer Fragen und oft auch Unsicherheit mit sich. Die am Prozess beteiligten Personen spüren, wo der Schuh drückt. Eine Retrospektive gibt diesen Bedenken eine Plattform und hilft dabei, relevante Fragen zu diskutieren und anzugehen. Wird das versäumt, wird es im Laufe der Zeit schwierig, bestehende Schwierigkeiten anzugehen, selbst wenn der Prozess eigentlich optimal aufgesetzt ist.

Typischer Fehler

Zu viel Zeit für die Vorbereitung

Bei der Wasserfall-Mentalität wird den Anforderungen/Problemstellungen oft viel Zeit gewidmet, bevor sie in die Umsetzung gehen. Das verzögert dann auch die Arbeit aller anderen. Es ist zwar wichtig, Dinge durchzuplanen, wenn man sich aber in den Details verliert, stagniert der gesamte Backlog.

Überlegen Sie stattdessen, wie Sie genügend Features / Epics auf schlanke Art und Weise für das nächste PI vorbereiten können. Überlassen Sie es dann den Teams, die nötigen Tasks zu identifizieren und weiterzuentwickeln.

Typischer Fehler

„Einfaches“ Planen auf Grundlage einer 12-Monats-Roadmap

Das grobe Schätzen von Aufwänden ist in der Tat schwierig! Noch schwieriger wird es, wenn sich agile Teams querstellen: “Warum in aller Welt müssen wir 6-12 Monate im Voraus schätzen? Das ist einfach nicht agil!”

Helfen Sie Ihren Teams, die Vorteile der Portfolioplanung nachvollziehen zu können. Argumente, die wir in diesem Zusammenhang oft hören sind:

  • Gute Leute einzustellen, braucht Zeit. Oft muss man rechtfertigen, wofür man das zusätzliche Personal braucht. Eine ordentliche Kapazitätsplanung inklusive der Auswertung entstandener Engpässe ist daher von zentraler Bedeutung, um das Anheuern neuer Leute zu rechtfertigen. Und dafür braucht es nun mal die entsprechenden Schätzungen. Selbst wenn gar kein Budget für neues Personal bereitsteht, so helfen die Informationen zumindest, realistische Erwartungen beim Management hinsichtlich des schaffbaren Pensums zu wecken.
  • Der Rollout neuer Features für den Kunden wirkt sich unmittelbar auf dessen Nutzererfahrung aus. Wenn die Features zu vieler Teams gleichzeitig live gehen, kann das Kunden überwältigen. Das wiederum kann zur Folge haben, dass keines der Features richtig genutzt wird und alle Projekte ihr Ziel verfehlen. Sinn und Zweck guten Portfolio Managements ist es hier, genau diese Szenarien bei der Planung zu berücksichtigen.
  • Die Unternehmensziele können nur dann richtig erreicht werden, wenn alle Zahnräder ineinandergreifen. Wenn nicht klar ist, was nach Abschluss eines Projekts passieren soll, können Teams wie Marketing, Vertrieb, Betrieb und/oder Support nicht dazu beitragen, die vom Unternehmen erwarteten Ergebnisse zu erreichen.

Best Practices im PI Planning

Agile im Unternehmen skalieren:

Wenn Teams anfangen, das Scrum-Framework zu verwenden, ist Best Practice, die Sprintplanung aller Teams in derselben Woche durchzuführen. Dabei ist es nicht so wichtig, ob der jeweilige Sprintzyklus 2 oder 4 Wochen lang ist.

Wichtig ist nur, dass die Sprint-Plannings direkt nach einer PI-Planungssitzung stattfinden können. Das PI Planning dient hier dazu, die Sprintplanung der einzelnen Teams aufeinander abzustimmen.

Meilensteine in einem Programm/Portfolio Epic:

Meilensteine gehören zu den wichtigsten Indikatoren für den Projektfortschritt sowie dessen Erfolg oder Misserfolg. Bei agilen Teams sind Meilensteine ein integraler Bestandteil, um gewisse Ergebnisse bis zum Sprintende sicherzustellen.

Aber auch für Wasserfallteams ist es empfehlenswert, mindestens alle 8 Wochen Meilensteine zu setzen. Diese Meilensteine können ein konkretes Endprodukt sein oder zumindest einen Touchpoint, um den aktuellen Stand zu präsentieren. Unterm Strich funktioniert agiles Arbeiten nämlich nicht, wenn man nach 6 Monaten ohne Zwischenstand feststellt, dass die Arbeit für die Katz war.

Roadmap-Kommunikation:

Die PI-Planung ist ein möglicher Weg, um mehr auf Basis eines gemeinsamen Verständnisses mehr Vertrauen in die eigene Roadmap zu wecken. Für gewöhnlich kommen bei den Stakeholdern Fragen wie diese auf:

  • Ist das Anfangs- und Enddatum eines Projekts fix terminiert oder nur grob eingeplant? Mit anderen Worten: Kann man sich auf das Enddatum der Arbeit verlassen? Im Rahmen des agilen PI Planning, werden nur Zusagen für das kommende PI gemacht. Alle anderen Zielsetzungen bleiben zunächst flexibel.
  • Ist das Projekt gescheitert, wenn Aufgaben neu verteilt, verschoben oder gänzlich eingestellt werden? Für die Stakeholder muss klar sein, dass solche Ereignisse Teil des Prozesses sind. Denn gute Führung heißt auch, mal „Nein“ oder „Nicht jetzt“ sagen zu können. Dafür brauchen die Verantwortlichen aber eine entsprechende Entscheidungsgrundlage. Mit Hilfe des PI Planning ergeben sich genügend Checkpoints, um mit der angemessenen Sorgfalt einlenken zu können.

Fazit

Puh, Sie haben es fast geschafft.

PI Planning hat Vorteile für alle Arbeitsweisen. Es erzwingt Kontrollpunkte, die sicherstellen, dass die richtige Arbeit priorisiert wird, während die Ressourcennutzung optimiert und die Abhängigkeiten (Team- oder Arbeitsabhängigkeiten) berücksichtigt werden. Das Ergebnis ist eine besser vorhersehbare Roadmap, der alle Beteiligten vertrauen können.

Wenn Sie PI Planning einführen wollen, brauchen Sie einerseits Leute, die die Prozesse immer wieder neu denken und die Struktur laufende verbessern. Andererseits benötigen Sie einflussreiche Führungskräfte, die die Teams motivieren. Im besten Fall haben Sie jemanden, den Sie zu Rate ziehen können und der bereits Erfahrung mit dem PI Planning hat.

Und denken Sie immer dran: Erst gehen, dann laufen, dann rennen!

Als nächstes lesen

Akku fast leer.