A Program Increment (PI) starts with a time-boxed PI Planning event in which the Agile Release Train is responsible for planning & delivering incremental value in the form of working, tested software and systems. This is a two-day event where all stakeholders (including Agile/Scrum Teams) on the Agile Release Train (ART) participate in a collocated event. All teams have their own areas set up for their planning together with a Program Area with a Program Board to map Feature delivery and dependencies across teams. PI is usually 8 – 12 weeks long. A well-executed PI Planning session ensures alignment, transparency, and collaboration across teams, setting the stage for a successful Program Increment.
Purpose: The purpose of PI Planning is to create an emergent roadmap to deliver a prioritized and agreed set of outcomes as well as identify both known and potential impediments to progress. The goal is to align business owners and program teams on a common, committed set of Program Objectives and Team Objectives for the next release (PI) time-box.
Aligning Teams: Ensuring that all Agile Release Trains (ARTs) understand the priorities, objectives, and dependencies for the upcoming PI.
Building Plans: Collaboratively creating plans for the PI, including defining objectives, estimating work, and identifying cross-team dependencies.
Enhancing Collaboration: Fostering communication and collaboration among teams, stakeholders, and product owners to ensure a shared understanding of goals.
Goals: The primary purpose of release (PI) planning is to gain alignment between business owners and program teams on a common, committed set of Program Objectives and Team Objectives for the next release (PI) time-box.
Features: Have clear, simple, well-written business-oriented and valuable features rather than Features describing a technical solution.
PI Planning Inputs (Pre-Work)
Product backlog features are prioritized & ranked.
Business review of each feature completed
Technical analysis done, feasibility established, architecture and solution understood, enabler features identified.
Features ranked (for example using WSJF) – single common stack for the entire program
Features sufficiently defined to support release planning and estimation.
PI Planning Process Steps
Mapping: Features elaborated into user stories
Sizing: Stories estimated (to +/- 20%) via bulk estimation
Scheduling: Initial allocation of stories to sprints, taking into account team velocities and dependencies.
Release scope set based on velocity and target release date.
Consolidated release plan showing feature completion dates.
PI Planning Outputs
Release scope defined for next time-box
The team better comprehends the objectives for the whole PI.
A shared understanding of what it takes to release
Program risks reviewed and actions identified to solidify the plan
Release objectives reviewed and scored by business stakeholders
Team and program confidence vote on the plan
Collective ownership of the plan
Day 1: Creating Draft Plans
Business Context: This is an update given by upper management or a business on how the business is doing and how well they are keeping up with the market and consumer needs.
Vision: This is the overall business vision and objectives, but also the vision for the upcoming PI. At the beginning of PI Planning, the vision will be presented by Product Management or a senior business sponsor for the Agile Release Train.
Architectural Runway: Understanding the architectural implications of upcoming Features is important to ensure that the teams have an understanding of the underlying architectural approach and system constraints that they have to work within. Systems Architect or IT department will outline the systems and architecture vision for improvements to the infrastructure that will help to improve the time to market and may impact development during the coming PI.
Planning Context & Lunch: The Release Train Engineer (RTE) outlines how the PI planning process will work and what is expected from the teams and the overall meeting.
Team Breakouts: Teams will gather around the boards to estimate their velocity for each iteration and look over their backlogs and what will need to be brought forward to support the features outlined in the vision.
Draft Plan Review: This is a time-boxed meeting where the teams present their draft plans so that business owners, product owners, stakeholders, and other teams can give feedback.
Management Review and Problem-Solving: In most cases, the draft plans will bring up issues with architecture, scope, and people and resource constraints. These issues can sometimes only be solved by management renegotiating scope and possible features.
The program Backlog should be sufficiently refined to support story writing and sizing. Each team will first create draft plans & these plans include 3 basic things: a feature delivery timeline, a set of PI Objectives, and a risk assessment.
Create Stories from Features: Known as Story Mapping – taking a set of features and breaking each one down into small slices of functionality that can be delivered in a single iteration. At this stage, it is not necessary to refine the story to the extent that it will meet the definition of ready. This refinement can be done as part of the backlog refinement process.
Capture the end-to-end user process flow. Consider these as functional steps or ‘features’.
Start defining potential actions the user will take to accomplish each function. These can be considered the ‘user stories’.
Story Size Estimates: estimation by linear affinity. This method is good for generating initial estimates for large Product Backlogs, e.g. for PI Planning. Stories not necessarily fully defined (Ready). Teams place stories in buckets of relative size: XS, S, M, L …, or Fibonacci: 1,2,3,5,8,13 … (Recommended)
Story
& Feature Scheduling: In this step allocate stories to sprints by
taking into account story size (in points) and team velocity (points per
iteration).
Identify Risks and Dependencies: Dependencies constitute a risk in that they represent items the team has no direct control.
Align
Team Deliverables with Program Objectives: It gives teams the
opportunity to validate with stakeholders that they have clearly understood the
intent and priorities defined for the PI in terms of business value.
This step is about assigning overall business value to the PI.
The intent of this exercise is to summarize the PI in terms of meaningful business objectives and to confirm alignment between teams and stakeholders. Features deliver benefits that are aligned with business goals.
Business stakeholders circulate and score the team’s objectives, assigning a ‘business value’ between 0-10, where 10 represents the highest business value. Each team starts with their most valuable PI Objective as a ’10’, then all remaining PI Objectives are scored relative to that first 10. BV can be scored as relative within the team, or relative to the overall train.
At the next PI planning event, following the PI demos, business stakeholders will rate objectives based on what was actually achieved – this data is the basis of the Program Predictability Metric. (Pass out a printed list of PI objectives with original rankings to the stakeholders with an additional column for actuals).
Leadership review & problem-solving: The leadership team will work on the following questions:
What have we learned so far?
Where do we need to adjust: Vision, Scope, People?
Where are the bottlenecks?
What features must be de-scoped, or deferred?
Are decisions needed before tomorrow?
Day 2: Make Adjustments and Finalize Plans
The leadership team will announce any required
changes to feature priorities and team changes.
The overall agenda for the day will look like this:
Program adjustments from leadership review – priorities, scope changes, people movements.
Teams adjust & finalize plans
Stretch objectives setting
Teams identify remaining issues needing help from an outside team
Business stakeholders circulate to review plans and score PI Objectives
Team-level confidence votes.
Program wall-board: Feature delivery timelines by the team.
The team plans collected to the front of the room, risks ROAM’ed, program confidence vote.
Event retrospective.
Program Adjustments – The day begins with any adjustments or decisions made by management and stakeholders in the problem-solving meeting.
Team Breakouts 2– Plan Adjustments to incorporate changes in priorities, scope, and people moves into their plans. This will include any scope changes and feature delivery timelines, updating the team’s list of risks, and potentially revising the team’s list of program objectives. Identify any ‘stretch objectives’ and add them to their list of program objectives.
Scoring PI Objectives – Business value is assigned to each objective (scored 1-10). Formulate objectives by thinking about the problems being solved for the user (Better, Faster, Cheaper, and so on). Think of features as being the solutions to those problems. Features have specific benefits for the user, and these are usually traceable back to an epic ‘value statement’ and from there back to at least one of the strategic themes identified for the business.
ROAM’ing exercise on their list of risks
R: Resolved. The team has resolved (or knows how to resolve) the risk.
O: Owned. The teams decide to ‘own’ the risk, that is, they will take responsibility to work to resolve the risk on their own without needing to escalate for help.
A: Accepted: The team accepts the risk as something that is ‘part of life’, or part of the cost of doing business.
M: Mitigated: The team believes they can take specific actions to reduce the impact of the risk.
Program Wall Board Update
The Program Wall Board represents the consolidated feature delivery timeline from all teams. It is used to provide a consolidated summary of feature completion dates, enabler items, dependencies, and major program milestones.
Program Confidence Vote
It is a Fist-of-Five vote from all team members. Any vote less than 3 should be explored and commitments potentially reworked until all team members vote at least a 3.
PI Planning Event Retrospective
It can be as simple as a 2-column table drawn on a whiteboard or flip-chart with a column for ‘what went well’ and another for ‘needs improving’. A Dot Voting exercise can be done to identify the issues most important to the gathered teams.
Benefits of PI Planning
Establishing face-to-face communication among all team members and stakeholders
Matching demand to capacity, eliminating excess Work in Process (WIP)
Fast decision making
Best Practices for PI Planning
Here are some best practices for PI planning:
Involve the entire team: PI planning should involve the entire agile team, including product owners, scrum masters, developers, testers, and any other stakeholders involved in the development process. This helps to ensure that everyone is on the same page and that all perspectives are taken into account.
Set clear goals and priorities: It is important to set clear goals and priorities for the upcoming program increment. This helps to ensure that everyone is working towards the same objectives and that the most important work is prioritized.
Use a visual planning tool: Using a visual planning tool, such as a Kanban board or Gantt chart, can help to make the planning process more efficient and effective. It provides a clear picture of the work to be done and helps to identify dependencies and potential issues.
Break down work into small, manageable pieces: Breaking down the work into small, manageable pieces, such as user stories, helps to make it more manageable and easier to estimate. It also allows for more frequent feedback and course corrections.
Estimate effort and capacity realistically: It is important to estimate the effort required to complete each item realistically and to take into account the team’s capacity to complete the work within the timeframe of the program increment.
Plan for contingencies: It is important to plan for contingencies, such as unforeseen issues or delays, to ensure that the team is able to stay on track and meet its goals.
Establish clear communication channels: Clear communication channels should be established to keep everyone informed throughout the increment. This includes regular check-ins, progress reports, and open communication channels for addressing issues or concerns.
Keep the planning session focused: PI planning can be a long process, so it is important to keep the team focused and avoid distractions. This can be achieved by setting clear objectives, managing the agenda, and encouraging active participation from all team members.
Align with the organization’s strategy: The goals and priorities set during PI planning should align with the organization’s overall strategy and objectives. This helps to ensure that the work being done is driving the organization toward its larger goals.
Plan for learning and improvement: PI planning should include a focus on learning and improvement. This can be achieved by setting goals for experimentation, incorporating feedback from customers or users, and regularly reflecting on the team’s performance and processes.
Involve stakeholders: PI planning should involve key stakeholders, such as customers or users, to ensure that their needs are taken into account during the planning process. This can help to improve the quality of the work being done and increase stakeholder satisfaction.
Continuously refine the plan: The plan created during PI planning should not be set in stone. It should be continuously refined and adjusted based on new information or feedback from the team or stakeholders. This helps to ensure that the team is always working towards the most important objectives and that they are able to adapt to changing circumstances.
Frequently Asked Questions
Who are the participants of PI Planning?
All the teams of the Agile Release Train, Scrum Masters, Product Owners, Developers, Stakeholders, Business owners, Suppliers, Users, & Customers.
Who conducts the PI Planning session?
The Release Train Engineer (RTE) is at the front of facilitating the PI Planning session and ensures that a seamless and smooth PI session is done.
What are the Challenges of PI Planning?
PI Planning does have its huge benefits but at the same time, it can have some challenges. Some of them are listed below:
Complexity: PI Planning involves coordinating multiple teams within an ART, each with its own objectives, dependencies, and priorities. This complexity can make it challenging to develop a cohesive plan that meets everyone’s needs.
Time Constraints: PI Planning is a time-boxed event, typically lasting two days. This compressed timeframe can make it difficult to discuss and plan for all the work that needs to be done.
Communication: Effective communication is essential during PI Planning, but it can be challenging to ensure that everyone is on the same page, especially when dealing with a large number of people and complex dependencies.
Resistance to Change: Some team members may be resistant to change, which can create friction during the planning process and impede progress.
Lack of Prioritization: Without clear prioritization, teams may struggle to focus on the most critical work during PI Planning, leading to inefficiencies and delays.
Dependencies: Identifying and managing dependencies between different teams and features can be challenging and time-consuming, especially when there are many interdependencies to consider.
What is the difference between a PI Roadmap and a Solution Roadmap?
A PI Roadmap provides an overview of the Program Increment, which typically lasts for ten weeks. It outlines the objectives, milestones, and deliverables for each team within the ART (Agile Release Train) for the upcoming PI. The PI Roadmap is developed during PI Planning and provides a high-level view of the work that will be completed during the PI.
PI Roadmap is created before your PI Planning event and also reviewed and updated by Product Management after the event is finished. It will usually cover three Program Increments:
The current increment (work that’s committed)
The next forecasted increment (planned work based on forecasted objectives)
The increment after that (further planned work based on forecasted objectives)
On the other hand, a Solution Roadmap provides a long-term view of the solution, typically covering 12-24 months or more. It outlines the overarching goals and objectives for the solution, including the features, enablers, and capabilities that will be delivered over time. The Solution Roadmap is developed during the Solution Management process, which is responsible for defining and managing the solution vision, roadmap, and backlog.
In summary, a PI Roadmap focuses on the upcoming PI and provides a detailed plan for the next 10 weeks, while a Solution Roadmap focuses on the long-term vision of the solution and outlines the features and capabilities that will be delivered over a more extended period.
What is Post PI Planning?
Post-PI Planning takes place subsequent to the completion of PI Planning by all the ARTs for the following increment. During this stage, the teams present their plans, clarify their aims, and communicate important milestones and anticipated schedules. Post-PI Planning session ensures that you have a finalized set of PI Objectives that have to be implemented, and all the expected dates and milestones for delivering the final increment. These are mapped onto a physical or a Digital Solution Board.
The Release Train Engineer explains and discusses the objectives, dependencies, impediments, and risks of the PI. Risks are identified and mitigated, using the ROAM technique. If there are any aspects of the planning session that are left or not clearly understood, then a Rework Session is held to review the plan with the Agile Release Train.
Similar to PI Planning events, Post-PI Planning employs a planning board. However, instead of features, it lists capabilities, dependencies, and milestones for each iteration and ART. Any possible issues and risks are recognized, deliberated, and addressed by either taking ownership, resolving them, accepting them, or minimizing their impact. Plans undergo a first-of-five vote of confidence to ensure they align with the solution’s objectives, much like regular PI Planning events. The plans are reworked until the attendees’ average confidence level is three fingers or more.
Benefits of Post-PI Planning
Aligns the Team: Post-PI Planning is an opportunity for the entire team to come together and review the progress made in the previous Program Increment, discuss any challenges faced, and align themselves with the upcoming goals and objectives. It ensures that everyone is on the same page and working towards the same goal.
Identifies Dependencies: During Post PI Planning, teams identify dependencies between different features, systems, and teams. This helps them to coordinate their efforts better and ensures that all the necessary components are developed in time for integration.
Promotes Transparency: Post-PI Planning promotes transparency and accountability within the team. It encourages open communication and helps to identify any issues or concerns early on, which can then be addressed promptly.
Enhances Predictability: Post-PI Planning helps to enhance predictability in the project by providing a clear plan of action for the upcoming Program Increment. This allows the team to prioritize their work and focus on delivering the most critical features first.
Facilitates Continuous Improvement: Post-PI Planning is an opportunity for the team to reflect on the previous Program Increment and identify areas for improvement. This helps them to continuously improve their processes, tools, and techniques and ensures that they are delivering value to the customer.
Conclusion
Executing a successful PI Planning event is pivotal for organizations following the SAFe framework. By following these steps and incorporating the provided tips and tricks, teams can navigate the complexities of PI Planning with confidence. This comprehensive guide aims to equip Agile Release Trains and teams with the knowledge needed to achieve alignment, collaboration, and success in their Program Increments.