SAFe is the most preferred framework worldwide when scaling Agile to the enterprise level. It is because it strives to fill the gaps when the level of Agile is scaled up. Multiple teams work together for standard products, objectives, and results. But when you have just begun scaling Agile in your organization, bringing multiple Agile teams together may seem intimidating. Even if you have done it already, things may need improvement. There is always room for improvement. Here, Program Increment or PI planning plays a crucial role because it is an event that brings representatives from all the teams together to help them in working together. This article will describe everything about the SAFe Program Increment planning and how it is done. But first, let us understand what Program Increment is.

Program Increment (PI):

A Program Increment is a timebox or a previously agreed period in which incremental value is delivered by the Agile Release Trains (ARTs) in the shape of a working and tested product or system. The duration of PIs usually is 8-12 weeks. The most used design of PIs includes four development iterations, one innovation, and finally, Planning Iteration (IP).

A PI means the same thing to an ART that an iteration means to an Agile team. A fixed period called a timebox is given for planning, building, and validating a full increment that would show value and get faster feedback. Cadence and synchronization are applied to each PI for the following purposes:

• Planning the next increment of work for ART
• Limiting the amount of work in progress (WIP)
• Assuring ART-wide retrospectives that are consistent
• And summarizing the significant value of feedback

Since the scope of PI is quite broad, it provides a suitable timebox for considerations at the portfolio level and road mapping.

Let us now know what PI is planning.

SAFe PI Planning:

Program Increment is an event in SAFe that is based on cadence, is carried out face-to-face, and is the pulse of an Agile Release Train. It aligns all the teams on an ART to work toward a joint mission and vision. It is a crucial part of SAFe to the extent that if you are not doing PI planning, then you are not doing SAFe. According to the Agile manifesto, face-to-face conversation is the best and the most effective method of communicating information to and within all the development teams. And in SAFe, this is taken to the next level with the help of PI planning.

The PI planning in SAFe is a two-day event where all the teams, Stakeholders, and Product Owners/Managers sit together to review the Program Backlog and set the direction of the business. These two days are spent on focused planning. This is a periodic event that takes place every eight or twelve weeks. Organizations may face a significant challenge in organizing such an event because of the prominent teams distributed all over the country or even to different parts of the world. Product Managers set the priorities for the planned features before the PI planning event, and the development teams own User Story planning and estimation. Engineers and UX teams work to validate the planning. The objective is that the teams should align with each other and the mission. As far as possible, everyone concerned personally attends the event. However, technology is allowed in the case of distributed teams that may be spread out in different locations.

Next, we will describe how to prepare for PI planning.

PI Planning Preparation Steps:

There are three areas in which you have to prepare for PI planning. These are:

The organization should be ready:

It should ensure that all the Stakeholders and leaders involved in the program are available for the PI event and on the same page regarding the business strategy. And the best way to do this is to schedule the PI meetings well in advance so that everyone can be appropriately notified and make arrangements for attending the meetings. Most large companies fix a quarterly schedule for these meetings, so everyone’s calendar is fixed. A better way is to schedule such a meeting at the end of the previous quarter so that everything is organized for the start of the next quarter.

Content should be ready:

Before starting the planning process, the program’s purpose and vision should be fully ready. It is best to communicate this to the teams by Stakeholders and program leaders at the start of the first day.

The facility for conducting the meeting should be ready:

A large room would serve best for the teams to move around freely and interact with each other and ask questions from each other. A standard for this is to arrange a room double the size that would be generally required for the number of people to be accommodated in the room, which means if 80 people are to be adjusted, the meeting room should have the capacity to accommodate 160 people. For remote teams, arrangements for video conferencing should be in place.

This completes the preparation for holding the Program Increment planning meeting. The next step is the agenda of the meeting. What needs to be discussed in the SAFe program increment planning meeting?

The Scaled Agile Framework PI Planning:

The PI planning meeting agenda follows a standard agenda. To ease the atmosphere, add some motivational speakers or even hold some games that could act as an ice-breaker between the teams and bring them closer. This could be an excellent team-building exercise. The scaledAgileframework.com provides an example of the PI planning meeting agenda that goes like this:

Agenda of Day 1

Business context:

A Senior Executive or Business Owner starts the proceedings with a presentation on how the business is currently performing, sharing the portfolio vision. Around one hour is given for this presentation. They then present a description of the current solutions taking care of the customer and keeping up with the market needs. They also describe gaps.

Product/Solution vision:

Above presentation is followed by a presentation by the product management team regarding the current vision for the business. This is usually represented by the forthcoming top ten features the business management determines to help meet the business goals. They then describe any changes since the last PI planning meeting. And they close it with a description of the upcoming milestones.

Architectural vision and Development practices:

Next, the System Architect/Engineer presents an outline of the systems and architectural vision. This includes improvements in the infrastructure that will aid in reducing the time to market and can affect the development during the following PI. Besides, a senior development manager may suggest changes in Agile development practices that would help enhance velocity and communication. These may include DevOps, continuous integration, deployment, and automation for the upcoming PI.

Planning context and lunch:

The Release Train Engineer (RTE) will then give a synopsis of how the PI process will work and what results are expected from the teams and the meeting. After outlining the expected outcomes from the meeting, the RTE will answer the team’s questions regarding the process.

Team breakouts:

In the breakout, teams collect around the boards, which can be either analog or digital, and estimate their velocity for each iteration and look at the backlogs they would be required to bring forward to support the features presented in the product/solution vision. Teams then prepare their draft plans individually for each iteration and present them for feedback and review. Teams are required to identify their risks and dependencies during this process. They also prepare a draft of the initial PI objectives of their team. This is also the stage where the team would say their iteration would connect with other teams and maybe even the Agile Release Train (ART).

Review of the draft plan:

Draft plan review is a timeboxed meeting in which the teams present draft plans for the Stakeholders, Business Owners, Product Owners, and other teams to give their feedback. The teams can use this feedback to read their draft plans before the management review. They can also present a contour of the potential problems to be solved by the management. The teams present key planning outputs in this review, including draft PI objectives, capacity and loads, and dependencies.

Management review and problem-solving:

The draft plan will likely bring out issues related to scope, architecture, constraints of people and resources, and dependencies. A call on these issues is taken during the problem-solving meeting, where the management may negotiate on scope changes and resolve other problems by giving their consent to make adjustments in the planning. The Release Train Engineer organizes the meeting and strives to keep the Stakeholders together till the decisions are made to reach achievable objectives. The meeting must end with the Stakeholders coming out of it offering a new set of features or priorities that the teams can use the following day.

Agenda of Day 2

Planning/Program adjustments: The second day of the PI planning meeting begins with management’s presentation of changes in the planning scope, people, or resources. They present the decisions and adjustments made by the management and Stakeholders in the problem-solving meeting. Teams are presented with these, which may sometimes result in new top-ten features emerging. These are then posted on the program board for all the teams to see and readjust.

Team breakouts:

These adjustments are then taken back to planning by the teams, and they continue to plan based on their agenda from the previous day, making the required adjustments. They then return with their PI objectives and put them on the program board. These objectives are then ranked for implementation after a value is assigned to each objective by the business owners. This value becomes the basis of the ranking. This gives the teams a fair idea about their objective position in the upcoming iterations.

Final Review of plan and lunch:

This is the session where all the teams present their plans to others. They end their presentation with a list of risks, dependencies, and obstacles to the RTE so that these can be used later in the ROAMING exercise. The business owners are then asked if they accept the plan. Once the plan is accepted, the teams bring their objectives sheet to the front so everyone can see it. But if there are any reservations about the plan from the business owners, then the teams can make changes according to the identified issue. And then, they can present the revised plan. However, there are other stages to resolve any issues.

Program Risks:

Teams have identified risks and obstacles that can prove detrimental to achieving their objectives in the previous step. With all the objectives posted on the board, the team can now look at each risk and see if they can be resolved. They are sorted out in front of the entire train in a broader management context. The risks and issues so identified are then placed in one of the following categories:

• Resolved: Teams discuss among themselves and conclude that the issue is no more a worry.
• Owned: Since the issue can not be solved during the PI meeting, someone from the train takes ownership of it to resolve it later.
• Accepted: Certain risks or potential problems are a reality and must be understood and accepted.
• Mitigated: Teams work together to formulate a plan to mitigate the impact of the risk. The solution so arrived at is documented so that it can be recalled when the need arises.

Confidence vote:

After all the risks and objectives have been discussed and addressed, the teams vote on their confidence about achieving the PI objectives in the coming PI. This is five fingers kind of voting where all the team members raise their hands with one or more fingers. The management accepts the vote of confidence if the average is three fingers or more. Anything with an average of fewer than three fingers has to be taken care of. Anyone raises two fingers has to be allowed to speak on the issue so the team can resolve it. This exercise may add to the list of risks, require some re-planning, or provide some information. If the issue is resolved, the teams vote again on the objective so that confidence is reached for the following PI. The process is repeated for the whole ART for a vote on confidence in the collective plan.

Retrospective:

This is the last stage of the PI planning meeting. Here, the RTE holds a retrospective on the PI planning meeting to get feedback on what was right in the meeting and what, if anything, needs to be changed for the next event. This is followed by a discussion on what steps have to be taken next and final instructions to the teams. Once the PI planning meeting is over, the RTE and the other Stakeholders in the ART sum up the PI objectives of individual teams and prepare a set of Program PI objectives used for external communication and tracking the progress.

So, we have detailed everything about the SAFe PI planning event. In today’s world, teams work more remotely and are distributed in many geographical locations. So, some may physically attend the PI planning event while others may need help to do so. For this, business owners must consider ways to include all the teams in the event so that every team can provide valuable input and better coordination and collaboration among the teams can be achieved. Multiple technological tools are available to facilitate such an arrangement and RTEs can take advantage of these tools. And this will provide the best results.