Schlagwort-Archive: SAFe

The hidden power of SAFe PI Objectives

Establish the feedback loop with PI Objectives

In the Scaled Agile Framework (SAFe) the „PI Objectives“ are a summary of what an Agile Team (Team PI Objectives) and what all the Teams together as the Agile Release Train (Program PI Objectives) intend to achieve in the next Program Increment (same is true for the further aggregation of PI Objectives for the Solution Train).

The PI Objectives are a key element to create alignment on what the really important stuff is we need to focus on. They help to create a shared understanding of what Business Value means to the business and by which outcomes it can be realized for the ART in the Program Increment.

They are written and agreed on in the PI Planning (including the assignment of „Business Value“) and tracked during PI Execution. They finally close the feedback loop for the PI at the System Demo when planned and delivered outcomes are compared and we get a better understanding of the level of predictability we have reached. 

They are of such high importance that they are so-called „first-class citizens“ and are prominently displayed on the SAFe Big Picture.

PI Objectives –
First Class Citizen in the Scaled Agile Framework

PI Objectives provide a way to work goal-oriented and check understanding, however often they are not used at all. Why is that and what is missing when you don’t use PI Objectives? 

Scrum Sprint Goals

Very early in the history of Scrum, the concept of a team having clear goals and trying everything to meet these goals was a key idea the inventors and early adopters of Scrum emphasized again and again. Still, the practice of defining Sprint Goals is still being ignored by a lot of Scrum teams while the importance of defining and following goals is more and more emphasized in the recent iterations of the Scrum Guide where it is stated that the Sprint Backlog includes selected backlog items plus a plan to deliver the product increment and realize the Sprint Goal. The backlog items are just there to make the work visible required to realize the Sprint Goal. While most Scrum Teams learn that with the Sprint Planning the Sprint Backlog gets logged-in, this is not what is stated in the Scrum Guide ( In the guide, it is clearly stated that the Sprint Backlog may emerge during the Sprint as the Team learns more about how to achieve the Sprint Goals.

To put it in a clear way: It’s meeting the Sprint Goals that count not mechanically delivering the set of backlog items (often „User Stories“) with their Acceptance Criteria and DOD!

„A sprint goal summarises the desired outcome of an iteration. It provides a shared objective, and it states why it’s worthwhile undertaking the sprint.“

Many SAFe implementations underuse PI Objectives

In Scrum, the Sprint Goals define an important focus point where all value delivered, progress and all effort spent is measured against and a way which is used to create alignment in the Team and between the Team and all the stakeholders. In SAFe the concept of Iteration Goals has the same purpose for the Team and the Iteration.

Take this concept and scale it up and you will end up with something like PI Objectives as described in SAFe. 

Team PI Objectives, Iteration Goals and Stories/Features – all related

While the problem of not working „goal oriented“ is present in most Scrum implementation the same is true for many Scaled Agile Framework (SAFe) implementations. In most Agile Release Trains (ARTs) the PI Objectives are constantly underused and often there is a strong resistance to use them at all as „we do have the Features and Stories we need to deliver“.

Looking at the official training material on this topic it becomes clear that there is not enough guidance on how to write and use PI Objectives in a productive, value-generating manner. While it is clearly communicated that in the standard PI Objectives belong to the expected results of a PI Planning event the examples displayed in the official SAFe 4.5 training material may even point you in the wrong direction on how to do it (IMHO got much better in the SAFe 4.6 material).

Some additional guidance for PI Objectives

Beside the guidance article found on the official SAFe site there are some additional articles and presentations available describing the importance of PI Objectives in a different way and giving better guidance on writing and using them.

The Role of PI Objectives

In this advanced topic guidance article for SAFe Fellow Eric Willeke summarizes the role of PI Objectives. We will refer to this article later in more detail…

The Synergistic Nature of PI Objectives

Charlene Cuenca give a good overview of the role and importance of PI Objectives in this presentation she gave at the Global SAFe Summit 2018 in Washington.

Measuring Business Value

This presentation (also Global SAFe Summit 2018) by Drew Jemilo & Jennifer Fawcett contains an explanation of how to write better PI Objectives and how to assign Business Value in the PI Planning. The slides explaining the concept and application of PI Objectives are very valuable and many readers like this approach more than the SAFe 4.5 training material. The talk is available on video.

What are good PI Objectives?

PI Objectives are one of the results of a PI Planning event in which we were able to agree on some shared goals (outcomes) that the Teams / the full ART should deliver in the next Program Increment. Teams in the ART commit to doing everything in their power to deliver their Team PI Objectives or make it immediate transparent when a PI Objective is at risk.

The objectives are written in a common language and understandable by the other Teams, the Stakeholders and Business Owners. They might be connected to a specific milestone like a tradeshow, maybe an aggregation of Features or a combination of different elements.

Most important is that benefits and value are clearly understandable and connected to the overall goal and the strategy of the organization and the ART which means a PI Objective may reflect directly business goals or might emphasize important enablers (gaining information, investing into technology).
Therefore the PI Objectives are describing what value is going to be produced by the Agile Release Train and as such supporting the primary principle of the Agile Manifesto:

„Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.“

PI Objectives do not need to map directly to Features in the Backlog but they sometimes might be a very important Feature or an aggregation of Features where the aggregation as such makes sense from a business perspective – which is not „Deliver Feature 1-3“ but something like „Initial autonomous parking capability in standard parking lots type 1“ (which probably includes functionality specified in Features 1-3).

By agreeing on the objectives of the whole ART including its Stakeholders are aligned to a shared mission, everybody knows what are the goals for the next Program Increment. This helps to decentralize decision-making and usually improves the flow of value.

PI Objectives help not to get lost in the details.

What benefits will you get if you use PI Objectives correctly?

Using PI Objectives helps to establish a culture of goal orientation instead of task orientation and with that focus on outcome instead of output. Used in the right way, a very valuable feedback loop with a lot of communication and collaboration between Business and Dev is created which creates high transparency and full alignment. This is important for building trust between Business and Dev and created real ownership & commitment on both sides.

Good PI Objectives provide the following benefits:

Benefits of PI Objectives

PI Objectives establish a critical feedback loop & foster collaboration between Development and Business

In his article „The role of PI Objectives“ SAFe Fellow Eric Willeke explains the following aspects of PI Objectives in more detail:

  • Validate understanding of the intent 
  • Focus alignment on outcomes rather than process 
  • Summarize data into meaningful and steerable information

Let’s have a closer look on how the feedback loop is established between Business and Development:

  1. Business and Product Management state at the beginning of the PI Planning the enterprise strategy, enterprise context, the business goals and the product vision for the next PI. While there should be an ongoing communication about these aspects during the PI Execution, everybody in the ART gets an updated clear understanding what the mission for the next PI is.
  2. The Teams take the prepared and discussed Features related to these business and technical goals and start figuring out a way how to deliver a maximum of value to their enterprise. They do this by breaking Features down to smaller chunks of work, typically User Stories, which they check for dependencies and other constraints. Then these smaller chunks of work are planned to be developed in a specific Iteration where enough capacity is available. While this might change during PI Execution it’s their base plan on how to implement work items that contribute to delivering Business Value to their enterprise. They finally summarize all the goals they want to achieve in (Team) PI Objectives and Stretch Objectives.
  3. Later in the PI Planning the Teams explain their plan using the PI Objectives and the Business Owners understand what Development will do and rates that in „Business Attractiveness“ (Business Value). This is typically a highly collaborative process where the teams explain and refine the PI Objectives and the Business Owners understand the constraints and alternatives identified by the team. Development gets better in understanding which elements are delivering value, Business understands better what is possible with the given constraints (capacity, expertise, ..). This is a core element in bridging the gap between Business and Dev and for building trust. This is part of the feedback loop in the PI Planning and critical for the collaboration and alignment between Business and Development in planning and executing the PI.
  4. An agreement is found how maximum Business Value can be delivered with the given constraints. The PI Objectives then become the business summaries of what outcomes each team intends to realize in the upcoming PI.

With all this it become clear that working with PI Objectives is a key element in SAFe as it creates transparency and alignment in a highly collaborative way. The whole organization focuses on outcomes (create business value) instead of output (deliver specific Stories / Features in a specific Iteration).

Note: This text was drafted quite some time ago and the idea was to create a series of articles about the PI Objectives. I never had the time/focus to do that but while it might not be perfectly written I see some value in publishing it now. Feel free to comment.

SAFe mal ganz einfach

Das Scaled Agile Framework (SAFe) wird häufig gleichgesetzt mit dem Big Picture mit seinen vielen Elementen. Was sind aber davon die wichtigsten Elemente?

Hierfür wurde das Essential SAFe definiert, jetzt mit dem SAFe 4.5 Launch die  Konfiguration „ESSENTIAL SAFe“.

Mir sind die Themen rund um Werte und Prinzipien in SAFe wichtig, da diese die Grundlage für erfolgreiche Implementierungen darstellen. Was aber, wenn man sich auf die wichtigsten „mechanischen“ Elemente beschränken möchte?

Hier ein Video mit dem Versuch einer Erklärung (noch in SAFe 4.0 Nomenklatur).

Zweiter Teil dreht sich um eine SAFe Konfiguration die wir von KEGON zusammen mit Seibert-Media entwickelt haben.


Impediment as cow on the track

Unterhaltsame Session von Sarah Scott (Northwestern Mutual) auf dem diesjährigen SAFe Summit in dem sie ihre SAFe Implementierung vorstellt.

Besonders die Visualisierung von Impediments in Form von Kühen hat zum Schmunzeln angeregt, obwohl dahinter eine richtige Geschichte steckt:

Und dazu passend das „Cow Board“ mit dem visualisiert wird wie der Status der verschiedenen Agile Release Trains (ART) ist:

  • Ready for SAFe
  • Vorbereitung
  • erstes PI Planning
  • Weitere Betreuung / Professionalisierung
  • weitere PIPs
  • Reduktion des Coachings..


SAFe Cow Board
SAFe Cow Board

Natürlich inklusive Cow Impediments :-)



Eine Einführung in das Scaled Agile Framework (SAFe) und das Problem dabei genügend Luft zu bekommen…

Beginnt man sich mit dem Scaled Agile Framework (SAFe) zu beschäftigen und sucht eine Kurzeinführung SAFe, dann fällt der Blick zuerst auf das sogenannte „Big Picture“ welches die Startseite von dominiert.

Hat man bisher bereits Erfahrungen mit agilen Teams gesammelt und ist stets dem Agilen Prinzip

Simplicity–the art of maximizing the amount of work not done–is essential. (

gefolgt, dann kommt es häufig zu einer Gegenreaktion im Sinne von „DAS kann doch nicht agil sein!“.

Es gibt nun diverse kurze Einführungen in SAFe die hauptsächliche auf die Elemente, Struktur und Abläufe fokussieren, wie sie im Big Picture abgebildet sind.Sehr schön ist beispielsweise das SAFe 4-0 in 5 Minuten Video von Inbar Oren:

Diese Darstellungen sind sehr nützlich, um einige wichtige Praktiken und Mechanismen zu verstehen. SAFe alleine auf die konkreten Praktiken zu reduzieren ist allerdings weniger hilfreich, weil diese recht konkret sind und sicherlich nicht in jedem Kontext passend.

Mein Ansatz in Trainings zum Scaled Agile Framework ist deshalb, relativ viel Zeit mit Themen wie

zu verbringen. Gerne wedel ich dabei auch mit den Büchern von Donald Reinertsen (Flow) und Kotter (Change Management) herum.

Dies sind Grundlagen, die sicherlich nicht direkt die konkreten und aktuellen Probleme der Teilnehmer adressieren. Sie müssen jedoch verstanden sein, damit SAFe im eigenen Kontext richtig interpretiert und adaptiert werden kann.

Vor ein paar Tagen durfte ich nun sehr kurzfristig für meinen Kollegen Thorsten Janning, dem ersten deutschen SPCT, kurzfristig einspringen, um eine Kurzeinführung SAFe beim Agile Roundtable Rhein-Main zu geben.

Was tun, wenn keine Zeit für eine intensive Vorbereitung da ist? Klar, man nimmt sich eine der Standardpräsentationen und eine gehörige Portion Improvisation dazu. Meine Wahl fiel auf die „SAFe in 8 Pictures“ Präsentation, wie sie über die Seite verfügbar ist (



Schön, ich habe ca. 45 Minuten Zeit und kann einen komprimierten Überblick über SAFe geben. Da Prinzipien, Werte und das House of Lean nicht Teil dieser Präsentation ist, kommen diese Dinge auf ein Flip und ich erkläre (leider nur) kurz etwas dazu.


Es gab nur einen kleinen Schönheitsfehler bei diesem Plan – statt der erhofften 45 Minuten gabs für alles zusammen nur einen Slot von 20 Minuten.

Sehr schön, vor allem wenn man bedenkt, dass ein beliebtes Feedback für die zweitägigen Trainings ist, dass diese mindestens drei Tage lang dauern sollten :-)

Egal, nicht erschrecken lassen sondern Gas geben und noch ein bisschen Humor einstreuen, u.a. die Frage wer denn diesen Satz lesen kann:


Eine kurze Summar im Sinne von „Hey, da gibts auch noch etwas reduziertes“ mit dem Hinweis auf das Essential SAFe gabs am Schluss auch noch …

Für mich waren die 20 Minuten (die ich recht gut einhalten konnte) ein spannender, schneller Sprint mit der zentralen Frage: „Hole ich Luft oder geht noch ein weiterer Satz?“. Die Antwort war zumindest zwei mal ein lautes Luftholen :-). Na, da steckt doch noch ein bisschen Energie in den alten Knochen …

Da ich früher gehen musste, konnte ich die versprochenen Zertifikate „I survived the SAFe speed run“ doch nicht an die Teilnehmer verteilen – vielleicht das nächste Mal :-).


Weiteres Video zur SAFe Implementierung bei LEGO

In dem Video „Is SAFe Evil?“ (letzter Beitrag) wurde bereits darauf eingegangen, wie das Scaled Agile Framework als Startpunkt für die „Scaled Agile Implementierung“ bei LEGO® genutzt wurde.

Auf der Lean Kanban Europe 2015 gab es nun einen weiteren Vortrag hierzu.

Das Video ist via vimeo verfügbar:

Learnings from SAFe @ Lego – Mattias Skarin & Eik Thyrsted Brandsgård at LKCE15 from Lean Kanban Central Europe on Vimeo.

Wichtige Punkte:

  • Impressionen zum Release Planning Event (16:00) – hier kann man richtig Spaß haben!
  • Was machen wir eigentlich mit SAFe? Das gleiche wie im Kindergarten (17:50) :-)
  • Schöne Visualisierungen, welche Prinzipien hinter SAFe stecken. Es ist eben nicht das „Big Picture“ sondern diese Prinzipien, die die Basis für eine Scaled Agile Implementierung sind.
  • Generell „play it unsafe“ – bewusst Dinge anders tun als in SAFe beschrieben. Hier heißt es keine Angst vor Experimenten! Sich dumpf an die Vorgaben zu halten ist langfristig nicht sinnvoll (als Startpunkt aber ok).
  • Algorithmus, um zu entscheiden was beibehalten und was wegfallen sollte:
    • die Elemente die Energie erzeugen – behalten
    • die Elemente die dazu führen, dass alle einschlafen – entfernen

Das Video enthält viele Ideen, wie das SAFe Release Planning Event adaptiert werden kann. Die eine oder andere Idee eignet sich dafür, sie direkt in der eigenen Scaled Agile Implementierung auszuprobieren.

Die Slides zu dem Vortrag sind via einem Blog Artikel bei Crisp verfügbar.

Ich halte die Impressionen von der SAFe Implementierung bei LEGO für sehr erfrischend. Hier in Deutschland neigen wir – gerade bei großen Organisationen – dazu, uns zu ernst zu nehmen und in Details zu verlieren. Es geht nicht darum, stumpf Backlogs abzuarbeiten, sondern wir sollten auch gemeinsam Spaß haben und eine Vision teilen.

Zudem ist es wichtig zu verstehen, dass SAFe lediglich der Startpunkt für die eigene Scaled Agile Implementierung („Land of Awesome“) ist. Dies versuche ich bei meinen „SAFe“ Implementierungsprojekten stets zu vermitteln. Je größer die Unternehmen, umso weiter jedoch der Weg zur Erkenntnis, dass sich Innovationen nicht standardisieren lassen.