Duration : 1 Day



Scaled Agile Framework (SAFe)


Scaled Agile Framework – SAFe, is a knowledge base of best practices that allows project teams to apply
lean-agile practices at the Enterprise level. It provides a simple, lightweight experience for the software
development teams. SAFe is used when teams are interested to implement an agile approach consistently across
larger, multi-team programs and portfolios. Typically, it answers the question, “How does one scale agile
software development across multiple teams?”


The Agile Release Train, often abbreviated to ART, is SAFe’s core means of value delivery from IT organizations to

end-customers. An ART corresponds to an enterprise program team

where a team of Agile teams (5 – 12 teams) consisting of 50 – 125+ individuals work for a program. Of course,

programs can be larger than this, then one has to think about the program having multiple ARTs.


Setting up an ART


Setting up the ART means, defining the program org structure roles and processes that delivers business value
into production. This also means not only defining key stakeholder positions at program level but also involves
decisions about team composition and the relationships among teams. Another point of emphasis that needs to
be considered while setting up the ART is on building the Program backlog which defines the actual work to be
done among the delivery teams. Put in the plainest terms, it’s a to-do list for the program and it consists of
features (realizations of business benefits) and so-called enablers (supporting work necessary to deliver that
business value, such as architectural constructs).


Program Increment and PI planning


Delivery in the ART centers around the idea of a Program Increment (PI). This is SAFe’s implementation of the
general agile concept of a Potentially Shippable Increment (PSI).


Program increments (PIs) are typically 8 to 12 weeks long and drives the program teams to deliver value at least
once per quarter. Every quarter, team’s plan out that quarter’s worth of work out of the Program backlog, if a
feature doesn’t make it aboard this quarter’s “train,” then it has to catch the next one. Within the program
increment timebox, the individual teams behave a lot like Scrum teams. They’ll execute two-week sprints—four
to six of them, depending on the length of the program increment 8 or 12 weeks.


Program Increment PI Planning is a cadence- based, face-to-face event that serves as the heartbeat of the Agile
Release Train. It is the most important event in Scaled Agile Framework, there’s no way to implement SAFe
without properly implementing the PI Planning process. The primary purpose of PI planning is to gain alignment
between business owners and program teams on a common, committed set of Program and Team Objectives for
the next PI release time-box.


PI Planning Event – We would conduct a simulation of this 2 day event


PI Planning is an event where everyone involved in the Program attends in person if at all possible. It is a
significant event that requires preparation, coordination and communication. Event attendees include Business
owners, Product Management, Agile Teams, System and Solution Architect/Engineering, System Team and other
stakeholders who all must be notified in advance to be well prepared. Product Management owns feature
priorities of the Program backlog, Architect/Engineering and UX work as intermediaries for governance,
interfaces, and dependencies, Development teams own story planning and high-level estimates.
It is expected that key stakeholders of the Agile Release Train will start preparatory work 5 to 6 weeks earlier
itself so as to make this PI planning event productive and successful.


Preparation is typically required in three major areas


● Organizational and Team readiness
● Content readiness
● Facility readiness


The PI planning meeting follows well-defined agenda. Senior stakeholders set the context for ART teams by
providing required high-level insights on the program vision, product roadmap, focus for the current PI as well as
architectural vision. With these as inputs to the PI planning, Agile teams of ART are given breakout session to
draft their team PI objectives as well as to identify risk and dependencies. It is likely that the draft plan
presented by each Agile team may present challenges in terms of scope, resource constraints, dependencies etc.,


In the next stage of the PI planning meeting, management addresses these challenges by making some changes
and provide one more break-out session to Agile teams. At the end of this breakout session, each of the Agile
teams present their finalized team PI objectives along with risks and impediments which could impact their
ability to meet their team objectives. The management will then address these risks and impediments and
provide a way to move forward. Then the teams are asked to provide a confidence vote on meeting their team PI
objectives. This is basically to ensure shared commitment of ART teams on the Program PI objectives. Finally, the
PI Planning event ends with conducting a brief retrospective to captures what went well, what didn’t and what
can be done better next time.


At the end of PI planning ART stakeholders summarize the individual team into a set of program PI objectives and
use this to communicate externally and to track the progress towards the goals. Another output of the PI
planning event is a Program board highlighting the feature delivery dates, dependencies among the teams, key
milestones, which is used to track the dependencies amongst Agile teams and stakeholders of the Agile Release



Want to do a PI planning simulation session for your teams? Drop your details below & we will reach out to customize a remote session.

Introduction to PI Program Increment Planning in SAFe