Or “How can we reduce the impact of timezones on the PI Planning event?”

PI Planning events becomes more complex as more timezones become involved. I have now experienced events where, for example, we have teams and distributed teams in people in locations as diverse as France, USA east and west coast, Australia, and India (OK perhaps we should look at our team structure, but that is what we have:-/) for a single ART.

How do we do “respect for people” when if we are not careful we end up forcing everyone to spend some time together at a time where it is not normal for them to work.

A “normal” approach is to declare “we are only doing this for a couple of days so let's use US timezones in general”. With the traditional agenda for a PI Planning event this means many are working hours at weird hours.

We spent some time looking at this approach, decided we needed to do better, and developed an experiment. We noticed that there are two basic types of agenda items on the agenda - those that work better when everyone is involved, and those that do not. Items that benefit everyone being involved include agenda items such as the kick-off sessions, plan reviews, plan adjustments, ROAMing risks, and the ART Confidence vote.

Others such as breakout sessions do not. We looked at the breakout session in particular, since it takes a lot of the time. There is clearly benefit in doing this at the same time as well such as

1. We can work dependencies quickly and directly if we are all working at the same time
2. We can understand progress toward plan and final plan review by doing the Scrum-of-scrums, for example

We setup an experiment to mitigate these two issues:

1. To work the dependencies, we set up an event at the beginning of Day 2 and Day 3 of we called “Dependency Discussion”. This was a designated time for teams to reach out to each other. Teams used asynchronous back channel communication to set up specific discussions. Note that we were clear with everyone that there was no problem with people reaching out and working these issues directly, but this gave a place if that process did not work, for whatever reason.
2. To work the progress issue we provided a set of acceptance criteria to help teams understand whether they are ready for draft and final plan reviews (see below).

From the release train engineers perspective, this felt like a bit of a risk, in that they weren't shepherding the process, but we figured it was a good experiment. It turned out that we need not have worried. The experiment was successful and I have since used this approach in multiple organizations with good effect. Feedback was very positive. Interestingly while some teams really did change their schedule for team breakouts to better support team timezones, a number of teams did not, and even they reported improved feeling about the PI Planning event. I suspect this was because we left the decision for time to plan to the teams and we were seen to listening to feedback from the PI Planning event.

• For Team Boards
  • Capacity calculated for each Iteration (Sprint)
  • User Stories from Features “road-mapped” in Iterations (Sprints)
    • User voice format
    • Story point estimate
  • Running total of Load calculated for each Iteration (Sprint)
  • Load < Capacity for each Iteration (Sprint)
• Draft PI Objectives with clear description of the business hypothesis being delivered, and simple answer to “how will we know we have achieved this PI Objective beyond just completing the Feature”.
• Draft Program Risks identified and placed on Program Risk board
• Draft Program Board entries for the Team based
  • Iteration Feature completes
  • Dependencies between Teams marked up
  • Dependencies have been negotiated and agreed to between the Teams, or expect to prior to Final Plan Review
• Intake list of Features for Team, based on current expectations, categorized by:
  • “Expect to complete in this PI”
  • “Expect to start in this PI”
  • “Do not expect to start in the PI”

• Final versions of the items above based on results of planning adjustments, additional planning, increased awareness (now that people have slept on it). So:
  • For Team Boards
    • Capacity calculated for each Iteration (Sprint)
    • User Stories from Features “road-mapped” in Iterations (Sprints)
      • User voice format
      • Story point estimate
    • Running total of Load calculated for each Iteration (Sprint)
    • Load < Capacity for each Iteration (Sprint)
  • Final PI Objectives with clear description of the business hypothesis being delivered, and simple answer to “how will we know we have achieved this PI Objective beyond just completing the Feature”.
  • Final Program Risks identified and placed on Program Risk board
  • Final Program Board entries for the Team based
    • Iteration Feature completes
    • Dependencies between Teams marked up
    • Dependencies have been negotiated and agreed to between the Teams, or expect to prior to Final Plan Review
  • Intake list of Features for Team, based on current expectations, categorized by:
    • “Expect to complete in this PI”
    • “Expect to start in this PI”
    • “Do not expect to start in the PI”
• Plus
  • Team confidence vote.
• Stretch
  • Information up to date in Jira:
    • Stories are in Iteration (Sprints) per the plan from PI Planning, including the estimates
    • Features (Jira Epics) set to “Implementing”, Start and end dates entered, BH / AC / etc. updated to reflect changes from planning