Can You Be SAFe Without PI Planning?

Get in Touch

Em Campbell-Pretty February 12, 2014

Category:

The concept of a Program Interval (PI), is generally considered the cornerstone of cadence in the Scaled Agile Framework (SAFe). In simple terms, SAFe recommends that a PI consists of between 4 and 6 two-week iterations, including an IP (Innovation & Planning) iteration. Each PI commences with a two-day "all hands" PI Planning event during which a high-level delivery plan is produced for the PI. As readers of this blog would already be aware, when we launched our first agile release train, we did not have enough funded development work in the pipeline to justify a full-blown release planning event, so we invented Unity Day.

Given that we could not use the PI cadence initially, we adopted a rolling wave planning approach. Late last year, demand started to exceed supply for the first time in the brief history of the EDW Release Train. Our first response was to add an additional team to our Release Train. When a couple of months later we found we were still feeling severely capacity constrained, the concept of implementing PI Planning as per textbook SAFe became a regular topic of conversation at our leadership team lean coffee.

We had shied away from adopting PIs in our first 18 months as a Release Train. In the early days, when demand was at its lowest, the majority of our projects/epics were simply responding to changes in front of house or billing that had consequential impacts on the Enterprise Data Warehouse (EDW). The priorities of the projects were set at an enterprise level, and our ability to make our stakeholders commit to even an eight-week plan seemed unrealistic.

With demand spiralling out of control, we needed to take action, so we decided to experiment. We would run a one-day "all hands" PI Planning event. As we had done a year earlier, my leadership team sat down with copies of Dean Leffingwell's Agile Software Requirements opened it to the section on PI Planning and started to adapt it to our needs. We landed on the following one-day agenda:

9am Unity Hour
10am Feature Team Planning
12pm Lunch
1pm Technical Alignement Huddle
1:30pm ROAM
2:30pm Dependency Alignment Huddle
3:30pm Re-unification
4:45pm Commitment

As our first PI Planning day drew closer, we found ourselves short on time. What should we do? Postpone? "No", I say, channelling Artful Making, "The show must open on opening night!". We had wanted to understand priorities at the feature level, but had to settle for epic-level prioritisation. We struggled to get participation from our business stakeholders, and those who had agreed to attend dropped out at the last minute. Despite some things not going according to plan, we stuck to our time box and held firm to our committed date. After all, the show must go on!

We were still working out the logistics at 9:10 am on the day. Rolling with the punches,s we quickly brought the room to order and commenced our first PI Planning Day. Unity Hour was brief, we used the time to talk about the day ahead and the prioritised program of work, making sure to include our traditional "shout outs". Given our concerns about capacity constraints, the amount of WIP, and the constant context switching it was driving, the theme of the day was "Stop Starting and Start Finishing".

Our six stream-aligned teams co-located for the morning planning session in a large meeting room. The energy from the group was nothing short of amazing. Just writing about it brings the memory of that buzz to the forefront of my mind, and I find I am smiling to myself. The goal of the morning was to produce a high-level plan, lower than feature level but less granular than a user story, for the next 4-5 iterations. For the most part, this was achieved without too much pain.

PI Planning for 6 teams — 6 Feature Teams PI Planning

After lunch, we kicked off the technical review of the plan. Given that all our feature teams are delivering capability from a single integrated physical data model, we were keen to understand if there would be any overlaps or collisions between the teams during the course of the PI. It was during this session that I realised that the published agenda for the day was not the agenda we had written up on the whiteboard. It was clear that context was missing from the conversation, as we had accidentally left out the reunification step originally scheduled to occur after lunch.

I gathered my leadership team for a quick discussion. What should we do? Continue with the published agenda? Revert to the original plan? While there wasn't enough time left in the day to revert to the original plan, it was clear the team was struggling. Then I remembered, "A good facilitator knows when to vary from the plan. Follow your nose." So we landed on making reunification our next session, accepting that we would probably have to forgo the remainder of the day's agenda.

I went back to where the teams were gathered and explained the scheduling mistake that had been made and apologised. I shared with the team the proposal that we adjust the agenda to compensate, and then asked them how they wanted to proceed. They agreed context was missing, so we broke for 15-20 minutes, while the feature teams were informed that we would be bringing forward the all-hands reunification session.

With the full release train present, each of the feature teams and the system team shared their goals, plans, risks and most importantly, dependencies. Feedback from most parties indicated that this was the most valuable part of the day. It certainly struck a chord with me, given the importance I place on the value of shared understanding in building teams. And as promised, this ended up being the last session of our first PI Planning.

My leadership team used the last hour of the day to reflect on the experience and consider the way forward.

What worked well?

Shared understanding across the group on the in flight and upcoming program of work

Plans focused on finishing rather than starting

Identification of cross team dependencies

The energy and sense of camaraderie in the room and during the day

The show opened on opening night!

What needs improvement?

Planning!

Air conditioning!

Business participation!

Planning at the right level of granularity

While the PI planning day had delivered unquestionable value by providing shared understanding and greater visibility of dependencies, most of the team indicated that their plans had not materially changed as a result of the day. (Although the focus on plans that limited WIP had helped.) Some of us also felt that a move from rolling wave planning towards PI Planning represented a move towards larger batch sizes and would be a step back in our mission to achieve flow. After some discussion, we decided to hedge our bets; we would work on improving our rolling wave planning approach and monitor our progress over the next four iterations, before making a decision to hold another PI Planning day.

With the learnings from the PI Planning day fresh in our minds, it was time to think about how we could make our rolling wave planning more robust and sustainable. The key change we made was to add back the reunification at the end of the day. (This is something we had done previously but had been dropped over time.) At reunification, each team provides their sprint goals for the new sprint, advises on updates to their rolling four-iteration plan, and calls out dependencies and risks to the plan.

We have been using our revised rolling wave planning approach for about six iterations now. We had a checkpoint with the teams late last year and decided to proceed with this approach for now, as opposed to adopting the practice of PIs. For us, right now, this practice is working and is still aligned with the SAFe principle of synchronisation and cadence. I don't know if our position will change in the future, and I don't know if this practice makes sense for other Agile Release Trains.

In our enterprise context, we are driven by alignment to upstream dependencies, not by putting stakeholders together in a room to make tradeoff decisions. Without that value-add, the PI construct doesn't help us. But do I regret holding it? No, it was great and we learnt a lot. Admittedly, most of what we learnt was how to improve our approach to rolling wave planning with SAFe - and that learning has shown benefits already!

Updated June 7, 2026, to reflect SAFe 6.0 terminology.

Tags: Agile Release Train, Collaboration, EDW Release Train, PI Planning, Scaled Agile Framework

< Iteration Reviews vs System Demos and what on earth is an ART Show?!