Mastering SAFe PI Planning

What is SAFe PI Planning?

PI Planning (Program Increment Planning), a regular event in SAFe, orchestrates Agile teams to envision shared objectives, devise strategic roadmaps, manage dependencies, and strengthen collaboration, aligning team efforts with overarching business goals.

PI Planning (Program Increment Planning), a cornerstone event in the Scaled Agile Framework (SAFe), harmonizes Agile teams’ efforts with a shared business vision. It’s a collaborative endeavor in which teams collectively define objectives and establish a roadmap for the next 8-12 weeks. This includes identifying interdependencies and coordinating to navigate them effectively. It also entails proactive risk management to mitigate potential pitfalls. Critically, the planning exercise embraces adaptation and continuous improvement, allowing revisions based on new insights and feedback. Consequently, PI Planning drives alignment, boosts collaboration, and fosters accountability, setting the stage for synchronized execution across the Agile Release Train (ART).

What is the purpose of PI Planning?

PI Planning aligns all teams on the Agile Release Train towards common objectives for the next Program Increment.

The main goal of PI Planning in SAFe is to establish a shared understanding and commitment toward the objectives for the forthcoming Program Increment (PI). It brings together all the Agile Release Train (ART) teams, stakeholders, and leadership to discuss, align, and plan for the upcoming PI. Teams identify and address dependencies, risks, and issues during this event, enabling efficient and effective execution. It fosters collaboration and transparency, strengthening the alignment toward the organization’s mission and vision.

In the SAFe planning process, PI Planning serves five specific purposes as follows:

1. Establishing a shared vision: During the event, teams and stakeholders work together to create a shared understanding of the objectives and priorities for the upcoming Program Increment.
2. Aligning development with business goals: PI Planning ensures a unified direction and a shared understanding of the business context, vision, and ART objectives.
3. Identifying dependencies and risks: By discussing and visualizing the work, teams can identify cross-team dependencies, potential risks, and opportunities for collaboration.
4. Providing the right balance of architecture and Lean User Experience (UX) guidance ensures that solutions are built with user needs in mind.
5. Matching demand to capacity: PI Planning helps eliminate excess Work in Process (WIP) and optimizes resource use throughout the PI.

How does PI Planning Align Teams with Portfolio Strategy?

PI Planning aligns teams with portfolio strategy by using strategic themes from Lean Portfolio Management to guide setting objectives, ensuring that all Agile Release Train efforts harmonize with overarching business goals.

While PI Planning works to synchronize teams and align them towards shared objectives, its relationship with SAFe Lean Portfolio Management (LPM) helps facilitate strategic alignment, resource allocation, governance, and risk management. This collaboration between PI Planning and LPM brings to the forefront the importance of aligning tactical execution with strategic vision.

1. Strategic Alignment through LPM and PI Planning: Strategic Themes in LPM are the backbone for business objectives connecting a SAFe portfolio to the enterprise’s overarching strategy. These themes guide Agile Release Trains (ARTs) during PI Planning, informing their objectives and ensuring their work aligns with wider business goals. This interplay forms a critical bridge between strategy formulation at the portfolio level and its execution at the program and team levels.
2. Budgeting and Resource Allocation: Financial considerations are crucial to this alignment. The LPM process provides Lean Budget Guardrails that inform how much should be invested in each value stream. During PI Planning, ARTs tailor their plans to adhere to these financial constraints, helping balance demand and capacity as per the LPM’s directives. This alignment ensures efficient use of resources and helps avoid excess Work in Process (WIP).
3. Governance and Compliance: LPM also ensures governance and compliance at the portfolio level. During PI Planning, ARTs align their work with these standards, incorporating any necessary compliance-related work into the plan for the upcoming increment. This interplay highlights the importance of regulatory compliance and governance in delivering value while mitigating associated risks.
4. Risk Management: One of the main components of PI Planning is identifying risks and dependencies. This information is crucial for LPM as it could impact strategic decision-making at the portfolio level. Therefore, through the lens of LPM, PI Planning can be viewed as a vital feedback mechanism that allows an organization to adapt its strategy based on the real-world complexities of execution.

The collaborative relationship between PI Planning and SAFe LPM is vital, aligning strategic vision with execution. This alignment enhances transparency, fosters strategic cohesiveness, and empowers teams to deliver value within the prescribed financial, regulatory, and risk parameters.

What are the objectives of SAFe PI Planning?

The objectives of SAFe PI Planning are to align Agile teams on a shared vision, create a PI roadmap, and identify dependencies and risks.

SAFe PI Planning sets out to achieve four specific objectives, and they are:

1. Align Agile Teams: SAFe PI Planning unites all Agile teams to gain consensus on a common mission and vision for the forthcoming Program Increment (PI).
2. Construct PI Roadmap: This event facilitates the development of a PI roadmap, detailing the features and capabilities projected for delivery, which offers clear guidance to all teams.
3. Identify and Manage Risks and Dependencies: PI Planning encourages detecting and handling potential risks and dependencies, ensuring smooth project progression.
4. Promote Communication and Collaboration: The planning process aids in dismantling silos and fosters improved coordination among teams, thereby enhancing overall work efficiency.

How does PI Planning Align Teams and Stakeholders?

PI Planning aligns teams and stakeholders by creating a shared understanding of goals, dependencies, and resources for the upcoming Planning Interval.

PI Planning promotes alignment by creating a venue where teams and stakeholders collaborate to create a shared understanding of goals, dependencies, and resources for the forthcoming Planning Interval. This alignment is achieved through various activities, such as presenting the business context, vision, and team breakouts, leading to forming PI Objectives (Program Increment Objectives).

Fostering an open communication environment ensures everyone is aligned regarding goals, expectations, and dependencies. Moreover, PI Planning helps identify and mitigate risks, ensuring smoother execution of projects.

What are the business benefits of PI Planning?

PI Planning increases predictability, improves alignment, reduces risks, and fosters innovation and decision-making.

PI Planning offers significant business advantages in SAFe. It enhances predictability by setting clear objectives and establishing a roadmap for the upcoming Program Increment. It promotes alignment across teams and stakeholders, ensuring a unified direction toward organizational goals. Furthermore, it mitigates risks by addressing dependencies and potential issues early. PI Planning also encourages innovation and decision-making, empowering teams to take ownership of their work and strive for continuous improvement.

By facilitating alignment, collaboration, and transparency, PI Planning contributes to seven specific business benefits:

1. Faster time-to-market: With a clear roadmap and well-defined objectives, teams can focus on delivering value quickly and efficiently.
2. Improved quality: By identifying dependencies and risks early, teams can address potential issues before they escalate, resulting in higher-quality solutions.
3. Greater adaptability: PI Planning allows organizations to respond to changing market conditions, customer needs, and priorities more effectively by regularly reassessing and adjusting their plans.
4. Enhanced stakeholder engagement: Involving stakeholders in the planning process ensures that their needs are considered and addressed, leading to better outcomes and higher satisfaction.
5. Increased predictability: By regularly reviewing progress and adjusting plans, organizations can improve their ability to forecast and manage resources, budgets, and timelines.
6. Better customer experience: Streamlined processes and alignment across the organization lead to smoother, more efficient customer experiences.
7. Faster decision-making: PI Planning brings teams together to make quick, informed decisions and prioritize tasks.

In conclusion, PI Planning is a cornerstone of the SAFe planning process. By participating in PI Planning, teams can collaborate effectively, delivering value to customers and the business.

What is a Planning Interval (Program Increment) in Scaled Agile?

A PI, or Program Increment, is a timebox during which an Agile Release Train (ART) delivers incremental value through working, tested software and systems.

Acting as a heartbeat of SAFe, the Program Increment (PI) is a set period reserved for Agile Release Trains (ARTs) to create, refine, and deliver customer value. This timebox facilitates a regular, predictable cadence of activities such as planning, execution, review, and delivery.

Generally lasting 8 to 14 weeks, a PI usually encompasses four to six iterative development cycles and concludes with an Innovation and Planning (IP) iteration. This structure ensures synchronization across Agile Teams in the ART, allowing them to consolidate their work into one or more deliverable increments. However, the design does not restrict individual teams from independently releasing value per specific situations.

PI Planning Step by Step

The PI Planning process flow involves pre-planning, a two-day planning event, and a follow-up, where teams align on objectives, plan work, manage dependencies, and commit to a Planning Interval.

The PI Planning Process comprises five overarching steps, and they are:

1 Pre PI Planning

• Program Backlog Construction & Refinement
• Portfolio epics elaborated into features.
• Features sufficiently refined to support the creation and sizing of user stories.

2 PI Planning Event

• Scope Estimation
• Features mapped into user stories
• Stories estimated in points or capacity units
• Stories scheduled into iterations
• The maximum scope of PI determined
• Feature Delivery Timeline
• Feature delivery schedule estimated to nearest iteration
• PI Business Objectives
• Teams confirm which business goals are being addressed (fully or partially) by feature deliverables.
• Stakeholders score objectives based on perceived business value
• Address program risks and dependencies
• Teams & Stakeholders Confirm Alignment on Scope & Objectives
• Program risks are assessed
• Confidence vote from teams and stakeholders

3 Finalize PI Plan

• Incorporate feedback and adjustments from the planning event
• Complete and share the final PI plan with stakeholders

4 Outputs

• Approved PI objectives and business value assignments
• Refined program backlog, including dependencies and risks
• Team and ART PI plans, including committed objectives and feature delivery timeline
• Identified risks, impediments, and mitigation strategies

5 Post PI Planning

• Conduct a planning retrospective to improve the process for future events
• Communicate the final PI plan to all stakeholders
• Initiate the execution of the PI based on the plan

What is a SAFe User Story?

User Stories are short, simple descriptions of functionality or feature told from the user’s perspective.

In SAFe, User Stories are the primary means of expressing software requirements on an Agile team. Each User Story includes a narrative that specifies the type of user, the user’s need, and why the need is important. A User Story aims to provide enough information so the development team can reasonably estimate the effort required to implement it.

What is a SAFe Feature?

Features in SAFe are services the system provides that fulfill stakeholder needs and deliver business value.

Features serve as a primary building block of the Program backlog. In the SAFe framework, a Feature usually spans multiple iterations and is developed by multiple teams. Features are an essential part of the SAFe framework, acting as a link between business hypothesis and its potential realization through the efforts of Agile teams.

What is the SAFe Requirements Model?

The SAFe Requirements Model combines Artefacts and activities that guide the creation of system solutions.

SAFe Requirements Model includes a combination of Artefacts – Epics, Capabilities, Features, and Stories, along with the corresponding activities necessary for defining and implementing a system. It’s a flexible model that can be adapted according to the needs of each organization. This model assists in breaking down large work items into manageable sizes, thus promoting incremental delivery.

PI Planning Roles and Responsibilities

The key stakeholders in PI Planning are Business Owners, the Solution Train Engineer (STE), the Release Train Engineer (RTE), Product Managers, System Architects, Product Owners, Scrum Masters, Agile teams, and other subject matter experts.

PI Planning brings together a range of different roles, each with its own unique perspective and contributions as follows:

1. Business Owners: They provide a strategic vision and influence the prioritization of features.
2. Solution Train Engineer (STE): The STE facilitates and coordinates multiple Agile Release Trains (ARTs) activities in a Solution Train.
3. Release Train Engineer (RTE): The RTE leads the Agile Release Train (ART), facilitating PI planning events and managing risks.
4. Product Managers communicate the strategic vision and roadmaps and define and prioritize features.
5. System Architects offer an architectural vision and guidance to ensure solution integrity.
6. Product Owners: They define and prioritize user stories within teams.
7. Scrum Masters: They facilitate team activities during PI planning and assist teams in delivering value.
8. Agile Teams: They estimate the effort required for user stories and commit to delivering objectives.
9. Other Subject Matter Experts: Various other experts may be involved depending on the nature of the PI, bringing their unique skills and knowledge to the planning process.

What is the role of Business Owners in PI Planning?

Business Owners influence the prioritization of features and help establish business value in PI Planning.

In PI Planning, Business Owners communicate business priorities and the vision to the rest of the team. They work with Product Managers and other stakeholders to influence the prioritization of features based on business value. Their role ensures the delivery of maximum economic benefit from the developed solution. During the planning event, they clarify business needs and support decision-making processes.

What is the role of the STE in PI Planning?

The Solution Train Engineer (STE) facilitates and coordinates multiple Agile Release Trains (ARTs) during PI Planning.

In a SAFe Solution Train context, the Solution Train Engineer (STE) plays a pivotal role in PI Planning. The STE acts as a chief Scrum Master for the Solution Train, facilitating the events and processes of PI Planning at the Solution level. This involves coordinating with all Agile Release Trains (ARTs), managing dependencies and risks, and working with suppliers and other stakeholders. By ensuring clear communication and alignment across all ARTs and stakeholders, the STE helps to steer the solution toward successful delivery.

What is the role of the RTE in PI Planning?

The Release Train Engineer (RTE) facilitates the PI Planning event, helps manage risks, and supports the Agile Release Train (ART).

The Release Train Engineer (RTE) plays a fundamental role in PI Planning. As the Agile Release Train (ART) leader, the RTE’s primary duty during PI Planning is to facilitate the event, ensuring all elements run smoothly. This includes orchestrating the activities of teams and stakeholders, enabling effective communication, and promoting a collaborative decision-making environment. The RTE also works closely with teams to identify and manage risks, facilitating problem-solving and encouraging continuous improvement throughout the PI.

What is the role of the Product Manager in PI Planning?

The Product Manager communicates the program vision and roadmap, prioritizes features, and collaborates with stakeholders during PI Planning.

Product Managers play a pivotal role in PI Planning. They primarily communicate the program vision and roadmap to the teams, setting the overall direction for the upcoming PI. Product Managers are vital in feature prioritization, ensuring alignment with the program objectives. They actively collaborate with stakeholders, including Business Owners, System Architects, and Agile Teams, to ensure shared understanding and facilitate decision-making. Their involvement in PI Planning is key to aligning team efforts with strategic goals and customer needs.

What is the role of the Systems Architect in PI Planning?

The Systems Architect provides architectural vision and guidance to ensure solution integrity during PI Planning.

The Systems Architect offers an architectural vision and guidance. Their role is to ensure that the technical aspects of the solution align with the overall architectural strategy and that the system’s integrity is maintained. They collaborate closely with Agile teams, providing guidance on design decisions, identifying significant system-level dependencies, and working to mitigate architectural risks. They also contribute to establishing the Nonfunctional Requirements (NFRs), which describe system attributes such as security, reliability, performance, maintainability, scalability, and usability.

What is the role of the Product Owner in PI Planning?

The Product Owner defines and prioritizes user stories within teams during PI Planning.

The role of the Product Owner in PI Planning is centered around defining and prioritizing user stories and ensuring alignment with the team’s goals for the upcoming Planning Interval. They work with the teams to develop and refine user stories, ensure clear acceptance criteria, and collaborate with other teams to manage dependencies. By representing the customer’s voice and focusing on delivering value, the Product Owner helps guide the team’s work throughout the planning process and beyond.

What is the role of the Scrum Master in PI Planning?

The Scrum Master facilitates team activities during PI Planning and assists teams in delivering value.

The Scrum Master plays a multifaceted role in PI Planning. As a servant leader for their team, the Scrum Master ensures that the team functions effectively during the planning event. They facilitate discussions, help remove obstacles, and work to ensure that all team members have the necessary resources to participate fully in planning. Additionally, the Scrum Master collaborates with other Scrum Masters to identify and manage cross-team dependencies and to facilitate problem-solving as issues arise. Throughout PI Planning, the Scrum Master’s role is central to fostering a productive and positive team environment.

What is the role of Agile Teams in PI Planning?

Agile teams estimate effort for user stories and commit to delivering PI objectives during PI Planning.

Agile teams are at the heart of PI Planning. They engage in various activities during the event, including understanding the vision and features, estimating the effort required for user stories, identifying risks and dependencies, and formulating their objectives for the upcoming Planning Interval. Teams work collaboratively to design their iteration plans, balancing the work across the team members and ensuring they can deliver value. By the end of the PI Planning event, each team commits to a set of PI objectives, creating a clear roadmap for the work ahead.

Who else is involved in PI Planning?

Additional stakeholders in PI Planning include subject matter experts, customers, suppliers, and other supporting roles.

PI Planning involves a broader set of participants beyond the Agile Release Train (ART) core roles. These additional stakeholders can include subject matter experts who bring specialized knowledge or technical expertise, customers or end-users who provide vital feedback and perspectives, and suppliers or partners who contribute essential components or services to the solution. Moreover, other supporting roles, such as UX Designers, QA Specialists, or Compliance Managers, might participate in PI Planning to ensure their specialized concerns are factored into the planning process. These participants contribute to a comprehensive and inclusive planning process, enhancing the quality and value of the outcomes.

Pre PI Planning

Pre PI Planning is a preparatory activity that precedes PI Planning to align leaders on vision, strategy, and backlog readiness.

Pre PI Planning is a preparatory process before the main PI Planning event in SAFe. It is an opportunity for the organization’s leadership, including Solution Management, Product Management, System and Solution Architect/Engineering, and Business Owners, to synchronize their understanding of the vision, strategy, and backlog status. The goal is to align these key stakeholders on the priorities for the upcoming Planning Interval, ensuring that the PI objectives align with the overall business objectives.

How does Pre PI Planning support the PI Planning event?

Pre PI Planning supports PI Planning by aligning key stakeholders, preparing high-level objectives, and identifying potential risks, dependencies, or architectural considerations related to the upcoming work.

Pre PI Planning is a preparatory phase that sets the stage for a successful PI Planning event. It is primarily conducted by key stakeholders such as Product Management, System Architects, RTEs, and possibly some representatives from Agile Teams. During this phase, these stakeholders align on the high-level objectives for the upcoming PI based on the strategic themes and vision. They also perform a preliminary breakdown of Features or Epics while identifying potential risks, dependencies, or significant architectural considerations.

Therefore, The Pre PI Planning phase provides a high-level vision and direction for the PI, allowing the PI Planning event to run more smoothly and effectively, with all teams starting on the same page regarding the direction and priorities for the upcoming PI.

When do you start Pre PI Planning?

Pre PI Planning generally begins during the final iterations of the current PI, although activities such as refining the architectural runway and grooming epics and features may start even earlier.

Pre PI Planning is not an isolated event that begins and ends within the last iterations of a PI. It’s a more continuous process, overlapping with the activities of the current PI. During the final iterations of the current PI, the focus on Pre PI planning intensifies as teams prepare for the next PI Planning event.

However, certain preparatory activities often start even earlier. For instance, the architectural runway needs continuous attention to support forthcoming features. This involves refining the architecture, identifying necessary infrastructure or technical enhancements, and aligning these with anticipated business features.

At the portfolio level, grooming epics, identifying potential features, and even pre-planning large solution trains can start much earlier, depending on the size and complexity of the initiatives.

The timing of these activities is not rigid but should be flexible and responsive to the ongoing needs of the development value stream. This approach helps ensure readiness for the upcoming PI while maintaining a steady flow of value delivery.

How do you conduct Pre PI Planning?

Pre PI Planning involves alignment sessions, backlog assessment, risk identification, and objective setting.

The conduct of Pre PI Planning follows a five-step approach designed to prepare the teams for a successful PI Planning event as follows:

1. Strategic Alignment: Leadership teams, including Release Train Engineers (RTEs), Product Management, and System Architects, meet to understand and align on the strategic objectives, vision, and roadmap for the upcoming Program Increment (PI).
2. Backlog Review: Product Management and System Architects review and prepare the Program Backlog. They assess the backlog items’ readiness based on the defined criteria, such as well-formed features with clear acceptance criteria and benefit hypotheses. Any adjustments are made to ensure the backlog aligns with the agreed strategic objectives.
3. Risk Identification: Potential risks, dependencies, and impediments that might impact the upcoming PI are identified. This often involves RTEs, Product Management, and System Architects.
4. Risk Mitigation Strategy: Mitigation strategies are devised to address the identified risks and impediments. The goal is to reduce the potential negative impact these could have on the upcoming PI.
5. Drafting PI Objectives: Preliminary objectives for the upcoming PI are drafted. These are based on strategic alignment, backlog readiness, and risk mitigation plans. These draft objectives are a guiding beacon for teams during the PI Planning event.

The RTE facilitates Pre PI Planning and ensures all teams are ready for the planning process.

The Release Train Engineer (RTE) is central in Pre PI Planning. They facilitate the Pre PI Planning event, guiding discussions to ensure alignment among all stakeholders. They work closely with the Business Owners, the STE, and the Product Manager to ensure that the vision, strategy, and objectives are clearly defined for the upcoming Planning Interval. They also evaluate the readiness of the Agile Release Train (ART) for the planning event, addressing any issues that may impede the process.

What is the role of Business Owners in Pre PI Planning?

Business Owners provide strategic direction and define business objectives during Pre PI Planning.

Business Owners deeply understand the business context, the market, and the organization’s strategic objectives. They contribute to the Pre PI Planning process by articulating the vision and setting the direction for the upcoming Planning Interval. Their input is crucial in defining the business objectives that the Agile Release Train (ART) will work towards. They also participate in discussions about the readiness of the backlog, helping to ensure that the planned work aligns with the business strategy.

What is Product Management’s Role in Pre PI Planning?

Product managers have six specific tasks to perform during the current PI to prepare for an upcoming PI Planning event, and they are:

1. Product Managers review market and technology trends and industry developments and align and refine the roadmap with the Product Owner.
2. Customers, stakeholders, and team feedback are gathered to refine the product vision and identify new opportunities.
3. Reviewing the product backlog with the Product Owner and development teams, prioritizing features and user stories.
4. Defining achievable objectives and goals for the upcoming PI with the Product Owner.
5. Collaborating with the Architecture team to ensure technical and architectural frameworks are in place to support planned features and capabilities.
6. Identifying dependencies and ensuring resources are available by working with other teams within the organization.

By performing these tasks during the current PI, Product Managers help ensure that the product vision and roadmap are up-to-date. It also ensures alignment with business objectives and that the necessary planning and preparation are in place for a successful PI Planning event.

What are the Architects’ Roles in Pre PI Planning?

Architects play a crucial role in the SAFe planning process, including preparing for PI Planning by focusing on the technical and architectural aspects of the product or solution. Architects have 6 specific tasks to perform during the current PI to prepare for an upcoming PI Planning event as follows:

1. Reviewing the architectural runway: Reviewing the technical framework for gaps or technical debt that need addressing.
2. Identifying technical risks: Identifying and prioritizing technical risks with the development teams.
3. Defining technical goals:  Technical objectives aligned with the product vision and roadmap.
4. Collaborating with the development teams: Collaborating with development teams to guide technical design, code quality, and architecture.
5. Preparing the technical backlog:  Preparing the technical backlog by identifying and breaking down technical epics and stories.
6. Identifying dependencies:  Identifying and ensuring necessary resources are available by working with other teams.

These tasks help ensure technical readiness for the upcoming PI, focusing on aligning technical goals with the product vision, addressing technical risks, and preparing the technical backlog.

What is the role of the Scrum Master in Pre PI Planning?

The Scrum Master in Pre PI Planning supports the team by facilitating backlog refinement.

The Scrum Master’s role in Pre PI Planning centers on assisting the Agile team in preparing for the upcoming PI Planning event. Their primary focus is facilitating the backlog refinement process, enabling the team to have a clear and well-understood backlog before the PI Planning session. The Scrum Master also ensures that potential impediments are identified and dealt with effectively, ensuring a smooth workflow. They serve as a bridge between the team and external stakeholders, promoting communication and collaboration, which in turn helps align expectations and facilitates efficient planning for the upcoming PI.

What is the role of the Product Owner in Pre PI Planning?

The Product Owner in Pre PI Planning readies the team backlog for the upcoming PI.

In the Pre PI Planning phase, the Product Owner prepares the team backlog for the forthcoming Planning Interval (PI). This task involves breaking down program backlog items into team backlog items, refining them into smaller, manageable user stories, and ensuring they are ready to be addressed during the PI. The Product Owner works collaboratively with the Product Manager and other stakeholders, drawing on their knowledge and expertise to ensure that the backlog accurately reflects the needs and priorities of the business. This preparation facilitates a smooth and efficient PI Planning event.

What is the role of SAFe Teams in Pre PI Planning?

SAFe Teams have five specific preparation activities to perform for an upcoming PI, and they are:

1. Review of the previous PI: The team reviews the results of the previous PI, including the successes and areas for improvement.
2. Evaluate the product state: The team reviews the current state of the product, including any outstanding features or issues.
3. Identification of business and technical risks: The team identifies any risks that may impact the upcoming PI.
4. Definition of PI objectives: The team establishes the objectives and goals for the upcoming PI based on the product vision and roadmap.
5. Identification of dependencies: The team identifies any dependencies between features or teams that may impact the upcoming PI.

Are user stories written before PI Planning?

Some User Stories might be prepared before PI Planning during the Pre PI Planning phase, primarily for well-understood features for which the teams and Product Management have had prior discussions.

The PI Planning Event

The PI Planning event is a two-day gathering of Agile teams to align on a shared mission and plan the next Planning Interval.

The PI Planning event is a cornerstone of the SAFe methodology. It typically spans two days and involves all the Agile teams within an Agile Release Train (ART). During this event, the teams align on a shared mission and vision, break down and estimate features, identify dependencies, commit to objectives, and plan the work for the next Planning Interval (usually 8-12 weeks). This face-to-face gathering promotes collaboration and alignment, serving as a crucial opportunity for teams to understand their roles in the bigger picture and build a shared commitment to the ART’s objectives.

What are the inputs to the PI Planning event?

Inputs to the PI Planning event include an executive briefing, product vision briefing, architecture vision briefing, and capacity and resource information.

There are four specific to prepare that will be presented during the PI Planning session to ensure a comprehensive understanding of the business landscape, product vision, and architectural direction; they are:

1. Executive Briefing: An overview provided by executives that outlines the current business context, strategic objectives, and also challenges the organization faces. This briefing sets the stage for the PI Planning event, helping participants understand the company’s priorities and focus areas for the upcoming Program Increment.
2. Product Vision Briefing(s): Prepared by Product Management, these briefings present the top 10 features in the ART Backlog, highlighting key initiatives and user needs that will drive the work during the upcoming PI. Product vision briefings should also cover any changes or updates to the product roadmap, allowing teams to align their efforts with the overall product strategy.
3. Architecture Vision Briefing: A presentation delivered by the CTO, Enterprise Architect, or System Architect that communicates new Enablers, features, and Nonfunctional Requirements (NFRs) from an architectural perspective. This briefing provides technical guidance and insights into the architectural considerations and constraints that may impact the implementing of features in the ART Backlog.
4. Capacity and Resource Information: Besides the above briefings, it’s essential to understand each team’s capacity and available resources for the upcoming PI. This information helps teams make informed decisions about what they can realistically commit to during PI Planning.

By ensuring that these inputs are carefully prepared and presented, teams and stakeholders can work together to develop a cohesive plan for the upcoming Program Increment that aligns with both the business and technical objectives.

How long is the PI Planning event?

The PI Planning session traditionally spans two full days, but the duration may be adjusted based on team distribution and remote work conditions.

PI Planning is typically an event that unfolds over two full days, designed to allow Agile teams enough time to understand the vision for the Agile Release Train (ART), discuss features, estimate effort, identify dependencies, plan work for the forthcoming Planning Interval (PI), and commit to PI objectives.

However, with the advent of COVID-19, the rise of remote work, and the increasingly global distribution of teams, organizations have had to adapt this traditional two-day format to suit their specific needs and circumstances. As such, PI Planning can be stretched over a longer period to accommodate teams working in different time zones or to compensate for the inefficiencies that can come with virtual collaboration. For instance, running the session over four half-days has become common for distributed teams, balancing focused planning time and ongoing operational work.

Furthermore, planning activities often take longer in a remote setting due to technological constraints and the lack of in-person interaction. Hence, organizations have learned to account for these delays and adjust the duration of their PI Planning sessions accordingly.

Ultimately, the length of the PI Planning session should be determined by the team’s needs, aiming to achieve the essential outcomes of the event — a committed set of PI objectives and a shared understanding of the path to achieving them.

How do you prepare for the PI Planning event?

When is PI Planning held?

PI Planning is held at the beginning of each new Planning Interval.

PI Planning marks the start of each new Planning Interval (PI) within the SAFe framework. The event takes place after the conclusion of the previous PI and the completion of the Pre PI Planning activities. This timing is pivotal because it allows Agile teams to align their objectives, plan the work for the upcoming PI, and commit to delivering specific objectives based on the previous PI’s learnings and the refined backlog.

PI Planning Agenda

PI Planning Roles and Responsibilities

The PI Planning event in SAFe involves several crucial roles, each contributing to a successful outcome. There are 7 key roles involved in PI Planning, and they are:

1. Release Train Engineer(s) (RTE): Ensures the Agile Release Train (ART) runs smoothly and involves all necessary stakeholders in the planning process. They also collaborate with the Scrum Master, Product Manager, and other stakeholders to align the planning process with the overall ART framework.
2. Product Managers: Responsible for defining the Product Vision and Roadmap and prioritizing the product backlog. They collaborate with the Product Owner and development teams to align the product backlog with business objectives.
3. Product Owners: Manages the product backlog, prioritizes features and user stories, and ensures a clear understanding of requirements by the development teams. They work closely with the Product Manager and development teams to prepare the product backlog for PI Planning.
4. Architecture Team: Establishes the technical and architectural framework to support planned features and capabilities. They also provide technical guidance and support to the development teams throughout the PI.
5. Agile Teams: Implement planned features and capabilities, collaborating with the Product Owner, Architecture Team, and other stakeholders to ensure a clear understanding of requirements and provide technical guidance.
6. Scrum Masters: Facilitates the PI planning event, ensuring smooth execution. They work with development teams and stakeholders to engage everyone in planning, share necessary information, and address potential issues or roadblocks.
7. Business Owners: Responsible for the business outcomes of the product or solution, providing guidance and feedback to the Product Manager and Product Owner, ensuring alignment with business objectives.

What is the role of the RTE in the PI Planning session?

The Release Train Engineer (RTE) facilitates the PI Planning session.

The Release Train Engineer (RTE) is the main facilitator for the PI Planning session. They coordinate the planning process, which includes managing schedules, handling logistics, and ensuring a smooth flow of information. The RTE guides various activities, including team breakouts, presentations, management reviews, and problem-solving. They are also responsible for resolving issues and impediments that may arise during the planning process.

What is the role of the Product Manager in the PI Planning session?

The Product Manager articulates the Program Vision and priorities during the PI Planning session.

The role of the Product Manager in PI Planning is crucial in setting direction and priorities. They communicate the Program Vision and priorities to Agile Teams and other stakeholders, helping them understand what features and capabilities must be developed in the upcoming PI. Their understanding of market needs and stakeholder feedback allows them to guide teams toward achieving valuable outcomes.

What is the role of the Product Owner in the PI Planning session?

The Product Owner clarifies story details and helps prioritize the team backlog in the PI Planning session.

The Product Owner is central to PI Planning, primarily clarifying story details and prioritizing the team backlog. They work closely with their team during planning and breakout sessions, ensuring that the team understands the context and details of user stories. The Product Owner also collaborates with Product Management and Business Owners to ensure alignment with overall program priorities.

What is the role of the Systems Architect in the PI Planning session?

The Systems Architect provides technical guidance and defines the Architectural Runway in the PI Planning session.

The Systems Architect plays a significant role in PI Planning, primarily providing technical guidance and outlining the Architectural Runway. They work closely with teams to help them understand the system architecture and any technical considerations that could influence their planning. They also communicate any design, technology changes, or constraints that must be considered during the PI.

What is the role of Agile Teams in the PI Planning session?

Agile Teams create and estimate user stories, define iteration goals, and identify risks in the PI Planning session.

Agile Teams are the heart of the PI Planning session, as they carry out three key activities and they are:

1. Create and estimate user stories informed by the Program Vision and backlog priorities.
2. Define iteration goals that align with the overall PI Objectives.
3. Identify dependencies and risks, participating in risk management activities.

Through all these activities, they lay the groundwork for the upcoming Planning Interval.

What is the role of the Scrum Master in the PI Planning session?

The Scrum Master aids their team in planning and removes impediments in the PI Planning session.

The Scrum Master’s role in the PI Planning session involves supporting their Agile Team throughout the planning process. They facilitate discussions, encourage collaboration, and help to clarify objectives and dependencies. If any impediments arise during the session, the Scrum Master removes or escalates them as necessary. They are instrumental in ensuring their team’s voices are heard and that they have the resources they need for effective planning.

What is the role of Business Owners in the PI Planning session?

Business Owners define the vision and provide the business context in the PI Planning session.

Business Owners play an important part in PI Planning. Their responsibilities entail defining the vision and providing the business context. This information helps Agile Teams understand the broader business objectives and how their efforts contribute to achieving these goals. Additionally, Business Owners contribute to priority-setting discussions, aligning development activities with business needs.

What is the role of the STE in the PI Planning session?

The Solution Train Engineer (STE) synchronizes multiple ARTs in a Solution Train during the PI Planning session.

Within the PI Planning session context, the Solution Train Engineer (STE) takes on a role akin to a Release Train Engineer but at a larger solution level. The STE’s task involves coordinating multiple Agile Release Trains (ARTs) that are part of a Solution Train. This synchronization process ensures alignment across ARTs and allows for collective decision-making. The STE also supports conflict resolution and encourages collaboration across ARTs to help achieve solution objectives.

How are Agile teams structured for PI Planning?

Agile teams are configured for PI Planning based on existing team structures and the needs of the upcoming Planning Interval.

Agile teams for PI Planning are generally composed based on existing team structures within the organization. However, adjustments can be made in light of the requirements of the upcoming Planning Interval. The main objective is to ensure that each team has the right mix of skills and experience to execute their portion of the PI. Typically, a cross-functional team configuration is preferred to ensure all necessary skills are available within the team to deliver value.

Do Agile team members change before PI Planning?

Agile team members can change before PI Planning to support self-organization and evolving team dynamics.

In Agile methodologies, including SAFe, stability in team composition is typically encouraged as it fosters improved communication, synergy, and performance. Over time, teams that work together tend to become more efficient and effective in their collaborations.

However, as Agile teams and Agile Release Trains (ARTs) are also self-organizing, there can be instances where changes to team composition occur before PI Planning. This can be driven by various factors, including the personal development goals of team members, the desire for exposure to different technologies or environments, or specific technical needs coming up in the next PI that require particular expertise.

These changes can be beneficial in promoting a culture of continuous learning and cross-pollination of skills within the organization.

When do Agile teams change?

Agile teams can change in response to evolving team needs and personal development goals of the team members.

Who decides which members are assigned to which Agile teams?

Agile team composition decisions involve collaborative discussions among leadership, team members, architects, and team leads.

Can Agile team members choose their teams?

In some circumstances, Agile team members can influence their team assignments.

Agile methodologies, including SAFe, highly value self-organization and individual engagement. This includes fostering an environment where team members have some level of influence over their team assignments. While team compositions are often decided by leadership considering skills, experience, and the needs of the upcoming Program Increment, the preferences and development goals of the individuals are also significant factors.

In practice, this might mean team members desiring to work in a particular team, perhaps to learn a new skill, engage with new technology, or collaborate with certain colleagues. Ideally, these desires are balanced with the needs of the organization and the Agile Release Train (ART).

It’s important to note that this doesn’t mean team members can freely choose their teams without consideration of the overall team and ART needs. The final decision generally involves a collaborative discussion with leadership, Scrum Masters, and Product Owners, ensuring that all teams are balanced and capable of delivering value in the upcoming PI.

Who presents the Product Vision?

The Product Manager presents the Product Vision during PI Planning.

In the SAFe framework, the Product Manager plays a central role in defining and communicating the Vision during the PI Planning event. They articulate the goals, objectives, and themes for the upcoming Planning Interval, ensuring alignment with the organization’s strategic objectives. By presenting the Vision, the Product Manager provides direction and clarity, helping Agile teams to understand the bigger picture and how their work fits within it.

Click here for a Product Vision Template

Who presents the Product Architecture?

The Systems Architect communicates the Product Architecture during PI Planning.

In the context of SAFe, the Systems Architect is usually responsible for communicating the Product Architecture during the PI Planning event. They present any architectural decisions, changes, or standards that affect the work in the upcoming Planning Interval. This includes the description of the technological landscape, infrastructure, and integrations needed to support the development and deployment of the product. This information is crucial for Agile teams to plan their work and make informed technical decisions.

Who defines technical standards during PI Planning?

The System Architect/Engineering team defines technical standards during PI Planning.

It’s the responsibility of the System Architect/Engineering team to define technical standards during a PI Planning event in the context of SAFe. They are proficient with the systems and technology and understand the product’s or solution’s overarching technical direction. Their knowledge and expertise enable them to establish consistent technical standards that all Agile teams can follow. They provide architectural guidance, align the system’s evolution, and contribute to the Agile Release Train’s vision during PI Planning.

What are team breakouts?

Team breakouts during PI Planning are sessions for individual Agile teams to plan their work.

In SAFe, team breakouts are integral components of the PI Planning process. Individual Agile teams retreat to separate spaces during these sessions to plan their work for the upcoming Planning Interval. Teams utilize these sessions to create objectives drafts, determine individual work items and tasks, write and estimate stories, and examine and manage dependencies. These activities help each team to solidify their plans and strategies for the PI, ensuring that they are aligned with the larger objectives of the Agile Release Train.

During the breakout sessions, teams iterate through a series of seven steps as follows:

1. Understand and Evaluate Features: Teams begin by reviewing and discussing the features that have been assigned to them. They evaluate the complexity, effort, and business value of each feature. Any queries or doubts about the features are clarified with Product Management.
2. Decompose Features into Stories: Teams break down the features into smaller, manageable user stories. These stories are then discussed in detail, including their acceptance criteria.
3. Estimate User Stories: Teams estimate the effort required to complete each user story. This is usually done using story points, which help predict the team’s capacity for the upcoming PI.
4. Create Iteration Plans: Teams plan which user stories will be completed in each iteration of the upcoming PI. This includes sequencing the user stories in the iteration backlog based on their dependencies and the team’s capacity.
5. Identify Risks and Dependencies: Teams identify any risks, dependencies, or impediments associated with the user stories. This includes dependencies within the team and those that involve other teams.
6. Create Draft PI Objectives: Based on the planned user stories and features, teams draft their PI objectives. These summarize what the team aims to achieve in the upcoming PI.
7. Confidence Vote: After creating their draft plan, the team members vote on their confidence in achieving the PI objectives. This is a quick way to gauge the plan’s feasibility and identify potential issues early on.

Who facilitates team breakouts?

The Scrum Master facilitates team breakouts during PI Planning.

The Scrum Master facilitates team breakouts during PI Planning. Leveraging their Scrum and Agile methodologies skills, they guide their respective Agile teams through planning. They encourage effective communication, ensure alignment with the Agile Release Train’s objectives, and assist in managing dependencies and mitigating risks.

Who leads the breakout sessions?

Breakout sessions during PI Planning are typically led by the Scrum Master, with active participation from all team members.

The Scrum Master usually facilitates breakout sessions during PI Planning, ensuring that discussions stay on track and all voices are heard. However, leadership in these sessions is a shared responsibility. All team members should actively participate, contribute ideas, and engage in decision-making. The Product Owner also plays a critical role, providing clarifications on feature requirements, aligning the team with customer needs, and helping to prioritize tasks. Leadership in this context is about collaborative problem-solving, shared understanding, and collective commitment.

How do you know a breakout session is going well?

Team breakouts go well with active participation, effective facilitation, clear outputs, and agreement on tasks and dependencies.

Several indicators indicate that a team breakout during PI Planning is going well. Active participation from all members signals engagement and collaboration, which is critical for shared understanding and effective decision-making. Effective facilitation, where the discussions stay on track and all voices are heard, is another positive sign. Clear outputs demonstrate progress regarding identified tasks, risks, and dependencies. Finally, agreement on the tasks and dependencies among the team members indicates consensus, an essential element for team commitment and effective PI execution.

What should the energy in the team breakout room be like?

The energy in the team breakout room should be focused, collaborative, and proactive.

During PI Planning, a productive team breakout room should exhibit focused, collaborative, and proactive energy. Participants should show focus by actively engaging with the topics at hand and minimizing distractions. Collaboration is key, with team members freely sharing ideas, asking questions, and making contributions. Proactivity should be evident in the team’s approach to problem-solving, with members willingly identifying issues and suggesting potential solutions.

What are common anti-patterns related to team breakouts?

Anti-patterns include lack of participation, dominance by certain individuals, inadequate facilitation, and lack of commitment to decisions.

Four common anti-patterns can derail the effectiveness of team breakouts during PI Planning, and they are:

1. Lack of Participation: Teams breakouts are meant to be collaborative and highly participatory. When team members are not actively engaged or contributing, it can undermine the session’s effectiveness. This could be due to various reasons, such as lack of preparation, disengagement, or clarity about the agenda.
2. Dominance by Certain Individuals: While every voice needs to be heard, it can be detrimental if one or two individuals dominate the conversation, limiting the opportunity for others to contribute their perspectives. This could skew decisions and may not accurately reflect the team’s collective understanding and agreement.
3. Inadequate Facilitation: Good facilitation is crucial during breakouts to ensure discussions are productive, focused, and inclusive. An inadequate facilitator may struggle to manage the conversation effectively, leading to inefficient discussions or missed opportunities to leverage the team’s collective intelligence.
4. Lack of Commitment to Decisions: Once decisions are made, teams must commit to the plans crafted during the breakout sessions. A lack of commitment can lead to misalignment and decreased accountability, which can ultimately undermine the effectiveness of PI Planning.

Are user stories written during PI Planning breakout sessions?

Yes, user stories are written during PI Planning breakout sessions.

In the context of SAFe, PI Planning breakout sessions are where Agile teams construct their user stories. These stories, couched in the language of the customer or end-user, describe the desired functionality or feature. Creating these user stories promotes understanding and communication within the team, helping to shape the work for the upcoming Planning Interval.

Are user interfaces designed during team breakouts?

High-level UI sketches or mockups are created to aid the understanding of user stories.

Are user flows mapped during team breakouts?

During PI Planning, high-level user flows can be outlined to aid the understanding of user stories.

Are the Agile teams or Product Owners responsible for documenting user stories?

Agile teams, with the Product Owner, are responsible for documenting user stories.

Documenting user stories is a collaborative effort within Agile teams. While the Product Owner plays a significant role in defining the ‘what’ of a user story, the team contributes to detailing the ‘how.’ The team and the Product Owner work closely to ensure that the user story is well-understood, well-documented, and aligns with the team’s capacities and the larger objectives of the Agile Release Train.

Who identifies inter-team dependencies during PI Planning?

Agile teams identify inter-team dependencies during PI Planning.

Agile teams work together during PI Planning to identify dependencies between different teams. By recognizing these dependencies, teams can better coordinate their efforts, mitigate risks, and improve flow. Facilitated by the Scrum Master During PI Planning, Agile teams work together to identify dependencies between different teams. This collaboration aids in the following:

• Fostering open communication among teams about shared requirements or resources.
• Highlighting potential bottlenecks or conflicts that could delay delivery.
• Defining clear expectations for mutual support and synchronization.

The Scrum Master and the Product Owner both play a key role in this process, assisting their teams in understanding and documenting these dependencies effectively.

How are dependencies tracked during PI Planning?

Dependencies are tracked through a Program Board during PI Planning.

The SAFe framework uses a visual tool known as a Program Board to track dependencies during PI Planning. This board depicts the important elements of the plan, including features, timelines, and, most crucially, dependencies between teams. As teams identify dependencies, they are represented on the Program Board as lines linking the related features. This visual representation provides an overview of the dependencies within the Agile Release Train, helping teams manage and mitigate potential issues.

Who assigns business value during PI Planning?

Business Owners assign business value during PI Planning.

Within the SAFe environment, it is the Business Owners who are entrusted with the task of assigning business value during PI Planning. Their knowledge of the strategic objectives and market dynamics equips them to evaluate the potential value of each PI objective. The Business Owners express this value in relative terms, assigning each objective a score. This scoring process helps prioritize work, guides resource allocation, and enhances economic decision-making throughout the PI.

Are user stories sized during PI Planning?

Yes, user stories are sized during PI Planning.

Sizing user stories is a fundamental activity in PI Planning. During this event, teams engage in detailed discussions and collaborate to estimate the complexity and effort required for each user story. This process helps understand the work involved and aids in effective planning and resource allocation for the upcoming Planning Interval.

Who sizes user stories during PI Planning?

The Agile teams size the user stories during PI Planning.

In the context of PI Planning, the responsibility of sizing user stories falls on the Agile teams. Each team utilizes its collective knowledge, expertise, and past experiences to gauge the relative effort and complexity of implementing each user story. This collective estimation process fosters a shared understanding among team members and promotes ownership of the work.

How are user stories sized during PI Planning?

User stories are sized during PI Planning using story points.

Agile teams typically employ estimation techniques such as story points or T-shirt sizing when sizing user stories during PI Planning. In the story points method, the relative complexity of user stories is quantified numerically.

How do you size stories during PI Planning?

Techniques such as Planning Poker, T-Shirt Sizing, and Bucket Systems support the story sizing process during PI Planning.

To support the story sizing process during PI Planning, Agile teams often use a combination of estimation techniques:

• Planning Poker: In this technique, each team member makes an individual estimate using a deck of cards with values corresponding to the story points. This prompts discussion, consensus, and an ultimate agreement on the size.
• T-Shirt Sizing: This technique uses size-based categories (S, M, L, XL) to classify the user stories based on their perceived complexity and effort.
• Bucket System: This approach involves grouping user stories into predefined-size buckets. The team then compares the stories within these buckets to validate their relative size.

How do you manage dependencies during PI Planning?

Why is the confidence vote held at the end of the PI Planning event?

The confidence vote is held at the end of PI Planning to assess the team’s conviction in their finalized PI objectives and plans.

Conducting the confidence vote after the PI Planning event ensures that team members are voting with a comprehensive understanding of the PI objectives, plans, and potential challenges. After thorough discussions, problem-solving, and planning, teams are in a better position to evaluate their confidence in the feasibility and success of the PI. Hence, the vote signifies the closure of the planning event, underlining the team’s collective commitment.

The systems demo in PI Planning demonstrates the integrated system built during the PI.

The “systems demo” is an integral event where the working system, built and integrated during the PI, is demonstrated. It allows Agile teams, Product Owners, and stakeholders to inspect the increment of value delivered. The demonstration includes new features, capabilities, and potentially even non-functional requirements like performance and security improvements, providing a tangible insight into the progress made during the PI.

What is the PI Retrospective in PI Planning?

The PI Retrospective is a session in PI Planning to reflect and learn from the previous PI.

The PI Retrospective is a dedicated session within PI Planning wherein teams reflect on the past Planning Interval. This exercise is an opportunity for Agile teams to identify what worked well, what didn’t, and what could be improved in the next PI. It is grounded in continuous improvement, fostering a learning culture that drives performance and quality enhancement.

How is the PI Retrospective structured?

The PI Retrospective follows the “What Went Well? What Didn’t? What to Improve?” structure.

The structure of the PI Retrospective commonly revolves around three key questions:

• What Went Well?: Identifying and acknowledging the successes and effective practices of the last PI.
• What Didn’t Go Well?: Reflecting on challenges, obstacles, and areas of underperformance in the previous PI.
• What Can We Improve?: Formulating improvement strategies for the upcoming PI based on the reflections and learnings from the above points.

This structure encourages teams to maintain and build upon their strengths, learn from their shortcomings, and devise actionable plans for enhancement.

What happens during the PI Retrospective?

During the PI Retrospective, teams review the previous PI’s successes and challenges and formulate improvement strategies.

In the PI Retrospective, teams collaboratively reflect on the performance of the past Planning Interval. It involves a structured discussion to dissect what went well, where the team faced difficulties, and, most importantly, how to improve in the forthcoming PI. The dialogue isn’t limited to technical aspects but extends to team collaboration, communication, and process efficiency. The goal is to foster a continuous learning culture and enhance team performance and product quality in subsequent PIs.

Who facilitates the PI Retrospective?

The Release Train Engineer (RTE) typically facilitates the PI Retrospective.

The PI Retrospective is typically led by the Release Train Engineer (RTE). As a servant leader and coach for the Agile Release Train (ART), the RTE encourages open dialogue and constructive feedback among teams. They help teams identify strengths and areas of improvement and guide the discussion toward actionable improvement strategies for the forthcoming PI.

What processes are used during the PI Retrospective?

The PI Retrospective typically involves reflection, discussion, and the creation of action plans.

The PI Retrospective follows a structured process that begins with reflecting on the past PI. It’s a collaborative and open dialogue where teams discuss their successes, challenges, and opportunities for improvement. This process involves the following steps:

1. Reflection: Teams identify what worked well, what didn’t, and where they faced challenges.
2. Discussion: Teams engage in a thorough discussion to dissect these aspects and understand the reasons behind the outcomes.
3. Action Planning: Based on these insights, teams formulate strategies and plans for improvement in the next PI.

What is done with the recommendations of the PI retrospective?

Recommendations from the PI Retrospective are translated into actionable improvement plans for the next PI.

The findings and recommendations of the PI Retrospective serve as a roadmap for continuous improvement. They are translated into actionable strategies and plans teams commit to implementing in the next Planning Interval. These may involve processes, communication, tooling, or teamwork changes to enhance team performance and product quality.

Who attends the PI Retrospective?

The Agile teams, Product Owners, RTE, and other key stakeholders attend the PI Retrospective.

The PI Retrospective is a collaborative event that includes all Agile teams, Product Owners, and the Release Train Engineer (RTE). In addition, key stakeholders, such as architects and business owners, may also participate in offering their perspectives and insights. The goal is to foster a culture of shared learning and continuous improvement, hence the importance of involving all parties contributing to the PI.

Do business users attend PI retrospectives?

While not mandatory, business users can attend PI Retrospectives to provide valuable feedback.

Business users, while not an obligatory part of the PI Retrospective, can be invited to participate. Their involvement provides a unique perspective and valuable feedback on the business value delivered. Their user experience and product utility insights can guide the teams toward enhancing product value in subsequent PIs.

Do product managers attend PI retrospectives?

Yes, Product Managers typically attend PI Retrospectives.

Product Managers are generally key participants in PI retrospectives. As part of the larger Agile Release Train (ART), their input can provide invaluable insights into the challenges and successes experienced during the PI from a product perspective. They can assist in identifying systemic issues or opportunities that may be beyond the scope of individual teams but significantly impact the overall product delivery. Their presence also reinforces the importance of shared learning and continuous improvement across all levels of the organization.

Do Agile Teams attend PI retrospectives?

Yes, Agile Teams are key participants in PI retrospectives.

Agile Teams play a central role in PI Retrospectives. These meetings allow them to share their experiences, challenges, and suggestions from the last Planning Interval. Their first-hand insights on technical and collaboration issues are crucial in designing strategies for continuous improvement in the following PI.

Do Architects attend PI retrospectives?

Architects can attend PI retrospectives to provide technical insights and guidance.

While it is not obligatory, the involvement of Architects in PI Retrospectives can prove valuable. They can offer critical technical insights and guidance, helping teams understand and improve upon technical challenges faced during the past Planning Interval. Architects can also help align technical improvement strategies with the architectural vision and guidelines.

Does the plan get reworked at the end of PI Planning?

The plan is refined based on feedback and confidence votes at the end of PI Planning.

The PI Planning event’s culmination is not typically about reworking the plan completely. Instead, it involves refining the plan based on insights, feedback, and the confidence vote results. Adjustments may be made to align the plan with business goals better, address potential risks, and manage dependencies. This fine-tuning ensures that the Planning Interval plan is realistic and achievable and that all teams are confident in its execution.

When does the plan get reworked?

The plan gets reworked during the planning process as new insights emerge and in response to the confidence vote.

The PI plan undergoes iterative refinement during the planning process itself. As teams identify dependencies, risks, or constraints, they adjust and rework their plans. Another important point for potential adjustments is the confidence vote. Suppose the confidence vote reflects low confidence in the plan. In that case, it signals the need for further discussion and potentially reworking the plan to address concerns and ensure a mutual commitment to the finalized plan.

Who is involved in the plan rework?

Plan rework involves all Agile Teams, the RTE, Product Management, and Business Owners.

Reworking the plan is a collaborative effort that brings together all Agile Teams, the Release Train Engineer (RTE), Product Management, and Business Owners. Each group brings a unique perspective: Agile Teams understand the intricacies of execution, the RTE ensures alignment with the Agile Release Train (ART), Product Management provides product vision guidance, and Business Owners clarify business objectives.

How long does the plan rework take?

The duration of plan rework varies, but it usually takes a few hours.

The length of the plan rework process is not fixed, as it’s contingent on the complexity of issues identified during PI Planning. It could range from a few hours to potentially a full day. It’s important to remember that the goal is to ensure everyone commits to a clear, feasible plan, regardless of the time it takes.

How many times can the plan rework be repeated?

Plan rework can be repeated as many times as necessary to gain consensus.

There isn’t a set limit on the number of times a plan can be reworked. The aim is to create a consensus-driven plan that all Agile Teams are confident in executing. Therefore, if new information, obstacles, or opportunities emerge, it warrants reconsideration and potential plan rework.

What are the outputs of the PI Planning event?

Outputs of PI Planning include committed PI Objectives, a final Program Board, and a Risk Management plan.

1. Committed PI Objectives: These are a set of SMART objectives that the teams agree to deliver by the end of the PI, including business value assigned by the business owners.
2. Uncommitted PI Objectives: These are stretch objectives that the teams will try to deliver but are not part of the team’s commitment.
3. Program Board: This visual representation of the ART’s delivery timeline captures the features to be delivered, relevant dependencies, and milestones across iterations.
4. Risk Management Plan: This involves strategies to address identified risks and dependencies.
5. PI Confidence Vote: A measure of confidence from all team members in achieving the PI objectives, voted on at the end of the PI planning event.
6. Vision for the Next PI: While primarily focused on the immediate upcoming PI, planning also includes a look ahead to what might be in the next PI.
7. Planning Retrospective and Action Items: PI Planning concludes with a brief retrospective where attendees identify what went well, what didn’t, and what can be done better next time.

Distributed PI Planning

Can PI Planning be done virtually or with distributed teams?

Yes, PI Planning can be conducted virtually.

With technological advancements and the growth of remote work trends, PI Planning has adapted to be fully executable in a virtual environment. Using various tools and software, Agile teams can collaborate effectively, maintain open lines of communication, and align on goals and objectives. The principles of transparency, collaboration, and adaptability remain at the core of these virtual PI Planning sessions.

How do you organize a distributed PI Planning event?

Organizing a virtual PI Planning event involves selecting the right tools, planning the agenda, enabling collaboration, and ensuring clear communication.

• Choose the appropriate digital tools: Tools for video conferencing, digital whiteboarding, and task management are essential.
• Draft a detailed agenda: A well-structured agenda provides direction and maintains focus.
• Facilitate virtual breakouts: This enables teams to work independently on specific tasks and return to share with the larger group.
• Clear communication: Establish guidelines for effective online communication to minimize misunderstanding and ensure everyone’s participation.

How do you structure the agenda for a distributed PI Planning event?

For distributed PI Planning with distributed participants, the agenda can be adjusted to span four days, allowing for timezone differences and slower coordination.

Day 1 Agenda:

1. Business Context: A Business Owner or senior executive presents the current state of the business, portfolio vision, and how existing solutions address customer needs.
2. Product/Solution Vision: Product Management presents the current vision and any changes since the previous PI planning event.
3. Architecture Vision and Development Practices: The System Architect presents the architecture vision and any Agile-supportive changes to development practices.

Day 2 Agenda:

1. Planning Context: The RTE presents the planning process and expected outcomes.
2. Team Breakouts #1: Teams estimate capacity, identify backlog items, create draft plans, and add features and dependencies to the ART Planning Board.
3. Draft Plan Review: Teams present key planning outputs, which Business Owners, Product Management, and stakeholders review.

Day 3 Agenda:

1. Management Review and Problem-solving: The RTE facilitates a problem-solving meeting to address challenges and make planning adjustments.
2. Planning Adjustments: Management changes the planning scope, people, and resources.
3. Team Breakouts #2: Teams continue planning, finalize their objectives, and in addition, Business Owners assign business value to identified PI Objectives.

Day 4 Agenda:

1. Final Plan Review: All teams present their plans, stating risks and impediments, and address any concerns from Business Owners.
2. ART PI Risks: Risks and impediments identified by teams are addressed in a broader management context.
3. Confidence Vote: Teams vote on their confidence in meeting their team PI objectives, and any concerns are voiced and addressed.
4. Plan Rework (if necessary): Teams adjust their objectives until they have high confidence.
5. Planning Retrospective and Moving Forward: The RTE leads a brief retrospective for the PI planning event, capturing what went well and what didn’t. They also identify areas for improvement.

10 Practical Strategies for Effective Distributed PI Planning

Despite the challenges, it’s crucial for organizations adopting SAFe to develop strategies for effectively carrying out PI planning with remote participants. Here are ten practical strategies to ensure a successful virtual PI Planning event:

1. Leverage Technology: Utilize video conferencing tools, virtual whiteboards, and collaboration platforms to facilitate real-time communication and collaboration among team members, regardless of their location.
2. Time Zone Considerations: Plan the event to accommodate various time zones, ensuring all participants can actively contribute to discussions and decision-making.
3. Flexible Event Schedule and Process Flow: Adjust the schedule and process flow to ensure that all teams have ample time to engage, collaborate, and make decisions without feeling rushed or overwhelmed. This may require extending the event over three, four, or even five days to accommodate different time zones and the slower pace of remote collaboration.
4. Clear Communication: Establish guidelines for effective communication and use visual aids to ensure all attendees easily understand the information.
5. Designated Facilitators: Assign facilitators at each location to manage discussions, address questions, and ensure remote participants stay engaged and involved.
6. Regular Breaks: Schedule frequent breaks during the planning event to allow participants to rest, engage in informal conversations, and maintain their focus and energy throughout the session.
7. Co-locate Teams When Possible: Co-locate teams as much as possible to enhance face-to-face collaboration rather than having everyone tune in from their remote locations.
8. Record the Event: Record the entire PI Planning event to allow team members who couldn’t attend or need a refresher to catch up on the discussions and decisions.
9. Adapt the Agenda: Be prepared to adapt the standard PI Planning agenda to fit multiple time zones or other unique circumstances.
10. Establish Ground Rules: Communicate when it’s acceptable to talk and when teams need to use the mute button to prevent noise and interference.

4 Tools and Platforms for Distributed PI Planning

Virtual PI Planning utilizes video conferencing for real-time communication, virtual whiteboards for collaborative visualization, collaboration platforms for team connectivity, and cloud-based program boards for immediate visibility and interaction.

1. Video Conferencing Platforms: Tools like Zoom, Microsoft Teams, or Google Meet are essential for virtual PI Planning events. These platforms allow participants to connect via video and audio in real time, facilitating effective communication and collaboration.
2. Virtual Whiteboards: Tools like Miro or Mural provide a virtual workspace for participants to visualize their plans, share ideas, and collaborate on tasks.
3. Collaboration Platforms: Tools like Slack, Microsoft Teams, or Google Workspace offer team chat and file-sharing capabilities that help teams stay connected and organized throughout the PI Planning event.
4. Cloud-based Program Boards: Using cloud-based tools like Jira, Rally, or VersionOne for program boards ensures that all participants have immediate visibility and can interact with the information in real-time.

Remember to set up, test, and introduce these tools to all participants before the PI Planning session to ensure a smooth experience. Additionally, provide training and tech support to help team members get up to speed with the tools and address any technical issues that may arise during the event.

How is PI Planning facilitated with Miro?

Miro facilitates PI Planning by providing an interactive, collaborative whiteboarding platform for visualizing plans and tracking progress.

Miro’s digital whiteboard enables Agile teams to visualize their work, draft plans, and collaboratively engage in real-time. It provides templates for story mapping, sprint planning, and retrospective sessions. The intuitive interface and range of tools support all stages of PI Planning, from the initial draft to the final review.

How is PI Planning facilitated with Mural?

Mural supports PI Planning with its visual collaboration space for brainstorming, mapping, and tracking.

With Mural, teams can brainstorm, design workflows, and collaborate on plans using a shared visual workspace. It offers templates for Agile planning and user story mapping. Virtual sticky notes, flowcharts, and diagrams help visualize PI objectives, dependencies, and progress.

How is PI Planning facilitated with Jira?

Jira facilitates PI Planning by offering a platform for task tracking, issue management, and progress reporting.

Jira’s features include creating user stories, planning sprints, and distributing tasks across teams. Teams can track their tasks, manage dependencies, and update their progress, providing real-time visibility to all stakeholders. It also supports integration with other tools, enhancing its utility for PI Planning.

How is PI Planning facilitated with Jira Align?

Jira Align supports PI Planning by providing enterprise-level tracking, visibility, and alignment of Agile initiatives.

Jira Align offers an enterprise-level perspective of all Agile work across the organization. It aids PI Planning by aligning team objectives with business strategy, offering real-time visibility into progress, and helping to manage dependencies. It ensures alignment from team-level work to strategic objectives.

What are common challenges and solutions to distributed PI Planning?

Navigating through a virtual PI Planning event comes with its own set of challenges. Below, we’ve highlighted common issues and provided practical solutions to help ensure a successful planning experience.

• Maintaining the Human Experience: Foster community and shared understanding among team members. Encourage informal conversations, empathy, and a sense of team identity and purpose.
• Managing Face-to-Face Interaction: Utilize video conferencing tools and encourage participants to use their cameras. Consider co-locating teams when possible.
• Navigating Time Constraints: Schedule the event to accommodate various time zones and potentially extend the event over several days. Prioritize agenda items and utilize time management techniques.
• Handling Slow Pace of Remote Collaboration: Adapt the PI Planning agenda to fit the slower pace of remote collaboration and adjust the schedule for various time zones.
• Preventing Boring Sessions: Keep sessions engaging and interactive with astakeholdctive discussions, breaks, multimedia content, storytelling, and real-life examples.
• Addressing Ineffective Communication: Establish communication guidelines, use visual aids, and assign facilitators at each location to manage discussions.
• Ensuring Accessibility for All Participants: Provide easy access to relevant information, tools, and resources and offer necessary training and support.
• Managing Technical Issues: Choose reliable tools, provide tech support throughout the event, and conduct a pre-event technical check to address potential issues.
• Improving Inefficient Tools and Processes: Adopt efficient tools and processes that support remote collaboration. Regularly review and update them, provide training and support, and encourage continuous improvement by seeking participant feedback.

How do you maintain the Human Experience?

• Solution: Foster a sense of community and shared understanding among team members.
• Provide opportunities for informal conversations and bonding activities.
• Encourage empathy and psychological safety within the team, and create a sense of team identity and purpose.

How do you manage Face-to-Face Interaction during virtual PI Planning?

• Solution: Utilize video conferencing tools to simulate face-to-face interaction.
• Encourage participants to use their cameras.
• Co-locate teams as much as possible by setting up regional headquarters or smaller meeting hubs.

How do you manage time constraints during PI Planning?

• Solution: Schedule the event to accommodate various time zones and constraints.
• Consider extending the event three to five days to allow ample time for everyone to engage and collaborate.
• Prioritize agenda items and allocate sufficient time for the most important topics.
• Use timeboxing and time management techniques to keep the event on schedule.

How do you manage the slow pace of remote collaboration during PI Planning?

• Solution: Adapt the PI Planning agenda to fit the slower pace of remote collaboration.
• Adjust the schedule and process flow to accommodate different time zones and ensure sufficient time for engagement and decision-making.

How do you address boring PI Planning Sessions?

• Solution: Keep sessions engaging and interactive.
• Encourage participants to contribute to discussions and ask questions actively.
• Break up long sessions with shorter breaks or energizing activities.
• Leverage multimedia content, storytelling, and real-life examples to keep participants engaged.

How do you address ineffective communication during PI Planning events?

• Solution: Establish guidelines for effective communication.
• Use visual aids to support understanding.
• Assign facilitators at each location to manage discussions, address questions, and ensure remote participants stay engaged and involved.

How do you ensure accessibility for all PI Planning participants?

• Solution: Make all relevant information, tools, and resources easily accessible.
• Offer training and support for team members who may not be familiar with the tools used during the event.

How do you manage PI Planning technical issues?

• Solution: Select reliable tools for video conferencing, collaboration, and virtual program boards.
• Ensure all participants have access to these tools and are familiar with their use.
• Provide tech support throughout the event and have a backup plan in case of technical issues.
• Conduct a pre-event technical check to identify and address potential issues.

Inefficient Tools and Processes

• Solution: Identify and adopt efficient tools and processes that support remote collaboration.
• Regularly review and update the tools and processes used to ensure they continue to meet the team’s needs.
• Provide training and support to help team members make the most of the tools and processes in place.
• Encourage continuous improvement by seeking participant feedback on the tools and processes used during the event.

By addressing these common challenges with practical solutions, you can create a successful and productive virtual PI Planning event that promotes collaboration, decision-making, and alignment across Agile Release Trains.

What are common PI Planning anti-patterns?

Common PI Planning anti-patterns include lack of preparation, ignoring dependencies, underestimating capacity, and neglecting retrospectives.

Several patterns can undermine the efficacy of PI Planning sessions. These include:

• Lack of Preparation: Entering a PI Planning session without preliminary work or clear objectives can cause confusion and waste time.
• Ignoring Dependencies: Failing to identify and address cross-team dependencies can lead to obstacles during the implementation phase.
• Underestimating Capacity: Overloading teams with unrealistic work expectations can result in burnout and missed objectives.
• Neglecting Retrospective: Skipping retrospective meetings at the end of a PI means losing valuable feedback and learning opportunities.

Post PI Planning

After PI Planning, teams execute the plan and continuously inspect and adapt their approach.

Upon concluding the PI Planning event, Agile Teams execute the agreed-upon plan. This involves developing the planned features and components, conducting iterations, and delivering value increments. Teams also participate in continuously inspecting and adapting their approach, refining their practices based on real-world feedback and evolving circumstances.

What is the PI Planning Report?

The PI Planning Report is a document summarizing the outcomes of the PI Planning event.

The PI Planning Report is an essential artifact that outlines the key results of the PI Planning event. It encapsulates objectives, team plans, identified risks, and dependency mappings. The report provides a clear snapshot of the decisions made during the planning event and sets the direction for the upcoming Planning Interval.

Who writes the PI Planning Report?

The Release Train Engineer (RTE) typically compiles the PI Planning Report.

The responsibility of drafting the PI Planning Report often falls on the Release Train Engineer (RTE). Having a broad view of the ART and direct involvement in PI Planning, the RTE collects inputs from Agile Teams, Product Management, and Business Owners to assemble this comprehensive document.

What goes into the PI Planning Report?

A PI Planning report typically includes the PI objectives, team plans, identified risks and dependencies, and any unresolved issues or concerns.

A PI Planning report serves as a comprehensive record of the outcomes of the PI Planning event. Key elements of this report usually include:

1. PI Objectives: A detailed list of the objectives set for the upcoming Planning Interval, often scored for business value and including any associated business hypotheses.
2. Team Plans: A summary of the plans from each Agile team for the upcoming PI, often represented visually on a Program Board that shows features and dependencies.
3. Risks and Dependencies: An overview of identified risks and dependencies, often with an associated ROAM (Resolved, Owned, Accepted, Mitigated) status for each risk.
4. Unresolved Issues and Concerns: Any issues or concerns raised during the event could not be addressed within the PI Planning time frame.
5. Retrospective and Improvements: Insights from the retrospective of the previous PI and agreed-upon improvements to be implemented in the next PI.

This report is a critical tool for ongoing tracking and management during the PI, and it promotes transparency and alignment within and outside the Agile Release Train.

Who receives the PI Planning Report?

Agile Teams, Product Management, Business Owners, and other stakeholders receive the PI Planning Report.

Distribution of the PI Planning Report is wide-ranging to ensure visibility and alignment. Agile Teams need to understand the overarching plan and their role in it. Product Management uses it to align team efforts with the broader product strategy. Business Owners review it to ensure their business objectives are being addressed. Other stakeholders, such as Architects, may also receive the report to understand the Agile Release Train (ART) direction for the next Planning Interval (PI).

What is the Solution Level Plan?

The Solution Level Plan is a larger-scale plan integrating multiple ARTs and suppliers towards a common objective in SAFe.

The Solution Level Plan operates above the ART in the SAFe hierarchy. It integrates the efforts of multiple Agile Release Trains and suppliers working towards the same Solution. This plan captures the broader strategy, dependencies, and risks that emerge when multiple ARTs work together to deliver complex, large-scale solutions.

Who reviews the Solution Level Plan?

Solution Management, Solution Architects/Engineering, and relevant Agile Teams and Suppliers review the Solution Level Plan.

Due to the breadth of the Solution Level Plan, it is scrutinized by several groups. Solution Management and Solution Architects/Engineering oversee the strategy and technical alignment of the plan. Agile Teams and suppliers, who are integral to its execution, also review the plan to ensure they understand their responsibilities and how their work contributes to the larger Solution. The Solution Train Engineer (STE), analogous to the RTE at the Solution Level, facilitates this review process.

Can the Solution Level Plan be updated after PI Planning?

The Solution Level Plan can be adjusted after PI Planning.

While it’s true that the Solution Level Plan can be modified following PI Planning, this is generally done only under certain circumstances. A primary purpose of PI Planning is to establish a stable set of objectives for the upcoming Planning Interval (PI). However, the realities of development and business environments mean adjustments may sometimes be necessary. If key assumptions change or if new insights are gained that substantially affect the plan, updates can be made. It’s important to note that such modifications should be cautiously approached to avoid undermining the stability and predictability that PI Planning aims to establish.

What is the PI Roadmap?

The PI Roadmap is a visual timeline of the planned PIs and features.

The PI Roadmap is an important tool in the SAFe framework that presents a chronological depiction of the planned Planning Intervals (PIs) and their associated features. It provides an overview of what features are planned for implementation during each PI. The Roadmap helps teams visualize the trajectory of their work and aligns all stakeholders by providing a shared understanding of what the organization is building and delivering. It includes the current PI and forecasts for future PIs, enabling strategic planning and setting appropriate expectations.

Who draws up the PI Roadmap?

With input from Product Management and System Architects, the RTE draws up the PI Roadmap.

In the SAFe framework, the responsibility for creating the PI Roadmap primarily lies with the Release Train Engineer (RTE). However, it’s a collaborative effort involving contributions from several roles. Input from Product Management is crucial for providing information about the features planned for future PIs. The System Architects also contribute by ensuring the technical aspects align with the architectural runway. This collective input helps the RTE draw up a PI Roadmap that effectively visualizes the trajectory of upcoming work and aligns all stakeholders.

Who maintains the PI Roadmap?

The RTE maintains the PI Roadmap.

In SAFe, the RTE is responsible for maintaining the PI Roadmap. This involves:

• Regular updates: The roadmap may need adjustments as development progresses and objectives evolve. The RTE ensures it remains an accurate reflection of the plan.
• Coordination with teams: The RTE liaises with Agile Teams, Product Management, and System Architects to ensure that the roadmap accurately represents the plan and any changes.
• Communication with stakeholders: The RTE uses the roadmap to inform all stakeholders about the progress and any shifts in direction.

What is the difference between a PI Roadmap and a Solution Roadmap?

A PI Roadmap focuses on a single Agile Release Train (ART), while a Solution Roadmap covers multiple ARTs or a Solution Train.

• PI Roadmap presents the planned features for a specific Agile Release Train (ART) over multiple PIs. It’s a visual tool that helps teams and stakeholders understand the direction of the ART’s efforts and serves to align their activities.
• Solution Roadmap: This goes a level above and provides an overview of the planned features for a Solution Train, which can encompass multiple ARTs. It’s used when several ARTs are working together on a larger solution. The Solution Roadmap assists in coordinating the efforts of different ARTs and aligns them toward common solution objectives.

Program Increment Roles and Responsibilities

Key stakeholders in the PI include the RTE, Business Owners, Product Management, System Architects, and Agile Teams.

SAFe identifies five critical stakeholders in a Planning Interval (PI) and they are:

1. Agile Teams: These are the people doing the work, developing the features planned for the PI.
2. Release Train Engineer (RTE): This person facilitates the PI Planning event and maintains alignment throughout the PI.
3. Product Management: They define the vision and roadmap and prioritize features for the teams.
4. System Architects define the technical direction, ensuring the work adheres to the architectural runway.
5. Business Owners: They influence the process by providing inputs from a business perspective and reviewing the outcomes of each PI.

What is the role of Business Owners during the PI?

Business Owners influence the PI by providing input, reviewing outcomes, and participating in “Inspect and Adapt” events.

Business Owners in SAFe play a multifaceted role during a PI:

• They provide inputs before and during PI planning, helping to prioritize features based on business value.
• They review and provide feedback on the team’s plans and objectives during the planning process.
• Business Owners participate in the Inspect and Adapt event at the end of each PI, helping review outcomes and participating in problem-solving workshops to improve the system.

What is the role of the STE during the PI?

The STE, or Solution Train Engineer, facilitates Solution PI Planning and aligns the Solution Train.

The STE coordinates and aligns all the ARTs in a Solution Train. Their responsibilities include:

• Leading and facilitating the Solution PI Planning event, where all the ARTs of a Solution Train synchronize their work.
• Maintaining alignment and dependencies between the ARTs.
• Coordinating with the Solution Management, Solution System Architect/Engineering, and Suppliers.
• Communicating with stakeholders and escalating impediments.

What is the role of the RTE during the PI?

The RTE facilitates the PI Planning, aligns the Agile Release Train, and removes impediments.

The RTE is a servant leader who is responsible for:

• Facilitating the PI Planning event and other key meetings.
• Helping to align the teams in the Agile Release Train, ensuring they work toward the common objectives set during PI planning.
• Ensuring the PI execution is on track by managing risks and dependencies and removing any impediments the teams might face.
• Communicating with stakeholders, escalating impediments, and helping to manage risk.

What is the role of the Product Manager during the PI?

The Product Manager defines the Agile Release Train’s vision, roadmap, and features.

The Product Manager plays a pivotal role in a PI:

• They are responsible for defining the vision and roadmap for the Agile Release Train, ensuring it aligns with the overall strategy.
• They prioritize features based on value to the business, considering input from stakeholders, customers, and Agile teams.
• During PI Planning, the Product Manager presents the vision and roadmap and works with the teams to define their objectives.

What is the role of the Systems Architect during the PI?

The Systems Architect defines the architectural runway and provides technical guidance.

The Systems Architect/Engineer provides technical leadership throughout a PI:

• They define and extend the Architectural Runway, which guides the teams’ work
• They define and extend the Architectural Runway, which guides the teams’ work.
• During PI planning, they guide system design, non-functional requirements, and technical enablers.
• They work with the Agile teams, RTE, and Product Management to ensure the implementation aligns with the defined architecture.
• The Systems Architect/Engineer collaborates with the Solution and Enterprise Architect to ensure alignment with the larger organizational strategy.

What is the role of the Product Owner during the PI?

The Product Owner’s role in the PI is to ensure team backlog readiness and to detail its contents.

The Product Owner is central in PI planning. They manage the team backlog, ensuring it is well organized, prioritized, and detailed with precise user stories. With this clear backlog, teams can estimate and plan the work. Product Owners collaborate with stakeholders to understand their needs and translate them into actionable work items, and they communicate these requirements to the team, clarifying any ambiguities.

What is the role of the Scrum Master during the PI?

The Scrum Master in the PI is responsible for facilitating the team’s events and assisting in obstacle removal.

The Scrum Master has a multifaceted role during PI planning. They act as facilitators during team breakout sessions, guiding discussions and helping to identify potential obstacles. They aim to ensure the smooth execution of planning activities and provide support in tackling any blockers. Scrum Masters also play a role in coordinating dependencies and risks with other teams and fostering a collaborative environment for problem-solving.

What is the role of Agile Teams during the PI?

Agile Teams are responsible for creating, estimating, and committing to user stories in the PI.

The Agile Teams have a critical role in PI planning. They generate user stories, estimate their effort, and commit to what will be delivered. Agile Teams also identify and communicate dependencies and risks. They participate in team breakout sessions to discuss and plan their work, and they present their draft plans in a team breakout review for feedback from other teams and stakeholders.

How are dependencies tracked and managed during the PI?

Dependencies are tracked and managed during the PI via visual aids like program boards and coordination with other teams.

During PI planning, teams identify dependencies between each other and external entities. These are visually displayed on a program board, clearly showing connections and potential bottlenecks. Managing these dependencies involves active team coordination, facilitated by roles like the Scrum Master and RTE. Regular sync-ups and a proactive approach toward risk mitigation help ensure dependencies do not become obstacles to progress.

Who manages and tracks dependencies during the PI?

The RTE, Scrum Masters, and Agile Teams collectively manage and track dependencies during the PI.

The management and tracking of dependencies in PI planning is a collaborative process. The RTE has an overarching view, looking for cross-team and cross-program dependencies. Meanwhile, the Scrum Masters aid their respective teams in managing dependencies within their scope. Lastly, Agile Teams are directly involved in identifying and tracking their dependencies, proactively communicating with other teams as necessary.

How are risks managed during the PI?

Risks in the PI are managed by identifying, assessing, and addressing them through a ROAM board.

Risk management during the PI follows a structured process. Teams identify risks and communicate them transparently. These are documented and assessed based on impact and probability, typically with the help of a ROAM board. ROAM stands for Resolved, Owned, Accepted, and Mitigated. Risks are categorized into these four quadrants, visually representing where each risk stands. Based on this, teams work together to address the risks – resolving, owning, accepting, or mitigating them.

Is the ROAM board used during the PI?

The ROAM board is used during the PI to manage and visualize risks.

The ROAM board is a fundamental tool in PI planning, offering a way to manage and communicate risks effectively. Based on their current status, it’s a visual aid that categorizes risks into four groups – Resolved, Owned, Accepted, and Mitigated. Using the ROAM board encourages team transparency and collaboration, leading to proactive risk management.

Who maintains the ROAM board during the PI?

The RTE, with input from Agile Teams and Scrum Masters, maintains the ROAM board during the PI.

The RTE typically leads the ROAM board’s upkeep during PI planning. They ensure the board accurately represents the current state of identified risks. However, it’s a collaborative tool, so Agile Teams and Scrum Masters actively contribute. Teams bring forward new risks or changes to existing ones, and these updates are reflected on the ROAM board. This collective maintenance ensures everyone stays on the same page about risks.

Who owns the risks during the PI?

Risks during the PI are owned by the teams or individuals who have accepted them on the ROAM board.

When risks are categorized on the ROAM board during PI planning, ownership is assigned. Teams or individuals take responsibility for handling specific risks based on their expertise, capacity, or relevance to their work. They commit to resolving, owning, accepting, or mitigating these risks. Thus, the ‘owners’ of risks have been responsible for addressing them during the PI.

What is the difference between a Sprint and an Iteration?

In SAFe, Sprint, and Iteration are synonymous, referring to a timeboxed period for developing a deliverable value increment.

Within the SAFe framework, the terms “Sprint” and “Iteration” are often used interchangeably. Both represent a specific, time-boxed period during which Agile teams work to produce a potentially shippable value increment. Typically, this period lasts about two weeks, though it can vary depending on the team’s processes and the nature of the work. Whether a Sprint or an Iteration, this period forms Agile work’s fundamental rhythm or cadence within a SAFe environment.

What is the difference between a Program Increment and a Planning Interval?

There’s no difference between a Program Increment and a Planning Interval; it’s purely a name change implemented by SAFe in 2023.

In 2023, SAFe updated the terminology from “Program Increment” to “Planning Interval.” Despite the change in terminology, the concept and structure remain exactly the same. Like the Program Increment, the Planning Interval is a time-boxed planning and execution cadence, typically lasting 8-12 weeks, used by Agile Release Trains (ARTs) in SAFe.This name change appears to be a move away from the term “program,” possibly to emphasize the focus on iterative planning and execution rather than on the program-level organization. Regardless of the terminology, the intention remains the same: to align teams, manage risk, and create a sustainable rhythm of delivery that brings tangible value to the end customer.

How long are iterations in a PI?

Iterations within a PI in SAFe are typically two weeks long, although some organizations use a different length.

In the SAFe framework, an Iteration is a timeboxed period during which an Agile team works to produce a potentially shippable value increment. These Iterations within a Planning Interval (PI) are typically two weeks long. However, the duration can vary depending on an organization’s specific needs and the nature of the work. Regardless of the precise length, each Iteration represents an opportunity for teams to plan, develop, review, and adapt their work, fostering continuous improvement and delivering value incrementally.

Can you have different sprint lengths during a PI?

No. SAFe requires consistent sprint lengths for predictability and alignment within a Planning Interval (PI). This is true for all iteration-based Agile methodologies.

While the SAFe framework offers flexibility in many aspects, uniformity is typically recommended regarding the duration of sprints or iterations within a Planning Interval (PI). Maintaining consistent sprint lengths fosters predictability, rhythm, and alignment, essential for efficient execution and effective planning. Changing sprint lengths and mid-PI could lead to misalignment between teams, disrupt the rhythm, and introduce unpredictability, impeding the value delivery process.

How many iterations are in a PI?

A Planning Interval (PI) in SAFe typically comprises four to six development iterations and an Innovation and Planning (IP) iteration.

In the standard structure of the SAFe framework, a Planning Interval (PI) generally consists of four to six development iterations, followed by an Innovation and Planning (IP) iteration. The IP iteration serves dual purposes: it provides buffer time to absorb any variability or unpredictability that might have occurred during the PI and offers dedicated time for innovation, continuing education, and strategic planning.

The combination of development iterations with the IP iteration creates a robust structure, enabling teams to deliver incremental value regularly, interspersed with feedback and adjustment cycles to ensure alignment with goals and objectives. Adding the IP iteration also ensures organizations maintain a sustainable pace, stimulate innovation, and plan for future PIs effectively.

How many days are in a SAFe PI?

40 to 60 business days. A Planning Interval (PI) in SAFe typically spans 8 to 12 weeks, equating to 40 to 60 business days.

In the SAFe framework, a Planning Interval (PI) usually extends across 8 to 12 weeks. A standard five-day working week translates to approximately 40 to 60 business days. The duration of a PI includes both planning and execution, with the number of business days typically divided into four to six iterations for execution, plus a couple of days set aside for PI planning. However, the exact number of days can vary based on an organization’s unique needs and the nature of the work.

How many days are in a SAFe iteration?

10 business days. An iteration in SAFe typically lasts two weeks, equating to 10 business days.

Within the SAFe framework, an iteration, commonly called a sprint in some Agile methodologies, traditionally lasts two weeks or approximately 10 business days. This span of time provides a consistent rhythm for teams to plan, develop, review, and adapt their work, promoting a continuous cycle of learning and improvement. The two-week timeframe offers a balanced compromise between allowing sufficient time for meaningful work to be completed and ensuring frequent checkpoints for feedback and adjustment.

How are iterations configured in a PI?

Iterations in a PI are set up sequentially, usually consisting of four to six development iterations followed by one Innovation and Planning (IP) iteration.

The configuration of iterations within a Planning Interval (PI) in SAFe is sequential and regular, promoting predictability and rhythm. A PI typically comprises four to six iterations to develop user stories or features. Following these development iterations, there is usually one Innovation and Planning (IP) iteration. The IP iteration serves a dual purpose: It provides time for innovation, continuous learning, and technical exploration, and it also affords a buffer to ensure that the teams can comfortably complete their committed objectives and prepare for the next PI.

What is an Innovation and Planning Iteration?

The Innovation and Planning (IP) iteration is dedicated to innovation, continual learning, and planning for the next Planning Interval (PI).

In the SAFe framework, an Innovation and Planning (IP) iteration is a unique iteration that does not focus on delivering user stories or features but is devoted to innovation, relentless improvement, and planning activities. The “Innovation” part encourages teams to explore creative solutions, conduct experiments, or work on technical spikes. The “Planning” component allows teams to prepare for the upcoming PI Planning event. This break from routine development work allows teams to catch their breath, deal with unpredicted events, and drive innovation.

Can you use Kanban in a PI?

What is Dual-track Agile?

Dual-track Agile is a development methodology combining discovery and delivery tracks to explore customer needs and develop solutions concurrently.

Dual-track Agile is an Agile product development approach that concurrently runs two parallel tracks—Discovery and Delivery. The two tracks work together, enabling efficient and effective product development.

1. Discovery Track: This is the exploratory track, where new ideas, user needs, and possible solutions are explored and defined. Techniques such as user interviews, prototyping, and usability testing are often used in this track to gain insights and validate hypotheses. The discovery track is typically less structured and can effectively employ the Kanban methodology due to the nature of its tasks.
2. Delivery Track: This is where identified and validated user needs are translated into shippable increments of a product. The delivery track follows a more structured approach, usually Scrum or similar iterative methodologies, with distinct iterations or sprints.

In the Dual-track Agile approach, these two tracks are not sequential but are run in parallel. The outputs of the discovery track feed directly into the “delivery track,” ensuring a continuous flow of validated, ready-to-build features for the development teams. This approach allows teams to explore, validate, and understand user needs and potential solutions before committing significant development resources, resulting in more efficient use of resources and higher quality outputs.

Can you use eXtreme Programming (XP) in a SAFe?

SAFe incorporates Extreme Programming (XP) practices for software quality and responsiveness.

SAFe has integrated Extreme Programming (XP) principles and practices into its framework, contributing to several areas of focus, such as ‘Built-in Quality’ and ‘Agile Product Delivery’ in the following ways:

1. Test-Driven Development (TDD): TDD is an XP practice wherein a test is written before the code. It is a core part of the ‘Built-in Quality’ competency in SAFe, ensuring the code functions as expected from the onset, reducing defects and making it easier to maintain and refactor code over time.
2. Pair Programming: XP’s pair programming practice is another way to enhance ‘Built-in Quality’. It involves two developers working together on the same code. It’s an effective way to share knowledge, improve code quality, and reduce errors.
3. Continuous Integration: This XP practice of integrating and testing code frequently is part of the ‘Continuous Delivery Pipeline’ in SAFe. It helps detect and fix integration issues early, leading to better software quality and faster delivery.
4. Refactoring: XP’s refactoring improves the code’s structure without changing functionality. It’s integral to maintaining ‘Technical Agility,’ a part of the ‘Team and Technical Agility’ competency in SAFe.

Close Collaboration and Customer Involvement: XP emphasizes working closely with customers to understand their needs and deliver value. This aligns with SAFe’s ‘Customer Centricity and Design Thinking,’ an aspect of the ‘Agile Product Delivery’ competency. SAFe and XP are highly compatible, and XP practices enrich SAFe’s ability to deliver high-quality software rapidly and responsively.

How does quality work during the PI?

Quality in a PI is ensured by incorporating Built-In Quality practices throughout all stages of development, adhering to the Definition of Done, and continuous validation and verification activities.

In a SAFe Planning Interval (PI) context, quality isn’t treated as an afterthought or separate phase; instead, it’s ‘built in’ from the beginning. This ‘Built-In Quality principle is achieved by following rigorous standards and practices at every stage of development. Teams must adhere to a clear ‘Definition of Done’ for each user story and feature, typically meeting functional and non-functional requirements such as performance, security, and usability. Throughout the PI, validation activities like user acceptance testing and verification activities such as automated unit testing and integration testing are continually performed to ensure the product or service meets its quality goals. Regular Inspect and Adapt sessions provide further opportunities for quality improvements by reflecting on performance and identifying areas for process enhancement.

What is SAFe DevOps?

DevOps can and should be integrated into a PI to ensure continuous delivery and quality.

DevOps practices can be—and are recommended to be—incorporated within a Planning Interval. Integrating DevOps within a PI promotes a culture of continuous integration, continuous delivery, and automation. This integration can help ensure quality, reducing the time to market and facilitating quicker feedback loops. Moreover, the automation of routine tasks can increase productivity and reduce the chances of manual errors. In essence, DevOps practices can significantly augment the effectiveness of a PI.

What are SAFe Value Streams?

SAFe Value Streams identify the activities needed to deliver value to the customer through a product or service.

In SAFe, two types of value streams are identified: Operational and Development. Operational Value Streams are the steps that an organization uses to deliver the product or service to the customer. In contrast, Development Value Streams represent the organization’s steps to develop new products or services, underpinned by Agile Release Trains (ARTs).

What is SAFe Continuous Delivery?

Continuous Delivery practices can be applied within a Planning Interval (PI) to ensure a smooth and rapid flow of value to the end users.

SAFe encourages the implementation of Continuous Delivery within a Planning Interval (PI). This involves an established set of practices and automated processes that aim to reduce the cycle time between when a change is introduced and when it’s delivered to the end users. By leveraging automated testing, continuous integration, and continuous deployment, teams can reliably release updates anytime, improving responsiveness to feedback and enhancing customer satisfaction.

Comparing Agile Planning Methods

Different types of Agile Planning, including PI Planning, Sprint Planning, and Rolling Wave Planning, share the principle of iterative planning but differ in scope, duration, and focus.

Agile planning methods like PI, Sprint, and Rolling Wave Planning share common elements. They all embody the Agile principle of iterative planning, continuous feedback, and adaptation. However, they differ in scope, duration, and focus:

1. PI Planning: Every 8-12 weeks, PI Planning is a large-scale planning event that includes all teams on an Agile Release Train. It focuses on creating a shared vision and aligning team objectives for the upcoming Planning Interval.
2. Sprint Planning: A more focused event occurs at the start of each Sprint (typically every 2-4 weeks), where individual teams detail the work to be done during the Sprint.
3. Rolling Wave Planning: An approach that involves planning for the near term in detail while leaving future work to be elaborated as more information becomes available. It balances the need for a long-term vision with the ability to adapt to changes.

What are the disadvantages of traditional Planning methods?

Traditional planning methods can be rigid, slow to adapt, and fail to promote cross-functional collaboration.

Traditional planning methods often prove rigid, leading to challenges in adapting quickly to changing market conditions. These methods usually follow a top-down approach, leaving little room for teams to adapt to changes or innovate. Moreover, traditional planning doesn’t always promote cross-functional collaboration, which can lead to siloed thinking and ineffective communication. This lack of flexibility and collaboration can lead to inefficiencies, missed opportunities, and slower time-to-market, undermining a business’s competitiveness in the rapidly evolving market landscape.

SAFe and PI Planning

The SAFe Framework is a method for scaling Agile practices across large organizations, where PI Planning is a key event for synchronizing all Agile teams on a shared mission.

The SAFe Framework is an industry-standard methodology that scales Agile practices across large organizations. Within this framework, PI Planning is an important event in the SAFe cadence that helps to synchronize all teams within an Agile Release Train (ART) on a shared mission. It lays the foundation for ARTs to plan, commit, and execute a set of business features over the upcoming Planning Interval. Therefore, PI Planning is the heartbeat of SAFe, facilitating alignment, collaboration, and delivery predictability.

Is SAFe Agile?

Yes, SAFe is Agile, as it implements Agile principles on an enterprise scale.

While it’s accurate to say that SAFe is indeed Agile, it’s crucial to understand that SAFe applies Agile methodologies to an expanded context, specifically designed for large-scale businesses and corporations. Rooted in Agile principles, SAFe scales these principles and practices, making them applicable to the enterprise level. This includes concepts like iterative development, cross-functional teams, regular retrospection, and adaptive planning. SAFe uniquely enables synchronization across multiple Agile teams, which allows for coordinated strategic direction and execution. Therefore, rather than viewing SAFe as a departure from Agile, it’s more apt to consider it an extension of Agile, crafted to cater to the complexities and needs of larger organizations.

Is PI Planning Agile?

PI Planning is decidedly Agile, emphasizing iterative development, small work increments, and adaptability during a PI, all with lean planning investment.

PI Planning, at its core, promotes Agile working methods by focusing on iterative development, breaking down tasks into manageable increments, and maintaining inherent flexibility to adjust priorities throughout a PI. An agile approach encourages adaptability and flexibility. PI Planning adopts the same principles. PI Planning is lightweight and is used more as a roadmap that can change based on circumstances. Furthermore, the planning process is not overdrawn or overly complex – it adheres to the lean principle of maximizing work not done, ensuring that time is used efficiently and teams can quickly get back to producing value. In this way, PI Planning does not contradict Agile principles but reinforces them, enabling teams to plan effectively while maintaining the flexibility that Agile methodologies champion.

The SAFe configurations and PI Planning

SAFe configurations are variations of the SAFe framework to suit different organizational needs, and all configurations incorporate PI Planning for alignment and synchronization.

SAFe configurations are adaptations of the SAFe framework designed to meet diverse organizational needs based on size, complexity, and specific business objectives. There are 4 SAFe configurations, and they are:

1. Essential SAFe: This is the foundational level of the Scaled Agile Framework that provides the basic elements needed for teams to align on strategy, collaborate effectively, and deliver complex, multi-team solutions.
2. Large Solution SAFe: This configuration extends Essential SAFe to address the challenges faced when multiple Agile Release Trains are needed to deliver large-scale solutions that typically involve coordinating multiple teams across an organization.
3. Portfolio SAFe: This configuration adds strategic and portfolio management to the Essential SAFe configuration, providing a way to align enterprise strategy with portfolio execution and manage Lean-Agile budgeting, strategic direction, and investment funding.
4. Full SAFe: The most comprehensive configuration, Full SAFe integrates all other configurations to provide a complete approach to delivering large, integrated solutions while coordinating multiple Agile Release Trains and managing portfolios at the enterprise level.

Regardless of the configuration, PI Planning remains a central event within SAFe. It allows teams to align their goals, understand dependencies, and create an achievable plan for the upcoming Planning Interval. It’s a shared experience, irrespective of the chosen SAFe configuration, and a fundamental mechanism to achieve alignment, synchronization, and delivery predictability across different levels of the organization.

The SAFe Core Competencies and PI Planning

The SAFe Core Competencies encompass seven areas vital for achieving Business Agility. They are central to PI Planning as this event aligns teams on the business strategy and execution for the upcoming Planning Interval.

The seven SAFe Core Competencies are:

1. Lean-Agile Leadership: Inspires adoption of Agile practices.
2. Team and Technical Agility: Enhances team capabilities and technical skills.
3. Agile Product Delivery: Delivers customer value through fast, integrated delivery cycles.
4. Enterprise Solution Delivery: Manages large-scale, complex solutions, incorporates guidance on coordinating trains and suppliers
5. Lean Portfolio Management: Aligns strategy and execution.
6. Organizational Agility: Enables quick, decentralized decision-making.
7. Continuous Learning Culture: Encourages innovation and improvement.

PI Planning is an essential event in SAFe that applies these competencies in a focused manner. During PI Planning, Lean-Agile Leadership fosters alignment on the shared mission and vision. Team and Technical Agility allows synchronized planning and dependency management across Agile teams. Agile Product Delivery ensures that teams plan to deliver customer value in the upcoming PI. Organizational Agility, Enterprise Solution Delivery, and Lean Portfolio Management provide the context and strategy for the work. Continuous Learning Culture helps teams retrospect and improve their planning processes for future PIs. Implementing these competencies during PI Planning contributes to overall Business Agility.

The SAFe Principles

The SAFe Principles are a set of ten fundamental principles derived from Lean and Agile methodologies that guide the implementation of SAFe.

The SAFe (Scaled Agile Framework) principles are guidelines derived from Agile practices and methods, Lean product development, and systems thinking to facilitate large-scale, complex software development projects. The ten principles that make up the SAFe framework are as follows:

1. Take an economic view: This principle emphasizes the importance of making decisions within an economic context, considering trade-offs between risk, cost of delay, and various operational and development costs.
2. Apply systems thinking: This principle encourages organizations to understand the interconnected nature of systems and components and prioritize optimizing the system as a whole rather than individual parts.
3. Assume variability; preserve options: This principle highlights the importance of maintaining flexibility in design and requirements throughout the development cycle, allowing for adjustments based on empirical data to achieve optimal economic outcomes.
4. Build incrementally with fast, integrated learning cycles: This principle advocates for incremental development in short iterations, which allows for rapid customer feedback and risk mitigation.
5. Base milestones on an objective evaluation of working systems: This principle emphasizes the need for objective, regular evaluation of the solution throughout the development lifecycle, ensuring that investments yield an adequate return.
6. Make value flow without interruptions: This principle focuses on making value delivery as smooth and uninterrupted as possible by understanding and managing the properties of a flow-based system.
7. Apply cadence, and synchronize with cross-domain planning: This principle states that applying a predictable rhythm to development and coordinating across various domains can help manage uncertainty in the development process.
8. Unlock the intrinsic motivation of knowledge workers: This principle advises against individual incentive compensation, which can foster internal competition, and instead encourages an environment of autonomy, purpose, and mutual influence.
9. Decentralize decision-making: This principle emphasizes the benefits of decentralized decision-making for speeding up product development flow and enabling faster feedback. However, it also recognizes that some decisions require centralized, strategic decision-making.
10. Organize around value: This principle advocates that organizations structure themselves around delivering value quickly in response to customer needs rather than adhering to outdated functional hierarchies.

Related Content

Mastering Lean Portfolio Management with SAFe

Lean Portfolio Management (LPM) in the Scaled Agile Framework (SAFe) is a modern approach to managing a portfolio of initiatives. It utilizes Lean-Agile thinking and Agile teams to deliver continuous value to customers. Key competencies within LPM include Strategy and Investment Funding, Agile Portfolio Operations, and Lean Governance. By…

Mastering Team and Technical Agility with SAFe

Dive into this comprehensive exploration of Team and Technical Agility - a crucial element in contemporary organizations. This blog post intricately discusses its significance, association with the Scaled Agile Framework (SAFe), and the pivotal role it plays in achieving optimal business agility. Delve into the transformation from traditional to…

Mastering Agile Product Delivery with SAFe

This comprehensive guide explores Agile Product Delivery in the context of the Scaled Agile Framework (SAFe). Through it, we delve into key aspects such as Business Agility, Customer Centricity, Design Thinking, Lean UX, and the principles of Developing on Cadence and Releasing on Demand. We further examine how to manage the Agile Release Train…

Implementing SAFe: Requirements Model (v6)

"Software development is a complex and often challenging process. As development teams grow in size, managing requirements becomes increasingly difficult. The Scaled Agile Framework (SAFe) provides a comprehensive framework for managing requirements in an Agile environment, ensuring that development efforts are aligned with the overall business…