PI Planning. Project Increment Planning according to SAFe®
What is a PI Planning event? How do you prepare and follow up? How do you carry it out?
The team backlogs with non-functional requirements must be prepared for PI Planning.
Program Increment (PI) objectives are a summary of the business and technical goals that the teams of an Agile Release Train want to achieve in the upcoming PI.
A program increment is 8 - 12 weeks long and usually consists of 4 iterations plus an IP iteration for innovation and planning of the next program increment.
The system demonstration is an important event where an integrated view of the new features within the latest iteration is possible. Each demo gives ART stakeholders an objective measure of the progress of a program increment.
At the Inspect and Adapt (I&A) workshop at the end of each program increment (PI), the current status of the solution is demonstrated and evaluated by the ART.
Release on demand is the process that introduces new functionality into production and releases it to customers immediately or incrementally as required. In contrast to development with fixed timeboxes, release is possible at any time.
This is only a reproduction of an excerpt from the SAFe® 5.1 Big Picture by Scaled Agile Inc. published at https://www.scaledagileframework.com/
PI Planning – The Event for Communication and Synchronization
Program Increment (PI) Planning is a regularly occurring event when using the Scaled Agile Framework®, SAFe®. During PI Planning, all stakeholders of an Agile Release Train (ART) should be present so that direct communication can take place face-to-face. Thus, PI Planning also forms a social construct that enriches both the individual participants and the collective. However, since the outbreak of the COVID-19 pandemic, many organizations have also had to host this event as an online meeting. PI Planning is the heart, the engine or clock of ART and aligns all teams around a common mission and vision.
The participants of the event include: business owners, product management, agile teams, system and solution architects, the system team and other stakeholders, all of whom must be invited in advance to be well prepared. The active participation of the business owners in this event is an important guardrail for budget planning.
PI Planning is essential to SAFe®: If you are not doing it, you are not doing SAFe®.
Scaled Agile Inc.
What Is a Program Increment?
A program increment (PI) is a period of time during which an Agile Release Train (ART) delivers incremental value in the form of working, tested software or systems. Program increments are typically 8 to 12 weeks in length. The most common pattern for a PI is four development iterations, followed by an Innovation and Planning (IP) iteration. A PI is to an Agile Release Train as an iteration is to an agile team. It is a fixed timeframe (timebox) in which to plan, build, and validate a full system increment, demonstrate the value created, and provide rapid feedback. Each program increment applies this fixed sequence (cadence) to synchronize all teams in the ART.
The Benefit of PI Planning Events
Personal Communication
for direct and fast decision making between all team members and stakeholders.
Social Network
strengthens cohesion and collaboration in the Agile Release Train.
Clear Goals and Vision
Align development with business objectives in the business context, vision, and team and PI goals.
Demonstration and Evaluation
of created value with direct feedback as a driver for further development.
Lean Architecture and User Experience
Constant Workflow
Match demand to capacity and eliminate excess work in process (WIP).
PI Planning Input
In order to successfully conduct a PI Planning, one must be well prepared in terms of organization, content and logistics. In terms of content, the event must be kicked off with presentations by:
- Business context
- Roadmap and product vision + Top 10 features of the program backlog
- Architecture vision
be coordinated and elaborated. Organizationally, the Agile Release Train must be ready to go, i.e. teams, roles, planning scope and process must be clear to everyone, and logistically, such a large event also needs good preparation (room booking, travel, technology, catering, etc.).
PI Planning Output
Successful PI Planning delivers these two outcomes:
- Established PI goals. These are specific, measurable, accepted, realistic and timed, in short SMART goals, created by each team, with business value assigned by the business owners.
- A shared program board showing new feature delivery dates, feature dependencies between teams, and relevant milestones.
And of course, such a joint event strengthens the cooperation in the Agile Release Train. It sharpens the common vision and thus automatically increases the motivation of all participants.
The Agenda of a PI Planning Event
A PI Planning has a standard agenda, usually lasts 2 days (longer if there are multiple time zones) and takes place within the Innovation and Planning (IP) iteration. At the beginning, the business context, the product vision and roadmap as well as the top 10 features from the program backlog are presented. Then there is an outlook on the architecture and development techniques. The Release Train Engineer (RTE) facilitates the event, presents the planning process and the expected results of PI Planning. Then the individual teams go into breakout sessions where they estimate effort, identify backlog item dependencies, plan for feature realization, and create a draft of their plan for the next increment. The drafts, with each team’s goals still non-binding, are presented in a joint review. Dependencies, conflicts, and resource constraints are then negotiated together and decisions are made that are necessary to achieve the goals.
Day 1
1. Presentation of business context and product vision, architecture and development practices.
2. Team planning breakout sessions
3. Review
Program risks are then discussed together and assessed according to the ROAM principle. Resolved, Owned (someone takes responsibility for this risk), Accepted (accepts that there could be potential problems) and Mitigated (risk defense is planned).
A vote of confidence follows. Teams vote on their confidence in meeting their own PI goals with a “fist of five”. If the average is three raised fingers or more, management should accept the commitment. If it is less than three, the team should revise the plan. Anyone who has concerns or sees risks is allowed to express them openly, and plans must be revised as needed. Then the process is repeated for the plan for the entire ART.
If necessary, teams revise their plans until a high level of confidence is reached, deliberately without a timebox. Only when plans reach consensus does the RTE lead a short retrospective for PI Planning. This is followed by: cleaning up together, capturing teams’ PI goals and stories in an agile project management tool, updating team and ART calendars, determining locations and timing for further iteration planning.
Day 2
1. Management presents changes in scope, staff and resources
2. Team planning breakout sessions
3. Team planning review
4. Joint risk assessment
5. Vote of confidence
Optional: Revision of the plans
6. Planning retrospective
Program risks are then discussed together and assessed according to the ROAM principle. Resolved, Owned (someone takes responsibility for this risk), Accepted (accepts that there could be potential problems) and Mitigated (risk defense is planned).
A vote of confidence follows. Teams vote on their confidence in meeting their own PI goals with a “fist of five”. If the average is three raised fingers or more, management should accept the commitment. If it is less than three, the team should revise the plan. Anyone who has concerns or sees risks is allowed to express them openly, and plans must be revised as needed. Then the process is repeated for the plan for the entire ART.
If necessary, teams revise their plans until a high level of confidence is reached, deliberately without a timebox. Only when plans reach consensus does the RTE lead a short retrospective for PI Planning. This is followed by: cleaning up together, capturing teams’ PI goals and stories in an agile project management tool, updating team and ART calendars, determining locations and timing for further iteration planning.
There is no magic in SAFe® … except maybe for PI Planning.
Dean Leffingwell
Remote PI Planning with distributed Teams
If a PI Planning event has to take place online, more preparation may be required. If the teams are spread around the globe, the time difference must also be taken into account in the planning. It is then advisable to extend the agenda over several days. Remote PI Planning can bring additional challenges in these points:
- Planning of various locations
- PI Planning agenda with different time zones
- Room booking & technology at various locations
- Consideration of all work agreements of the event participants
- Use of technology to support the various planning activities
- Facilitation of a successful distributed PI planning event
The community platform of the Scaled Agile Framework® offers many tips and templates for registered members on how to organize such remote PI Plannings. Certainly, the organization of a remote PI Planning takes more time. It is advisable to have a moderator for each location, to test a person responsible for the technology, audio, video and screen sharing several times beforehand, to contact the teams beforehand e.g. via the scrum master, to plan more buffers and also to plan program points for the social aspect (e.g. singing a song together, a motto for all participants etc.).
SAFe® and Scaled Agile Framework® are trademarks of Scaled Agile Inc. which publishes detailed documentation of the framework on its website www.scaledagile.com.