Skip to main content

Conducting Remote Program Increment (PI) Planning: Tips, Tricks and Tools from the Field

Conducting Remote Program Increment (PI) Planning: Tips, Tricks and Tools from the Field

Many organizations shy away from scaling Agility or conducting robust Program Increment (PI) Planning because of remote teams. Gorilla Logic and one of its clients took on this challenge and saw great success. We’ll walk you through how we did it to show that remote Program Increment Planning is a viable option.

The challenge: How can an organization effectively plan on cadence, with all teams and team members present, when the budget can’t cover everyone traveling to a single location?

The solution: Conduct remote PI Planning using Scaled Agile Framework® (SAFe®).


Project Context

What: B2B e-commerce portal re-platform project.

When: Kicked off January 2018 with a projected go-live date of September 2018.

How: Scaling client’s scrum practices using SAFe®.


8 teams, 105 team members, 4 time zones, 3 countries, one re-platform


The project is comprised of seven, feature-based, full-stack scrum teams, each including scrum master, product owner, developers (front end and back end), QA (manual and automation), tech lead, and embedded architect. There is an eighth team responsible for systems/DevOps.

At the train level, there is a Gorilla Release Train Engineer, four product managers (one acting as Chief Product Owner), three architects and one development manager dedicated to the train. Six primary stakeholders consult with train leadership on the train’s product and architectural roadmap. These individuals are located in the US, UK and Costa Rica.


Remote Locations Map

Set Up – Optimize with Co-location and Tools

Co-locate where you can

The client established a main operations room in their Denver offices where all leadership were present during PI Planning: primary business stakeholders, PMO, Product Managers, most Scrum Masters and principal architects. The remote development teams, QA and embedded architects were co-located on-site to the nearest remote location (Costa Rica and London).

Leverage real-time, digital tools

Jira®: We used Jira, an issue tracking product developed by Atlassian, to build our user stories and Epics before PI Planning started. After finishing our PI Planning, the teams created and updated the user stories in Jira so we can continue to track the train’s progress.

RealtimeBoard: This cloud-based whiteboarding tool was key for keeping everybody on the same page and enabling collaboration across the teams. We used RealtimeBoard for almost everything in the PI Planning!  For example we:

• Inserted a Google Spreadsheet listing the Epics and their team assignments.

• Created a section for the Program Board.

• Set up spaces for teams to add their capacity, objectives, and stories, by sprint.

• Added Risk and Parking Lot sections.

The above web of collaborative, Agile tools was designed to mirror the physical space recommended for a PI Planning.  It was easy to draw lines, post sticky notes, and create comments for all to see in real time. We were delighted that we could capture and share information as if everyone was in the same physical space.  

RealtimeBoard also has a nice, built-in integration with Jira, enabling us to export the board as a pdf. Here are some screenshots of our board for the PI Planning:


Planning Board

Remote PI Planning Board



Team Board 

Remote Team Board



ROAM Board



Zoom: We use this conferencing software every day. For the remote PI Planning, we additionally leveraged Zoom Breakouts Rooms when the teams split out into their own work sessions. This functionality allowed us to communicate across multiple teams without having to set up multiple calls. This feature was especially useful in allowing the Chief Product Owner (CPO), and others necessary to a team’s breakout, to easily “step in” so the team could get the information they needed to complete their planning.

Slack: Slack is at the core of our communications. In this setting, for example, it was helpful to use Slack to coordinate when a person needed to jump from one breakout to another.

Planning Overview

We developed our PI Planning based on the recommended two-day agenda from SAFe®:

• Business context and vision

• Two team breakouts

• Two plan reviews

• Confidence vote

• Retrospective

How did we execute among different time zones (Americas & UK)?

To optimize the time zone overlap, we developed an agenda that was distributed over three days instead of two. This accommodation enabled all locations to be a part of the business context, product vision and architecture review. Breakouts were scheduled so that teams in the Americas worked in their afternoon, when UK teams were logged off. The UK teams had breakouts their next morning, while the Americas teams were logged off. Both geos would then be ready for plan reviews. All locations participated on ROAMing, confidence voting and the retrospective.


Sample Agenda

Sample Agenda Final

Day by Day Execution

Day One agenda items:

• Review Planning Context and Agenda – RTE reviewed the agenda and time frames with the train

• Product Vision – The product management team reviewed each feature under consideration for the PI with the entire train. Although the teams had heard about these features, this session was critical to the train’s full understanding of the scope of work for the program increment as well as the current program vision.

• Business Context – The executive sponsor then discussed the current state of the business and how the goals of the PI fit within the overall vision of the organization. She described the current state and near term direction of the business.

• Architecture Vision and Development Practices – the enterprise architect described the architectural vision for the product and reviewed a new team structure. There were no changes to existing development practices, but if there had been, the context would have been described here.

• Q2 Retrospective – Knowing how important it is to build on successes and improve where we can, we made sure to look back at the prior quarter and discuss what went well and what needs to be better.

• Team breakouts #1 – The teams on mountain time broke out to do an initial plan of their sprints for Q3 based on prioritized features. Remote teams used Zoom Breakout sessions so train leadership and architecture could join without too much disruption.

• Teams estimated their capacity for sprints 1-5 (70%, 70%, 50%, 50%, 50%)

• Finalized stories for assigned epics

• Identified dependencies (within train and external)

• Created draft plan sprint by sprint

• Identified risks

• Drafted PI objectives including stretch objectives

• Added features and dependencies to the virtual program board (see photo 1 above)

• Management Review & Problem Solving – During the Day One management review and problem solving session, the group reviewed initial plans from the Denver and Costa Rica teams and provided updates to London for dependency mapping. There were no scope changes on Day One.


Day Two Agenda Items:

• London Team breakouts #1 – While the Americas were sleeping, the teams in London started their day by planning their sprints for Q3 based on prioritized features as well as any dependencies called out by the teams from the prior day’s planning.

• Draft Plan Review – The full train was present again; London and Costa Rica teams were on the Zoom session while Denver teams and train leadership gathered in person. Each team reviewed their draft plan for the five sprints of the PI  with the train leadership and stakeholders. The teams presented their draft PI objectives and listed any potential risks and dependencies across the train and external to the project. This was the first of two sessions.

• Dependency Mapping and Planning Adjustments – Once the team presentations were complete, the teams collectively mapped features and dependency stories on the RealTime program board (see image 1 above).

• Team breakouts #2 – Teams in Denver and Costa Rica broke out for the second time to finalize their sprint plans and re-adjust based on the dependency mapping exercise. Teams finalized sprint objectives.

• Management Review & Problem Solving – During Day Two of problem solving, the team discovered the initial features that London planned to work on would require additional support from an internal business process team. Because the London team was not immediately available for a real time discussion, the management team sent a message to the London team indicating  a new feature which would replace the descoped one. The Denver and Costa Rica teams stayed on course and prepared for their final presentation the next day.


Day Three Agenda Items:

• London Team breakouts #2 – The London teams began their Day Three by reviewing input from Denver’s Day Two management review and problem solving session. They  were able to adjust their sprint plans based on the feedback.

• Final Plan Review – Once all teams came together on Day Three, each team presented their final plan review. The London team, who was directed to switch gears, provided two different sprint plan options and after some debate, everyone agreed to a hybrid of plan A and plan B. The teams stated risks and issues which were added to the ROAM board (see image 3 above). Each team presented their finalized PI objectives and the product management team assigned values (1-10).

• Program Risks and ROAM activity – All team members then presented each of the risks which were compiled on the ROAM board (see figure 4 below) and each risk was assigned to one of the following columns:


ROAM Acronym


• Confidence Vote – The full team voted on their confidence in meeting the PI objectives. We did this using a “fist of five.” Any person showing less than three fingers states their reasons and the entire team listens and attempts to address the problems. Prior to agreeing to the plan, everyone must raise three fingers or more. In our planning session a few of the team members were below a three. They stated their issues and the program came up with a plan to move forward. A re-vote was done and everyone agreed to the plan.

• Review Parking Lot Items – The team had a number of parking lot items over the two and a half days so we spent 30 minutes reviewing those items.

• Planning Retrospective and Moving Forward – This was our first remote PI planning. The team had a lot of ideas on how to make it better for next time, and also shared how surprised we all were at how well it went. See Figure 4 for retro items.


Retro Board

Lessons Learned Remote PI Planning


• Next steps for teams – The teams had many items on the ROAM board, so we made a plan for the first few sprints while also detailing how we would progress towards our major milestone.

Lessons Learned

Retrospectives are foundational for Agile teams and SAFe® trains. This was our first PI planning and we were working in a remote fashion so we anticipated lots of learning. We are happy to report that while there were a good amount of items in the “what didn’t go well” column, overall we were very successful. A couple things to note so you don’t run into the same issues we did:


Learning from remote PI planning


In Summary

Remote planning is less optimal than big room planning, but do not let that discourage you –  there are so many benefits! Take advantage of all the tools at your disposal and remote PI planning can be successful. Co-locate where possible and encourage key individuals to go where they will be the most valuable. By following the guidelines Scaled Agile® recommends and altering the days and times where you must, you can succeed with remote PI planning.


Read all the lessons we’ve learned since this post in our follow-up post here!


New call-to-action