The number 1 priority you need to invest in your IP Iteration... be ready for the PI Planning. That's even more important for remote PI Plannings. Make sure your preparation is ready and solid. You won't be able to catch up stuff during the PI Planning, you've missed to prepare upfront. Just the IP Iteration won't be enough for preparation. All people involved in PI Planning preparation should follow a common roadmap. RTEs and Scrum Master doing the logistics, agenda, Planning context. Product Management getting the Backlog ready. And Business Owners preparing the Business Context presentations. Preparing a remote PI Planning, you should also consider a few important aspects regarding tools and communications channels. The number one goal: enable and keep collaboration ongoing for the whole two days. I've learned and want to talk about a few important aspects.

Remember... individuals and interactions over processes and tools. One reason why a PI Planning gains its magic is because people use easy tools like sticky notes, pens and walls to put collaboratively created plans on it. Don’t disrupt analog behavior just because you’re doing remote planning. Instead, choose tools and communication channels that still focus on people and their interaction. That means, focus on a lean and clean approach when you're thinking about tools. ALM tools like Jira, Rally or Azure DevOps are designed to be great issue tracking and iteration execution supporters. They are not designed to support PI Plannings or agile events in general.

Define a clear toolset and the channels you will be going to use to connect your teams. There are different types of channels needed. Audio, Video, Presentation and Chat. Clarify every channels purpose and its owner, slash, facilitator. People participating the PI Planning will create outcomes which need to get visualized and shared across teams and locations to provide the necessary transparency. Here we are talking about real-time synchronized presentation channels in the form of digital boards. Stay as close to the behaviors we know using physical boards. Provide as much functionality as needed, as less as possible. Again, the teams should be able to focus on planning, not on questions what functionalities different tools provide.

Having real-time synchronized boards also provide a single source of truth. Every participant looking on the Program Board should see the same Program Board as everybody else.

A key difference between co-located and remote PI Plannings is the fact that we do not instinctively know, if it is a good time to interrupt an ongoing conversation. When everybody is in the same room we see whether a team is breaking down a feature and clarifying detailed questions or team mates are walking around, having some general discussions with different stakeholders. We need to shift the trigger for conversations in a remote planning. The ones receiving needed information trigger the ones providing it. The trick: Establish Working Agreements. I'll talk about working agreements when diving into specific roles in later lessons.

Finally, challenge your PI Planning agenda. It might make sense to split a 2 day PI Planning into 3 days, 5 hours each day. Virtually participating a PI Planning is exhaustive. Staying online 8 hours actively and effectively contributing in breaking down Features, solving dependencies and having detailed scope discussions with product management simply doesn't work.

In the next lesson I'll talk about “Remote PI Planning in the shoes of a Release Train Engineer”.

‍