Remote PI Planning: Tips, Tricks, and Tools
This is post 1 of 2 in the series “Remote PI Planning”
- Remote PI Planning: Tips, Tricks, and Tools
- Remote PI Planning, One Year Later: Lessons Learned & Improvements Made
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 the 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®.
The project is comprised of seven, feature-based, full-stack scrum teams, each including a 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 U.S., UK, and Costa Rica.
Remote PI Planning Set Up: Optimize with Co-location and Tools
Co-locate where you can
The client established the main operations room in their Denver offices, where all leadership was 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® Software Development Tool: 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 used RealtimeBoard to:
• Insert a Google Spreadsheet, listing the Epics and their team assignments.
• Create a section for the Program Board.
• Set up spaces for teams to add their capacity, objectives, and stories by sprint.
• Add Risk and Parking Lot sections.
The above web of collaborative, Agile tools was designed to mirror the physical space traditionally recommended for a PI Planning. It was easy to draw lines, post sticky notes, and create comments for everyone 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:
PI Planning Board
Team Board
ROAM Board
Zoom Video Conferencing: 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 individual 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 Chat Platform: 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 room to another.
PI 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 PI Planning across different time zones (U.S. & 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 U.S. worked in their afternoon, while UK teams were logged off. The UK teams had breakouts the next morning (their time), while the U.S. teams were logged off. Both locations would then be ready for plan reviews. All locations participated in ROAMing, confidence voting, and the retrospective.
Sample Remote PI Planning Agenda
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 U.S. teams 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 that 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 – When all teams came together on Day Three, each team presented their final plan review. The London team, which was directed to switch gears, provided two different sprint plan options and, after some debate, everyone agreed on 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 its 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:
• Agile 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 next time and shared how surprised we all were by how well it went. See Figure 4 for retro items.
PI Planning Retro Board
• 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 milestones.
Lessons Learned from Remote PI Planning
Retrospectives are foundational for Agile teams and SAFe® trains. This was our first PI planning working in a remote fashion, so we anticipated lots of learning curves. 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 of things to note so you don’t run into the same issues we did:
In Summary
Remote PI planning may seem 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!
