Introduction to PI (Program Increment) Planning in SAFe

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 Train.