PI Planning, or "quarterly" planning in a scaled agile environment

In the first phase of the project we focused on agile education, taking into account local conditions and the specificities of the multilocation team. After learning and practicing the basic agile education and agile design process, the participants were introduced to the characteristics of scaled agile operations. The most important training before the first PI Planning was the PI Planning simulation, focusing on the valuable elements and products delivered by PI Planning, the main elements of the event and the main activities of the team members. The training also included a simulation exercise to pre-test multi-team planning.

The second phase involved preparing for PI Planning. We often encounter situations where a team wants to start working in an agile manner but is unable to accurately estimate how much time it will take to set up properly structured, competent product teams and prepare an adequate backlog before actually starting implementation. As a result, they begin with PI Planning immediately after preparatory training.

SAFe works with a special sprint system, where the last two-week sprint of the usually 12-week PI is the so-called IP (Innovation and Planning) iteration. Within the Innovation and Planning iteration, the first 6-7 days are used to round off any backlog, finalise documentation, innovation activities, training sessions as required and to prepare for the most important element of this project description, the so-called PI Planning. In all cases, this preparation will be done by means of a PI Planning Readiness checklist, in order to follow up the work to be done at different levels before planning. In the second week of the IP iteration, two events that are essential in scaled systems take place, one is the "demo and retrospective" of the entire scaled Agile team, or in SAFe parlance, the Inspect and Adapt event, which provides insight into the results of the previous PI and an opportunity to surface and resolve issues affecting the operation. The other is the PI Planning, which is important in our case, and is ideally a two-day planning event with all the team and key stakeholders.

The third phase was the actual implementation of the event, which required focused attention and intense activity from all participants at all times. In our case, we did not have the opportunity for two days of PI planning, so we carried out the first experimental PI Planning in one day. The condensed agenda included the following elements:

• Facilitator's short opening
• Opening by the top management
• Product Managers: the main priorities at Epic and Feature level and their context, and then answering the questions that arise
• Capacity planning
• Design preparation (teams, POs and Product Management members): feature selection, fine-tuning, creating user stories, answering clarification questions, estimating stories. One of the most motivating elements of the event was the openness and active participation of Product Management in answering questions and sharing ideas.
• Team level planning:
  • At separate tables, the teams discussed the main elements of the next 5 two-week sprints and assigned the elements they had created to the corresponding sprints
  • They then summarised the planned focus and purpose of each sprint based on their current knowledge. The facilitators asked questions at each stage, providing guidance to help keep the planning at the right level and to ensure that team members did not get too lost in the detail.
  • Planning at team level and coordinating the work of teams is one of the most energy-consuming tasks in PI Planning. After planning their own work, the team needs to perform capacity checks and visualise the dependencies between teams. They can do this with more rest and reflection over a two-day event, but as this was not possible in this case, teams had to plan and replan many times in succession (e.g. when an unbridgeable dependency or risk surfaced).
• The Product Management meeting ran in parallel with the team planning, where participants followed the plans as they developed, focusing on targets and deadlines. Any new decisions had to be incorporated into the planning by the teams.
• After planning, the teams reviewed the plans and created PI goals, i.e. they presented what their focus will be for the whole next period, which they finalised together with Product Management members, depending on capacity. In addition, a list of known risks was presented, as well as the ART Board with dependencies and deadlines.
• Teams were then given the opportunity to give their feedback on the event either on the spot or in written form.
• In the following days, the results of PI Planning were uploaded to the Project Management platform used for planning and follow-up. The teams used it to plan their sprints accurately when the first sprint started.

The multi-step team planning, problem-solving workshop of Product Management, risk management, retrospective of the event and longer reflection on the plans, familiar from the two-day format, were not possible in this first pilot PI Planning, the consequences of which were experienced by the team in the following period.

In the fourth phase, based on the lessons learned from the team's first experimental PI Planning, we further developed the Innovation and Planning iteration, continued agile education in smaller workshop formats, and introduced other elements of agile operational development, such as the event system, support from various experts, and generally increasing agile maturity. We collected the specific goals and activities related to the development of PI Planning, as well as the tasks supporting operational development, in a development backlog dedicated to this purpose.