management review and problem solving safe

Future product development tasks can’t be predetermined. Distribute planning and control to those who can understand and react to the end results. —Michael Kennedy, Product Development for the Lean Enterprise There is no magic in SAFe . . . except maybe for PI Planning. —Authors

PI Planning

Introduction to pi planning: a quick overview.

PI Planning is a cadence-based event for the entire ART that aligns teams and stakeholders to a shared mission and vision.

PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe.

Find a Course :

The Agile Manifesto states, “The most efficient and effective method of conveying information to and within a development team is a face-to-face conversation.” SAFe takes this to the next level with PI planning.

Where possible, everyone is face-to-face (virtually or physically), and these large-scale PI planning events now occur within many enterprises worldwide. They have clearly shown real financial ROI, not to mention the intangibles that happen when the team of Agile teams creates a social construct that is personally and collectively rewarding.

It may not always be practical for the entire Agile Release Train (ART) to collocate; however, in our current times, COVID-19 has created a situation where this isn’t an option. While physical face-to-face planning has benefits, the unwritten SAFe ‘rule’ is that the people who do the work plan the work. Real-time, concurrent, virtual, face-to-face planning has now proven effective when physical presence is not possible. Indeed many ARTs have been flourishing in creating a hybrid situation where several teams join remotely, as shown below in Figure 1.

The advanced topic article, Distributed PI Planning with SAFe , provides additional guidance and considerations for successfully managing these scenarios.

PI Planning has a standard agenda that includes a presentation of business context and vision , followed by team planning breakouts—where the teams create their Iteration plans and objectives for the upcoming PI . Facilitated by the Release Train Engineer (RTE) , this event includes all members of the ART and occurs within the Innovation and Planning (IP) Iteration . Holding the event during the IP iteration avoids affecting the scheduling or capacity of other iterations in the PI. PI Planning takes two days, although the ART can extend this timebox to accommodate planning across multiple time zones.

Business Benefits of PI Planning

PI planning delivers many business benefits, including:

• Establishing face-to-face communication among all team members and stakeholders
• Building the social network the ART depends upon
• Aligning development to business goals with the business context, vision, and Team and ART PI objectives
• Identifying dependencies and fostering cross-team and cross-ART collaboration
• Providing the opportunity for just the right amount of architecture and Lean User Experience (UX) guidance
• Matching demand to capacity and eliminating excess Work in Process (WIP)
• Fast decision-making

Inputs and Outputs of PI Planning

Inputs to PI planning include:

• Business context (see ‘content readiness’ below)
• Roadmap and vision
• Highest priority Features  of the ART Backlog

A successful PI planning event delivers two primary outputs:

• Committed PI objectives – Each team creates a set of SMART objectives with the business value assigned by the Business Owners.
• ART planning board – Highlighting the new feature delivery dates, feature dependencies among teams, and relevant milestones

Preparation

PI planning is a significant event that requires preparation, coordination, and communication. It is facilitated by the RTE and event attendees, including Business Owners , Product Management , Agile Teams , System and Solution Architects , the System Team , and other stakeholders. The RTE must schedule all PI planning in advance to be well prepared. The active participation of Business Owners in this event provides an essential Guardrail on budgetary spending.

For the event to be successful, preparation is required in three major areas:

• Organizational readiness
• Content readiness
• Logistics readiness

The following sections describe these three areas.

Organizational Readiness

Before PI planning, there must be strategy alignment among participants, stakeholders, and Business Owners. Critical roles are assigned. To address this in advance, however, event organizers must consider the following:

• Planning scope and context – Is the planning process’s scope (product, system, technology domain) understood? Do we know which teams need to plan together?
• Business alignment – Is there reasonable agreement on priorities among the Business Owners?
• Agile teams – Do we have Agile teams? Are there dedicated team members and an identified Scrum Master/Team Coach and  Product Owner for each team?

Content Readiness

It’s equally important to have a clear vision and context so that the right stakeholders can participate. Therefore, the PI planning must include the following:

• Executive briefing – A briefing that defines the current business context
• Product vision briefing(s) – Briefings prepared by Product Management, including the top 10 features in the ART Backlog
• Architecture vision briefing – A presentation made by the CTO,  Enterprise Architect , or System Architect to communicate new Enablers , features, and  Nonfunctional Requirements (NFRs)

Logistics Readiness

Preparing an event to support a large number of attendees isn’t trivial. This prep can include securing and preparing the space for physically collocated planning. For remote attendees or a fully distributed PI Planning, this also includes investment in the necessary technical infrastructure. Considerations include:

• Locations – Each location where planning takes place needs preparation in advance.
• Technology and tooling – Real-time access to information and tooling to support distributed planning or remote attendees
• Communication channels – Primary and secondary audio, video, and presentation channels must be available

Standard Agenda

The event follows an agenda similar to Figure 2. Descriptions of each item follow. For guidance on adapting this agenda to support planning across multiple time zones, refer to the advanced topic article, Distributed PI Planning with SAFe .

Day 1 Agenda

• Business context – A Business Owner or senior executive describes the current state of the business, shares the Portfolio Vision , and presents a perspective on how effectively existing solutions address current customer needs.
• Product/solution vision – Product Management presents the current vision (typically represented by the top ten or so upcoming features). They highlight changes from the previous PI planning event and any relevant milestones.
• Architecture vision and development practices – The System Architect presents the architecture vision. Also, a senior development manager may introduce Agile-supportive changes to development practices, such as test automation, DevOps , Continuous Integration , and Continuous Deployment , which the teams will adopt in the upcoming PI.
• Planning context and lunch – The RTE presents the planning process and expected outcomes.
• Team breakouts #1 – In the breakout, teams estimate their capacity for each Iteration and identify the backlog items they will likely need to realize the features. Each team creates draft plans, visible to all, iteration by iteration.

During this process, teams identify risks and dependencies and draft their initial team PI objectives. The PI objectives typically include ‘uncommitted objectives,’ which are goals built into the plan (for example, stories that have been defined and included for these objectives) but are not committed to by the team because of too many unknowns or risks. Uncommitted objectives are not extra things to do in case there is time. Instead, they increase the reliability of the plan and give management an early warning of any objectives that the ART may not be able to deliver. The teams also add the features and associated dependencies to the ART Planning Board, as shown in Figure 3.

• Draft plan review – During the tightly timeboxed draft plan review, teams present key planning outputs, which include capacity and load, draft PI objectives, potential risks, and dependencies. Business Owners, Product Management, and other teams and stakeholders review and provide input.
• Management review and problem-solving – Draft plans likely present challenges like scope, people and resource constraints, and dependencies. During the problem-solving meeting, management may negotiate scope changes and resolve other problems by agreeing to various planning adjustments. The RTE facilitates and keeps the primary stakeholders together for as long as necessary to make the decisions needed to reach achievable objectives.

Solution Trains often hold an additional management review and problem-solving workshop after the first day of planning to address cross-ART issues. Alternatively, the RTEs of the involved trains may talk with each other to discuss the problems for the ART’s specific management review and problem-solving meeting. The Solution Train Engineer (STE) helps facilitate and resolve issues across the ARTs.

Day 2 Agenda

• Planning adjustments – The next day, the event begins with management presenting changes to the planning scope, people, and resources.
• Team breakouts #2 – Teams continue planning and making the appropriate adjustments. They finalize their objectives for the PI, to which the Business Owners assign business value, as shown in Figure 4.
• Final plan review and lunch – All teams present their plans to the group during this session. At the end of each team’s time slot, the team states its risks and impediments and provides the risks to the RTE for use later in the ROAMing exercise. The team then asks the Business Owners if the plan is acceptable. If the plan is accepted, the team brings their team PI objective sheet to the front of the room so everyone can see the aggregate objectives unfold in real-time. If the Business Owners have concerns, teams can adjust the plan to address the identified issues. The team then presents its revised plan.
• Resolved – The teams agree that the risk is no longer a concern
• Owned – Someone on the train owns the risk since it cannot be addressed during PI planning
• Accepted – Some items are simply facts or potential problems that must be understood and accepted
• Mitigated – Teams identify a plan to reduce the impact of the risk
• Confidence vote – Once ART PI Risks have been addressed, teams vote on their confidence in meeting their team PI objectives

Each team conducts a vote using their fingers (fist of five) or a digital tool for remote events. If the average is three fingers or above, then management should accept the commitment. If it’s less than three, the team reworks its plan. Anyone voting two fingers or fewer should be allowed to voice their concerns. These concerns might add to the risk list, require replanning, or provide information. Once each team has voted, it’s repeated for the entire ART, with everyone expressing their confidence in the collective plan, as illustrated in Figure 5.

• Plan rework – If necessary, teams adjust their objectives until they have high confidence. This additional planning is one occasion where alignment and commitment are valued more highly than adhering to a timebox.
• Planning retrospective and moving forward – Finally, the RTE leads a brief retrospective for the PI planning event to capture what went well, what didn’t, and what to do better next time, as shown in Figure 6.

• Cleaning up the rooms used for planning (if applicable)
• Entering the team PI objectives and stories in Agile lifecycle management (ALM) tooling
• Reviewing team and ART events calendars
• Determining Iteration Planning and Team Sync locations and timing

After the planning event, the RTE and other ART stakeholders summarize the individual team PI objectives into a set of ART PI objectives (Figure 7) and use this to communicate externally and track progress toward the goals.

Product Management uses the ART PI objectives to refine the roadmap, improving the forecast for the following two PIs.

The ART Planning board is often used during the Coach Sync to track dependencies. It may or may not be maintained (manually) after planning is complete. A digital tool for managing dependencies facilitates their follow-up.

Teams leave the PI planning event with a prepopulated iteration backlog for the upcoming PI. They take their team’s PI objectives, iteration plans, and risks to their regular work area. ART risks remain with the RTE, which ensures that the people responsible for owning or mitigating a risk have captured the information and are actively managing the risk.

Most importantly, the ART executes the PI, tracking progress and adjusting as necessary as new knowledge emerges. Execution of the PI begins with all the teams conducting planning for the first iteration, using their PI plans as a starting point. It offers fresh input for the iteration planning processes that follow. Since the iteration plans created during PI Planning did not consider detailed story-level acceptance criteria, the team will likely adjust the first and subsequent iteration plans.

Solution Train PI Planning

This article focuses on the planning activities of a single ART. However, large Value Streams may contain multiple ARTs and suppliers. In this case, the Solution Train provides coordination using Pre-Plan and Coordinate and Deliver activities.

Last update: March 19, 2023

Privacy Overview

Ask a question

Start a discussion.

• Jira Service Desk Jira Service Management
• Jira Work Management
• Confluence Confluence
• Trello Trello

Community resources

• Announcements
• Technical support
• Documentation

Atlassian Community Events

• Atlassian University
• groups-icon Welcome Center
• groups-icon Featured Groups
• groups-icon Product Groups
• groups-icon Regional Groups
• groups-icon Industry Groups
• groups-icon Community Groups
• Learning Paths
• Certifications
• Courses by Product

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Level 1: Seed

25 / 150 points

1 badge earned

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Join now to unlock these features and more

Come for the products, stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Tips for Facilitating a Virtual Management Review and Problem Solving Meeting During PI Planning

Was this helpful?

Sam Tsubota

About this author

Senior Product Manager, Enterprise Agility

Los Angeles, CA

29 accepted answers

139 total posts

• +24 more...
• best-practice
• pi-planning
• scaled-agile
• Community Guidelines
• Privacy policy
• Notice at Collection
• Terms of use
• © 2023 Atlassian

Agile workflow

29 min read

The Ultimate Guide to PI Planning [2023 SAFe Edition]

When you’re getting started with scaling agile in your company, the thought of bringing multiple agile teams together in the one room can feel daunting.

Or maybe you’ve been doing PI Planning for a while now, but it’s not running too well and you have room to improve but not sure where.

Never fear, Easy Agile is here!

We’ve put together this complete guide to PI Planning in 2022. We’ll help destroy the myths and crack the code to running successful and effective SAFe PI Planning sessions.

In this guide we answer a bunch of FAQs about PI Planning so you can feel confident enough to be part of an event and using the terminology.

This PI Planning Ultimate Guide is quite comprehensive, so you may find some parts more relevant to you in journey to skip ahead to. We'll cover:

What actually is PI Planning?

Why do pi planning, what is the goal of pi planning, what should be included in the pi planning agenda, what is accomplished in the first part of the pi planning meeting, why is a confidence vote held at the end of pi planning, when is pi planning held, what is a pre-pi planning event and when is it needed, what does safe have to do with pi planning, what is pi planning in scrum, what is the difference between a pi roadmap and a solution roadmap, what is a program, what’s a program board, who should be involved in pi planning, what should we do to prepare for pi planning, what do you do after pi planning, what is post-pi planning, tips for distributed teams and remote pi planning, common mistakes and challenges, using jira for pi planning.

The complete PI Planning solution for Jira

Easy Agile Programs

Let’s start with the basics…

PI Planning stands for Program Increment Planning.

PI Planning sessions are regularly scheduled events held throughout the year where multiple teams within the same Agile Release Train (ART) meet to align to a shared vision, discuss features, plan the roadmap, and identify cross-team dependencies.

Here are the essential elements of PI Planning:

• 2 full day events run every 8-12 weeks (depending on the length of your increments)
• Product Managers work to prioritize the planned features for the increment beforehand
• Development teams own user story planning and estimation
• Engineers and UX teams work to validate the planning
• The goal is to align the teams to the mission and each other
• Everyone attends in person (if possible)
• Technology is used to allow distributed teams to participate (if needed)

If you’re adopting SAFe for the first time, chances are, it’ll start with PI Planning. That’s because it forms the foundation of the Scaled Agile Framework.

As Scaled Agile says, "if you are not doing it, you are not doing SAFe."

Quick definition: SAFe or the Scaled Agile Framework™ is a series of guidelines and practices designed to help bring agility into larger organizations, across all teams and levels of the business. The framework is geared at improving visibility, alignment, and collaboration and should lead to greater productivity, better results, and faster delivery.

Whether you’re adopting all 5 levels or just essential SAFe, the foundation of your transformation and the driver for everything is the PI Planning ceremony.

A word on distributed or hybrid PI Planning

Covid-19 has changed the way we work irrevocably. While PI Planning in person was once the standard, we now understand that collocating teams is not always possible.

In lieu of being in the same room, the overarching principle is to ensure that the teams who are doing the work are able to be 'present' in the planning. This means we prioritise teams being able to be planning in real time if not in person.

Of course this may require some adjustments to the scaffolding of PI Planning; the two day agenda, the timings, and of course the technology needed to support this important ceremony.

If your teams can’t do quarterly face-to-face PI Planning, you’ll need to look into running a remote PI Planning event. Don’t worry - it’s very do-able and ideal for organizations with distributed teams or flexible work arrangements. Plus, it’s a lot cheaper than flying folks in to do PI Planning every few months.

If you’ve got the right tools and technology, you can run PI Planning and allow anyone to participate, whether they’re in the same room or on the other side of the world.

Here are a few tips to help you make it work:

Rather than having everyone tune in from their separate remote locations, co-locate teams as much as possible. You might set up a main headquarters for hosting the leadership group and nearby teams, and then fly distributed workers into their nearest remote location. That way, everyone still gets an element of face-to-face collaboration.

Embrace the cloud

Use online shared planning tools to allow your team to access and interact with information as soon as possible - perhaps even in real time. Making sure every participant has immediate visibility on the information makes it easier to map cross dependencies and avoids storing the info in 10+ different places.

Livestream the event

Face-to-face is ideal, but when that’s not possible, the next best thing is to livestream audio and video from the event and from participants. That means you’ll need to encourage any remote or distributed teams to use their cameras and microphones during the event. It’s not quite the same as having them in the room with you, but it’s pretty close.

Ideally, everyone will participate in the PI Planning live. But whether your team is distributed across multiple timezones or a couple of team members can’t make it on the day due to sickness or something else, it’s a good idea to record the event, too. Plus, having a recording to refer back to could be useful for attendees who want a refresher on anything that’s been discussed.

Some teams will change the standard PI Planning agenda to fit multiple timezones, which could mean starting the event earlier or later for some, or even running it across 3 days instead of 2.

Lay down the law

One common issue that can arise from having distributed teams tune in remotely via video and audio is too much noise and interference. Before your first session kicks off, communicate about when it’s acceptable to talk and when teams need to use the mute button. That way, your teams will avoid getting distracted, while still ensuring everyone can participate.

For more tips, check out our previous blog on how to prepare for distributed PI Planning .

Equip your remote, distributed or co-located teams for success with a digital tool for PI Planning.

Whether distributed or in person, if your team gets PI Planning right, it makes everything in the upcoming increment so much easier.

PI Planning is incredibly beneficial for large scale agile organizations.

To understand the impact, let’s look at some numbers. For example, some larger organizations might have 200-300 teams and 10,000 developers. In the old way of working, these teams would never have spoken to one another before (until there was a critical problem that forced them to talk).

Previously, alignment would have been at the leadership team level, and they’d have multiple levels of managers in between who cascade information down, but the people on the teams would never talk to one another. There would be a constant battle for resources, budget, and opportunities to work on the sexiest projects.

Speaking of projects, these had a habit of conflicting - one team would release something and then it would break something in another team’s project.

PI Planning is the first time many of these really big companies get their teams together in a room or on the same call and talking to each other. They get the chance to nut out those important conversations about who’s working on what.

Why might this be important?

• When you’re touching a system or a code repository, you need to know how it’s going to impact another team
• You might need to do some work to enable another team to work on their feature first (and vice versa)

PI Planning enables:

• Communication
• Collaboration

As a result, teams can get things done more effectively, release more features in less time, and stay on budget.

All very good reasons to do PI Planning. But let’s also look at the big picture...

PI Planning is an essential part of the Scaled Agile Framework , a framework that’s designed to bring agile to large companies with multiple teams.

SAFe PI Planning helps teams in the Agile Release Train (ART) synchronize, collaborate, and align on workflows, objectives, releases, and more.

On the flip side, without PI Planning, teams don’t have structured communication. They may not know what the other teams are working on, which can cause a lot of problems. For example, two teams might be working on different features without realising there’s a dependency which could hold up the release or require a significant rework of the code.

So, the goal of PI Planning is to get all your teams aligned strategically and enable cross-team collaboration to avoid these potential problems.

Now that we’ve covered off the “why”, let’s dig a bit deeper into the “what”. The best way to get a picture of what happens during PI Planning is to take a look at an agenda.

Here’s a standard PI Planning agenda template suggested by the SAFe website:

Source: scaledagileframework.com/pi-planning

This agenda might be perfect for you, or you might tweak it based on your team’s needs. Distributed teams, very large ARTs, and other factors might require you to get creative with the schedule. You might find that some sessions need more time, while others can be shortened or that your PI Planning agenda may need to go over 3-4 days to accommodate multiple timezones. If it’s your first PI Planning event, try the standard agenda, get feedback from your teams, and experiment with different formats next time.

Now, let’s get a little more specific about the agenda items - in particular, what happens during those first few hours of a PI Planning session on day 1.

Day 1 usually kicks off with a presentation from a Senior Executive or Business Owner. The agenda allows an hour to talk about the current state of the business. They highlight specific customer needs, how the current products address these needs, and potential gaps.

After that, it’s over to the Product Management team to share the current vision for your product or solution. They’ll talk about any changes that have occurred since the last PI Planning session (usually around 3 months prior). And they’ll cover off what’s coming up, including milestones and the next 10 features that are coming up. This session should take around 1.5 hours.

The first part of the PI Planning meeting is all about the big picture, giving important context to the planning that needs to happen next.

The confidence vote is a seemingly small but very important part of PI Planning towards the end of the event.

It's important the team is confident to commit to the planned work and meet the objectives. The Release Train Engineer will ask teams to vote on this.

Everyone in the room needs to vote by raising a hand (and fingers).

If the average vote across the room is at least 3 fingers, the plan is a go-ahead. If it’s less it’ll need reworking (until it reaches a high confidence level). Plus, if anyone votes using just one or two fingers, they’ll have the chance to share the reasoning.

The confidence vote is all about making sure that the attendees are in alignment and that they agree that the plan in its current form is do-able within the given timeframe. Speaking of timing, let’s talk about how and where PI Planning actually fits into your company calendar.

Many companies find that 8-12 weeks (which adds up to 4-6 x 2-week iterations) is the right amount of time for an increment.

Some companies hold quarterly PI Planning, for example:

• Q1 PI Planning: December
• Q2 PI Planning: March
• Q3 PI Planning: June
• Q4 PI Planning: September

But the timing and frequency will depend on how long each program increment is scheduled to last and may need to accommodate holidays.

The good thing about PI Planning events is that they happen regularly on a fixed schedule, which means you can plan for them well ahead of time. That means teams and Business Owners have plenty of notice to ensure they can show up for the event.

This means that what happens in preparation for PI Planning can be just as important as the event itself.

A pre-planning event - separate to PI Planning - is to make sure that the ART is aligned within the broader Solution Train before they do PI Planning. It’s all about synchronising with the other ARTs to ensure the solution and organization are heading in the right direction, together.

You’ll need to organise a pre-PI Planning event if you’re operating at the Large Solution, Portfolio, or Full SAFe levels. Essential SAFe is more basic and does not have a Solution Train, so if you’re operating at this level, you won’t need pre-PI Planning so formally.

What usually happens is that key people get together from the Solution Train, along with representatives from the ARTs and relevant suppliers. Here are a few of the folks you’ll find at the planning event:

• Solution Train Engineer
• Solution Management
• Solution Architect/Engineering
• Solution System Team
• Release Train Engineers
• Product Management
• System Architects/Engineers

Easy Agile Programs enables Release Train Engineers and Program Managers to effectively manage programs at a team-of-teams level to deliver alignment at scale.

They’ll look at the top capabilities from the Solution Backlog, Solution Intent, Vision, and Solution Roadmap. It’s really a lot like PI Planning but at a higher level, across the overall solution and not just the individual ART.

The event starts with each ART summing up their previous program increment and accomplishments to set the context. Next, a senior executive will brief the attendees on the current situation before Solution Management discusses the current solution vision and any changes from what was shared previously. Other things that are often discussed or finalized include:

• Solution backlogs
• Upcoming PI features from the Program Backlog

In the next section, we'll help to define a few key terms that have been touched on.

As mentioned earlier, SAFe stands for the Scaled Agile Framework.

SAFe is the world’s leading framework for scaling agile across the enterprise. ( State of Agile Report )

For a bit of perspective - Scrum and Kanban are also agile frameworks (that you may be more familiar with), and these have historically been very effective at the individual team level. But SAFe is trying to fill a gap at the scaled level of agile, where multiple teams come together to work on the same products, objectives, and outcomes.

SAFe outlines what should happen at each level of the organization to make sure that scaled agile is successful. It goes way beyond the team level to include every stakeholder.

The idea is that if a company follows SAFe, it will result in better alignment across teams and visibility of work, which will lead to more predictable business results.

This is increasingly important as the environment for organisations continues to change and customers expect more features to be delivered more quickly. The traditional waterfall approaches fall short because they’re slow and inefficient.

Bigger companies (often with thousands of developers) can’t keep up with the innovation of smaller, more nimble startups. Along with bigger teams, larger organizations often have stricter requirements around governance and compliance, which can make it harder to move quickly.

It can take 3-4 years for these bigger, more complex companies to launch a new feature, which slows down customer delivery. Plus, they often struggle to manage and organize their (many!) teams of developers, which also stops them from launching projects on time.

They need to make a change to speed things up, make the most of their resources, and minimize budget blowouts. These companies are looking for new ways to organize people into projects and introduce more effective ways of working. If they don’t, they face not surviving.

SAFe is a way for these companies (that otherwise would stay stuck in their old ways) to start moving in a more agile direction.

This is where PI Planning comes in.

PI Planning is a vital element of SAFe. It’s a ceremony that brings together representatives from every team to help them work together, decide on top features to work on next, identify dependencies, and make a plan for the next Program Increment. As a result, there’s greater visibility across all the teams, changes are made more frequently, and teams work with each other - not against each other. From there, these massive companies can speed up their processes, work more efficiently, compete with newer and more nimble companies, and stay viable.

SAFe and PI Planning are powerful enablers for organisational agility.

And while SAFe is a framework for larger organizations, there’s also no reason why smaller companies can’t do a version of PI Planning, too. All you need is more than one agile team to make it worthwhile.

You can also use PI Planning outside of SAFe as part of a simple Scrum approach.

Scrum Framework diagram shows when and how scrum teams can implement PI Planning

Source: Scrum.org

Scrum is an agile framework that helps teams get things done. It’s a way for teams to plan and organize their own work and tackle user stories and tasks in smaller time boxes. This is often referred to as a sprint.

If multiple scrum teams want to work better together (but aren’t necessarily operating within SAFe), they could adopt a version of PI Planning.

For example, these scrum teams could:

• Meet every 10 weeks and discuss the features they are planning to work on
• Get product managers to combine backlogs and prioritize together
• Share resources across the teams, as needed
• Map dependencies and coordinate joint releases

The good news here is that there’s no “one size fits all” approach to PI Planning, so think about how you could adopt the ideas and principles and make it work for your organization and context.

Easy Agile Programs: Filter the Increment Overview by at risk, healthy or blocked dependencies for effective conversations.

💥 JOIN A DEMO 💥

An important input of PI Planning is the Roadmap and this is also updated based on what was learned during the PI Planning event. A common question we get asked is:

There are a few different types of roadmaps in SAFe, so it’s important to understand the differences and what each roadmap is meant to do.

Your PI Roadmap is created before your PI Planning event, and also reviewed and updated by Product Management after the event is finished. It will usually cover three Program Increments:

• The current increment (work that’s committed)
• The next forecasted increment (planned work based on forecasted objectives)
• The increment after that (further planned work based on forecasted objectives)

If you do quarterly PI Planning, it’ll outline around 9 months of work. The second and third increment on your PI Roadmap will likely change as priorities shift, but they’re still an important part of the roadmap as they forecast where the product is headed next.

So, what’s the Solution Roadmap all about?

The Solution Roadmap is a longer term forecasting and planning tool for a specific product or service.

It will usually cover a few years at a time, with more specific details available for year one (like quarterly features and capabilities), and more general information (like objectives) for year two and beyond.

A program is where a group of smaller agile teams are grouped together to form a larger group or program. This is often referred to as the “team-of-teams” level.

When you hear people talking about team of teams or scaled agile, they mean taking agile beyond a single team, and asking more teams to join in.

For example, there might be 4 teams working on a NASA spaceship mission to Mars.

NASA decides they want to see if agile can help these teams do better work. So, to start with, the Oxygen team switches from working with traditional Waterfall project management methods to embracing agile principles.

• Launch team
• Oxygen team (Agile)
• Landing team

After a few months, NASA decides that the way the oxygen team is working is going well, so the remaining three teams similarly adopt more agile methodologies:

• Launch team - Agile!
• Food team - Agile!
• Oxygen team - Agile!
• Landing team - Agile!

Each of these 4 teams are self-organising, meaning they’re responsible for their own work.

However, now that these teams are all working in the same way, they can be grouped together as a program.

So in simple terms, a program is a group of agile teams. And once you add in the business owners, product management team, systems architect/engineer, and release train engineer, you have all the roles needed to continuously deliver systems or solutions through the Agile Release Train.

Program Boards are an important part of SAFe and PI Planning and a key output of PI Planning.

Traditionally, they’re a physical board that’s mounted on the wall, with columns drawn up to mark the iterations for the increment, and a row for each team. Teams add sticky notes that describe features they’ll be working on.

Once all the features are added, they work to identify dependencies (features that’ll affect other features) and mark this up by connecting them with red string.

SAFe program boards don’t have to be physical, though. There are a lot of advantages to using a digital program board like Easy Agile Programs , which integrates directly with Jira. We’ll talk more about how you can use Jira for PI Planning towards the end of this guide. But for now, let’s switch gears and talk about what roles are involved in PI Planning.

There are 5 key roles in a PI Planning event:

• Product Managers
• Product Owners
• Scrum Masters

Let’s take a closer look at what each of these roles is responsible for during the event.

Release Train Engineer

The Release Train Engineer is a servant leader and coach for the ART. Their role focuses mainly on planning and facilitating the PI Planning event. This means they help:

• Establish and communicate the annual calendars
• Get everything ready (including pre and post PI Planning meetings)
• Manage risks and dependencies
• Create Program PI Objectives from Team PI Objectives and publish them
• Track progress towards expected goals
• Ensure strategy and execution alignment
• Facilitate System Demos

As the facilitator for the 2-day event, the Release Train Engineer presents the planning process and expected outcomes for the event, plus facilitates the Management Review and Problem Solving session and retrospective.

Product Manager

A Product Manager’s job is to understand the customers’ needs and validate solutions, while understanding and supporting portfolio work.

So, what is the product manager’s role in PI Planning?

They present the Program vision (aka top 10 Features that are coming up) plus any upcoming Milestones. They review the Draft plan and describe any changes to the planning and scope based on the Management Review & Problem Solving session. That way, they can manage and prioritize the flow of work. Once the PI Planning event is over, they use the Program Objectives from the Release Train Engineer to update the roadmap.

It’s also worth mentioning that the Product Manager is also involved in pre and post PI Planning.

Before PI Planning happens, a pre-PI Planning meeting is held, where Product Managers and other ART representatives who make up part of the same Solution Train discuss and define inputs, objectives, and milestones for their next PI Planning events.

Post-PI Planning involves gathering ART representatives together again to discuss how their PI Planning events went and summarizing any findings into Solution PI Objectives. Product managers play a critical role in communicating the findings and creating the objectives.

Product Owner

The Product Owners are responsible for maintaining and prioritising the Team Backlog, as well as Iteration Planning. They have content authority to make decisions at the User Story level during PI Planning Team Breakout sessions.

Product Owners help the Team with defining stories, estimating, and sequencing, as well as drafting the Team’s PI Objectives and participating in the Team Confidence Vote. They’re also responsible for conveying visions and goals from upper management to the team, as well as:

• Reporting on key performance metrics
• Evaluating progress, and
• Communicating the status to stakeholders

Scrum Master

The Scrum Master is a servant leader to the Product Owner and Development team, which means they manage and lead processes, while helping the team in practical ways to get things done.

They facilitate preparation for events (including PI Planning) and prepare System Demos. They help the team estimate their capacity for Iterations, finalise Team PI Objectives, and manage the timebox, dependencies, and ambiguities during Team Breakout sessions. The Scrum Master also participates in the Confidence Vote to help the team reach a consensus.

Developers are responsible for researching, designing, implementing, testing, maintaining, and managing software systems.

During PI Planning, they participate in Breakout sessions to create and refine user stories and acceptance criteria (alongside their Product Owner) and adjust the working plan. Developers help with identifying risks and dependencies, and support the team in drafting and finalizing Team PI Objectives, before participating in the Team Confidence Vote.

At this point, you’ve got all the key definitions, you know what needs to happen during a PI Planning event and who needs to be involved.

Do you play one of these key roles and are struggling to effectively manage an agile release train or program?

“By failing to prepare, you are preparing to fail.” - Benjamin Franklin

If you want to succeed at PI Planning, make sure you don’t skip over the prepwork.

Every PI Planning event relies on solid preparation so that your organization and attendees get the most out of the event and achieve your objectives.

What is involved in planning?

The participants themselves (plus key stakeholders and Business Owners) must get ready by assigning any key roles, ensuring there’s alignment on the strategy, and ensuring the planning process is properly understood by everyone.

Any presenters will also need to get content ready for their presentations.

Plus, you’ll need to ensure the facility is ready - especially since you may have hundreds of participants attending. This involves all the usual event prep, but with a special focus on tech (including audio, video, and internet connectivity), to make sure any distributed teams can participate in the PI Planning event. Don’t forget to plan for enough food for everyone, too (planning is hungry work).

So, at this point, we have a clear picture of what happens during and before a PI Planning event, but what about afterwards?

After PI Planning, teams do a planning retrospective and list out:

• What went well
• What went not-so-well
• What could be better for next time

And then there’ll be a chat about the next steps. These steps can include things like:

• Getting copies of the objectives, user stories, and program board into your project management tool (like Jira)
• Taking a look at calendars
• Chatting about meeting times and locations for daily stand-ups and iteration planning
• Making sure that everyone has their belongings and leaves the event rooms clean when they go

The other thing that usually happens after PI Planning events is a post-PI Planning event.

These are similar to the pre-PI Planning events we already talked about. They involve getting together ART stakeholders across all the Agile Release Trains within the solution train to ensure they’re synchronised.

Post-PI Planning happens after all the ARTs have completed their PI Planning for the next increment. They present the plans, explain their objectives, and share milestones and expected timelines.

Like PI Planning events, post-PI Planning involves using a planning board, but rather than features, it outlines capabilities, dependencies, and milestones for each iteration and ART. Potential issues and risks are identified, discussed, and either owned, resolved, accepted, or mitigated. And similar to regular PI Planning events, plans go through a first-of-five vote of confidence to ensure they meet the solution’s objectives, and are reworked until the attendees average 3 fingers so more.

Are you going to SAFe Summit 2022?

Stop by our booth for a live demo of Easy Agile Programs. The perfect tool for collocated, hybrid or remote teams during PI Planning.

PI Planning doesn’t always smoothly, especially the first time. And the framework itself may present a challenge to some organizations. Here are some common mistakes and challenges to keep in mind (and avoid, if possible):

Long, boring sessions

One of the major downsides of PI Planning is the suggested agenda includes some long, heavy sessions, right from the start. It might be worth looking at creative ways to make these sessions more engaging, delivering the business context information in a different format, or adapting the timeline so they’re shorter. That way, there’s more time for team planning and collaboration.

Tech issues

Any event is vulnerable to tech mishaps, but if you’re streaming audio and video to a distributed team, this can really impact on the flow of the event. It’s a good idea to carefully test all the equipment and connections ahead of time to minimise potential problems.

Confidence vote

Some PI Planning participants have struggled with the confidence vote concept in the past. People may feel pressure from the room to vote for a plan to go ahead, rather than speaking up about their concerns.

Time constraints

When you have a large ART of, say, 12 teams, that’s a lot of draft plans to present and review. Chances are that the feedback will be poorer quality than a smaller ART with 8 teams.

Not committing to the process

SAFe isn’t perfect and neither is PI Planning. But the process has been proven to work for many organizations. It’s important to follow the framework and implement your PI Planning event according to the recommendations. Then commit to the process that follows.

Sticking with the same old tools

If something’s not working, fix it. For example, too many teams stick with traditional SAFe Program Boards even though they’re not always practical. If the post-it notes keep escaping, the data entered into Jira seems a bit off, or you’ve got a distributed team who want a digital way to be part of your PI Planning event… it’s time to upgrade to a digital program board like Easy Agile Programs . Speaking of software, it’s (finally) time to talk about Jira!

Jira is the most popular project management tool for agile teams, so if you’re agile, chances are you're already using it at the team level.

Jira is great for single teams.

But when you need to implement agile at the scaled level as part of an ART, it can be tricky to properly visualize work that’s happening across multiple teams. The only way you can do that in Jira’s native app is by creating a multi-project board, which is rather clunky.

So, how does Jira fit into SAFe and PI Planning?

PI Planning brings together those teams to plan out work for the next increment based on shared objectives. During PI Planning, teams use a Program Board to plan out their work and map dependencies. Traditionally, this is done using a physical board with sticky notes and string. After the session is over, the notes and string are recreated in Jira for the whole team. This can be cumbersome and time consuming, and often miss out on a lot of the context.

The best way to use Jira for PI Planning is to use an app like Easy Agile Programs to help you run your PI Planning sessions. The integrated features mean you can:

• Set up a digital Program Board (no more string and sticky notes!)
• Do cross-team planning
• Visualize and manage cross-team dependencies, create milestones
• Identify scheduling conflicts to mitigate risks
• Get aligned on committed objectives for the Program Increment
• Visualize an Increment Feature Roadmap
• Transform Jira from a team-level tool to something that’s useful for the whole ART

Join companies like Boeing, Vodafone, and Prudential Insurance who use Jira to do PI Planning with Easy Agile Programs (which is available from the Atlassian Marketplace).

📣 Listen to what Ben form PNI Media has to say about Easy Agile Programs

One and done: Discover how PNI media embraced virtual PI planning

Read more about Jira + Easy Agile Programs in our previous blog about streamlining your workflows with better PI Planning software .

Anything else you’d like to know about PI Planning?

We’ll come back to this guide and make it even more epic in the future. So if you have any questions about PI Planning or you notice there’s an aspect we haven’t covered yet, let us know over on Twitter !

Scaled Agile Framework (SAFe) 5.0 - The Easy Agile Review

Why large enterprises need Scaled Agile Framework (SAFe), not team-level Agile

Subscribe to our blog.

Keep up with the latest tips and updates.

What is PI planning?

Sign up for free to get started

Table of contents, definition of pi planning.

Program increment (PI) planning is an event that creates a shared vision among Agile teams. Throughout the event, business stakeholders, project owners, and project teams review their program backlog. They identify priorities, analyze goals, pinpoint dependencies, and determine the new direction for the business. Organizations typically carry out these meetings every 8–12 weeks. They’re usually spread over 1–2 days (although virtual sessions tend to be shorter). This allows teams plenty of time to host breakout sessions, collaborate, and discuss the new plan of action. But where does Agile come into this, and what is a PI planning event in Agile ? In the Agile framework, PI planning allows teams to create an Agile Release Train (ART). An ART brings teams together to help them make informed decisions about the future of product development.

What is SAFe PI planning?

The Scaled Agile Framework (SAFe) is a structure for implementing Agile practices. It helps teams come together to review the same products, outcomes, and key objectives at an enterprise scale. The SAFe program board is an important part of Agile PI planning. In fact, it’s the key deliverable of a PI session (more on this later). A SAFe program board maps delivery dates, dependencies, milestones, and timelines.

What is the goal of a PI planning event?

There are many benefits to running a PI planning session with your team. The main goals of a PI planning event is to:

1. Align Agile teams

Cross-functional collaboration is tricky, especially for distributed and remote teams. Everyone is on the same page  with a PI planning event — no matter what department they’re from.

2. Set clear goals

PI planning outlines your company goals and objectives. Every participant knows what the end goal is, why it’s important, and how to achieve it.

3. Build trust

PI planning is a collaborative process. It’s a great way for Agile teams to build relationships and develop trust with other team members.

4. Offer a better customer experience

PI planning allows you to streamline your processes and ensure that your teams are aligned across the business. As a result, your customers get a smoother, more efficient, and an overall better experience.

5. Make quick decisions

Decision-making isn’t easy for large, cross-functional teams. Use a PI planning event to bring teams together to make fast and informed decisions.

6. Prioritize tasks

Use a PI planning session to pinpoint the most important areas of your work and focus on action items that will help you achieve your objectives.

Who should be involved in PI planning?

The following team members form a PI planning event:

Release train engineer

The release train engineer (RTE) is the leader and coach of the Agile Release Train (ART). They form the head of the PI planning board. Their role is to plan, manage, and facilitate the PI planning event.

Scrum master

The scrum master in PI planning manages and leads processes during the event and facilitates preparation with the RTE. They also review team capacity, making sure the team can complete the work required to meet the goals and objectives. The scrum master is responsible for the timebox, identifying dependencies, and addressing any ambiguities during the breakout sessions.

Product manager

The product manager is responsible for presenting the program vision and any upcoming milestones. They review the draft plan to ensure they can effectively manage the flow of work. Their perspective is also valuable to the PI planning process, mostly because they fully understand customer needs. Their input ensures that the goal and direction add value to the end user.

Developers research, design, test, and maintain software systems. During PI planning, they participate in breakout sessions to help refine user stories, identify risks, and help the product owner finalize the PI objectives.

Big room planning versus PI planning

Big room planning is another word for PI planning, but it indicates that the team meeting is in-person. Today, many teams opt for a hybrid format to host these meetings. This allows distributed teams to easily attend the sessions from wherever they are. And when the meetings are online, the teams can record the sessions and review them in the future.

But managing an online PI planning session doesn’t come without challenges. Hosting a virtual meeting can be hard for hosts, with more considerations to make than an in-person event. Technology, for example, is a big factor to think about. If the technology doesn’t work or isn’t efficient, the entire meeting could fall apart. Online meetings can also be tricky for attendees. Focusing on a screen for long periods can be challenging, leading to a lack of concentration. Fortunately, there are tools to help you overcome these issues. Take a look at Miro as an example. If you choose to host a virtual PI planning session, a tool like Miro can help you plan, manage, and execute your meeting — as well as keep your participants engaged. Using a customizable and intuitive visual workspace allows teams to collaborate online. Start by selecting the ready-made PI planning template and begin recording all the information on Miro's infinite canvas. To keep participants focused, use the timer to cap the time spent in each session. Allow for breaks, and consider using icebreaker games to keep things light and engaging.

What to include in a PI planning agenda?

A successful PI planning meeting agenda should include the following information:

Business context

The business owner starts by describing the current state of the business. They’ll share the company’s vision for the future and outline how existing business solutions address current customer needs.

Product/solution vision

Product management then presents the current vision. This is often represented as the next 10 product features or the most pressing items in the product backlog. The product manager then highlights any changes from the last PI planning session.

Planning context

The RTE presents the planning process and outlines the expected outcomes.

Team breakouts

Participants break away into their teams to estimate the capacity for each iteration. The teams then create a draft plan outlining each iteration. This session is timed (use Miro’s Timer to manage this).

Draft plan review

Teams present their key planning outputs, including their capacity, PI objectives, risks, and dependencies. Other teams review all the draft plans and provide feedback.

Management review and problem-solving

Draft plans often present challenges to overcome, such as limited scope, capacity, resources, and conflicting dependencies. Management spends some time figuring out how to address these challenges. The RTE keeps this meeting on track.

Program risks

Before launching any new iterations, it’s important to identify potential risks. Teams categorize these risks into one of five categories. The first category is Resolved , which means the entire team agrees that there’s no longer a risk. The second category is Owned , meaning someone takes ownership of managing an unresolved risk. The third category is Accepted , which includes risks that are unavoidable and simply need to be understood and accepted. The fourth category is Mitigated , where teams figure out how to reduce the impact of a risk. Finally, the fifth category is Confidence Vote . The confidence vote in PI planning allows teams to vote on how confident they are that the team will meet the objectives after addressing all the risks.

Rework plan

Teams then rework their plans and address potential risks to achieve as high a confidence level as possible.

Planning retrospective and moving forward

In the final stage of the meeting, the RTE leads a brief retrospective. They’ll cover what went well, what didn’t, and what can be improved for the next session. The amount of time you assign to each of these areas is up to you. There’s no right or wrong but bear in mind that it’s harder for team members to maintain focus if they’re attending the meeting virtually. Allow for enough breaks throughout the session to keep them motivated and engaged.

How to prepare for a PI planning session

Follow these three simple steps to prepare for your next PI planning session.

Perform pre-planning activities

Pre PI planning events help everything run smoothly on the day of the session. You’ll make sure that all teams are ready for the session, that the necessary people have been invited, and that the technology (or location, if the meeting is in person) is ready to go. Here are the three key areas of pre PI planning:

1. Organizational readiness

This involves preparing the planning scope to ensure everyone is prepared for the meeting. It also means aligning the business priorities ahead of the meeting to make them as streamlined as possible and ensuring all critical roles are assigned.

2. Content readiness

To ensure a clear vision for the meeting, teams need to have all the right content ahead of it. This includes the executive briefing to define the current state of the business, an up-to-date product backlog, and the architecture vision briefing.

3. Logistics readiness

Organizing logistics is a vital part of PI planning. It involves planning the location (at a facility or online), sourcing the right technology, and choosing the right communication channels.

Choose the right platform

Planning to run a virtual PI planning session ? You need software that works for you and your Agile team. If the platform isn’t right, it can be difficult to run a successful meeting. To find the right platform, think about the features you need to make your meeting run as smoothly and efficiently as possible. Here are some suggestions:

A collaborative workspace . A virtual, collaborative workspace allows teams to work together throughout the session. Using an online workspace, especially one with specific features to enable PI Planning can help boost productivity, camaraderie and innovation.

Top-quality video chat . If participants are dialing in virtually, you need a high-quality video call platform. That way, everyone can experience the meeting without experiencing any glitches.

A timer . Keep your meetings on track by using a timer. This helps teams be as concise and productive as possible during the session.

Voting . Ensure all opinions are taken into account by using a voting tool.

Templates . Speed up by leveraging tried and tested templates to take advantage of best practices.

Understand the inputs and outputs

The items you’ll need to prepare before the meeting are your inputs. They’re vital to the success of your PI planning session, so it’s important to know exactly what they are and how to prepare them. Here are some examples of PI planning inputs:

Executive briefings. Briefings must be prepared beforehand to align teams and provide context for your session.

Roadmap and vision. You need a clear definition of the business’s direction and management’s vision for the future.

Program backlog. Prepare your prioritized list of product features and functionalities before the meeting so that you can discuss which items to focus on in your upcoming iterations.

Now, let’s look at the outputs.

Outputs are any tangible outcomes from your planning session. Two outcomes of PI planning indicate that the session was a success:

Committed PI objectives. The team’s commitment during the PI planning will result in a set of SMART goals that outline what you intend to achieve in your upcoming iterations. Each team may have its own goal to focus on, depending on what you discussed during the session.

A program board. A program board outlines your delivery dates, dependencies among teams, milestones, and a timeline of the events.

These outputs mark the end of your PI planning session. They’ll guide your future iterations and help your teams achieve their goals before returning to the drawing board for a new PI planning meeting.

Use Miro to host your PI Planning event

Miro's integrated set of Agile tools helps teams of all sizes run PI Planning events efficiently. Streamline preparations, align on dependencies, and run sessions that are engaging and collaborative.

Discover more

The ultimate guide to facilitating hybrid pi planning, what is an agile workflow, how to hold sprint planning & review meetings, what is safe, get on board in seconds.

Join thousands of teams using Miro to do their best work yet.

What is SAFe PI Planning?

September 26th, 2023 by inflectra

PI planning is an efficient way to leverage agile processes at scale, even in large enterprises. But how do we define PI planning? Keep reading to learn what it is, the benefits it provides, and the steps involved with this process.

PI planning meaning

One of the cornerstone practices in the Scaled Agile Framework is PI (Program Increment) planning . This is a structured, time-bound event in the SAFe framework where cross-functional teams come together to plan and align their work for a specific Program Increment.

A Program Increment is a fixed time frame, typically spanning 8-12 weeks, during which an Agile Release Train (ART) delivers value in the form of working, tested software and systems. This practice ensures that all teams within the ART move in a coordinated manner, working toward common objectives.

What is the goal of PI planning?

The primary goal of PI planning is to create alignment and synchronization among multiple Agile teams that are working collaboratively to deliver value. It aims to establish a clear plan for the upcoming Program Increment, ensuring that everyone understands their roles, responsibilities, and priorities. Essentially, PI planning sets the stage for a focused, well-coordinated, and productive execution phase.

Why is it important?

SAFe PI planning holds immense importance for several reasons:

Alignment - one of the central tenets of SAFe PI planning is alignment. It aligns all teams within the Agile Release Train to a common mission and vision. By doing so, it ensures that everyone is working in concert towards shared objectives. This alignment prevents the common problem of different teams pulling in different directions, which can lead to inefficiencies and conflicts.

Visibility - PI planning provides transparency into the work that will be undertaken in the upcoming Program Increment. This transparency is vital for stakeholders, including executives, product managers, and team members, as it enables better decision-making. When everyone can see what's planned, they can anticipate potential bottlenecks, address resource constraints, and make informed decisions.

Coordination - in a large organization with multiple Agile teams, dependencies are inevitable. PI planning brings these dependencies to light and provides a forum for teams to discuss and coordinate their work. This coordination minimizes bottlenecks and ensures that work flows smoothly from one team to another.

Risk Mitigation - identifying and addressing risks early is a fundamental part of PI planning. By discussing potential challenges and bottlenecks, teams can proactively develop mitigation plans. This risk-focused approach further reduces the chances of unpleasant surprises during the Program Increment.

Customer Value - in an Agile environment, delivering value to the customer is paramount. PI planning ensures that customer-centric features and functionality are prioritized and delivered in a timely manner. It keeps the focus on delivering value at regular intervals, which is one of the core principles of Agile.

Who should be involved in PI planning?

As we mentioned, PI planning is a collaborative effort that involves a variety of roles , including Product Owners, Scrum Masters, Testers, and more. Key participants typically include:

Release Train Engineer (RTE) - facilitate and orchestrate the PI planning event, ensuring that it runs smoothly and efficiently.

Product Owners - responsible for representing the voice of the customer. They define the features and user stories to be developed in the Program Increment.

Scrum Masters - play a crucial role in removing impediments and ensuring that teams adhere to Agile principles and practices. They act as coaches and servant leaders.

Developers and Testers - individuals who execute the work and are responsible for implementing and testing the features and user stories.

System Architects - provide technical guidance and ensure architectural integrity across the Program Increment. They help teams make sound technical decisions.

What are anti-patterns?

"Anti-patterns" refer to common practices or behaviors that, while often mistakenly used, can hinder or undermine the effectiveness of the PI planning process. They are patterns of action that are counterproductive and can lead to suboptimal outcomes during planning. Common anti-patterns to watch out for include:

Lack of Preparation - inadequate preparation can lead to a disorganized and unproductive event. Teams should ensure that the backlog is well-prepared, dependencies are identified, and key roles are aware of their responsibilities before the PI planning event.

Overloaded Agendas - trying to cover too much in a single PI planning event (which we’ll explain more further down) can lead to information overload and decreased focus. It's essential to strike a balance between discussing important topics and keeping the event manageable.

Lack of Engagement - if key stakeholders, including product owners and business owners, are not actively engaged, alignment and buy-in may suffer. It's vital to ensure that all relevant parties participate fully in the planning process.

Ignoring Dependencies - dependencies between teams and features are common in large-scale Agile environments. Ignoring or mishandling dependencies can lead to delays and disruptions during the Program Increment. It's crucial to identify, document, and address dependencies during PI planning, including discussing inter-team dependencies, coordinating efforts, and developing strategies to mitigate risks associated with dependencies.

Neglecting Retrospectives - PI planning retrospectives, where teams reflect on the planning process and identify areas for improvement, are essential. Skipping these retrospectives can prevent teams from continuously improving their planning process.

Benefits of scaled agile PI planning

Effective SAFe PI planning offers a wide range of business benefits that contribute to the success of large-scale Agile initiatives:

Better predictability

Improved planning leads to greater predictability. Stakeholders can have confidence in the team's ability to meet commitments and deliver value consistently. Predictability is essential for business planning, as it allows organizations to set realistic expectations, allocate resources effectively, and make informed decisions about priorities and investments. When teams consistently meet their commitments, trust is built between teams and stakeholders, which further enhances predictability.

Early issue identification

PI planning provides a structured forum for identifying and addressing potential issues and risks early in the planning process. By discussing potential challenges and bottlenecks during the planning event, teams can proactively develop mitigation plans and strategies. This early issue identification and proactive problem-solving help teams avoid surprises and delays during the Program Increment. It also allows teams to make necessary adjustments to their plans to ensure a smoother execution phase.

Improved collaboration

Effective SAFe planning fosters collaboration among teams within the Agile Release Train. Teams learn from one another, share insights, and work together to achieve common objectives. This collaborative environment promotes knowledge sharing and cross-functional teamwork, which are essential for successfully delivering value in a large-scale Agile setting. Improved collaboration also reduces the potential for silos and promotes a sense of unity among teams.

More transparency

With scaled agile PI planning, stakeholders (including executives, product managers, and team members) gain transparency into progress and priorities. They can see what work is planned for the upcoming Program Increment, which features are a priority, and how teams are coordinating their efforts. This transparency builds trust among stakeholders and allows for more informed decision-making. When everyone has visibility into the planning process, it becomes easier to address challenges and make adjustments as needed.

PI planning steps

PI planning involves a meticulously structured process designed to ensure alignment, collaboration, and efficient execution of work across ARTs. This planning process consists of several key phases, each with its unique purpose and activities:

Preparation

The preparation phase is the foundation of successful PI planning. It involves three primary activities:

Prepare the Backlog - product owners work diligently to ensure that the backlog is in a well-defined, prioritized, and ready-to-plan state. This means that features and user stories should be refined, detailed, and appropriately sized.

Pre-PI Planning - before the official PI planning event, product owners, Scrum Masters, and other key roles engage in the pre-PI planning activities mentioned above. This includes reviewing features, identifying dependencies, and addressing any outstanding questions or concerns. The goal is to enter the planning event with a clear understanding of what needs to be accomplished.

Identify Business Context - Understanding the strategic themes and priorities for the upcoming Program Increment is critical. Teams must be aware of the larger organizational goals and context within which they will be planning their work.

Standard agenda

The standard agenda in SAFe PI planning is the next planning step and is made of a structured sequence of events that provides a framework for teams to follow during the planning event. The standard agenda in SAFe PI planning consists of 7 activities over the two days of PI planning (Business Context, Product Owner Pre-Planning, Team Breakout Session, I&A Session, Management Review, Problem-Solving Workshop, and PI Objectives and Metrics):

The first day of the PI planning event is dedicated to preparation. It sets the stage for a productive and well-organized planning session.

Business Context - the day begins with a clear Business Context presentation. During this session, leaders and stakeholders communicate the strategic themes, objectives, and priorities that will guide the Program Increment. It's crucial for teams to understand the larger context within which they'll be working to ensure that their efforts are aligned with the organization's goals.

Product Owner Pre-Planning - before the event, product owners engage in pre-planning activities. This involves reviewing the features and user stories in the backlog, ensuring they are well-defined, prioritized, and ready for discussion during the planning event. The preparedness of product owners is essential for a smooth and efficient planning process.

Team Breakout - after the Business Context presentation and product owner pre-planning activities, teams participate in a team breakout session. In these breakouts, teams review and discuss the features and user stories that are relevant to their areas of responsibility. They consider factors such as dependencies, technical considerations, and the overall scope of work. These discussions lay the groundwork for informed decision-making during the formal planning sessions on Day 2.

The second day of SAFe PI planning is the formal planning day, where teams come together to make commitments and align their work for the Program Increment.

Inspect and Adapt - the day kicks off with an Inspect and Adapt (I&A) session. During this session, teams present their preliminary plans for the Program Increment. They share what features they intend to work on, their capacity estimates, and any identified dependencies. This presentation allows teams to inspect their plans collectively and receive early feedback from other teams and stakeholders.

Management Review - following the I&A session, there is a management review phase where leadership and stakeholders provide input and feedback on the proposed plans. This is a critical step where any misalignments or issues can be addressed and resolved. It ensures that the plans align with strategic objectives and organizational priorities.

Problem-Solving Workshop - in the problem-solving workshop, teams address any significant issues or challenges that have been identified during the planning process. This workshop is an opportunity to collaboratively find solutions to problems, remove roadblocks, and ensure that the plans are feasible and executable. Problem-solving at this stage helps prevent potential bottlenecks and delays during the Program Increment.

PI Objectives and Metrics - the final step of Day 2 involves setting clear PI objectives and metrics. Teams define what success looks like for the Program Increment and establish measurable objectives that align with the larger strategic goals. These objectives and metrics serve as a compass for the upcoming work, providing a clear definition of what teams are striving to achieve.

What to include in PI planning agendas?

Business Context Presentation:

Overview of the strategic context and themes

Communication of key organizational objectives

Presentation of strategic priorities for the Program Increment

PI Objectives:

Clear and specific PI objectives that align with the strategic context

Measurable outcomes and success criteria associated with each objective

Team Breakout Session:

Allocation of time for teams to review features and user stories

Discussion of dependencies, technical considerations, and scope

Opportunities for teams to ask clarifying questions

Inspect and Adapt (I&A) Session:

Scheduled time for teams to present their preliminary plans

Availability of feedback channels for other teams and stakeholders

Facilitation to ensure a structured and efficient I&A session

Management Review:

Defined time for leadership and stakeholders to provide input and feedback

Mechanisms for addressing misalignments or issues

Ensuring that plans align with strategic objectives and priorities

Problem-Solving Workshop:

Allocation of time for addressing significant issues or challenges

Facilitated discussions to identify solutions and mitigation strategies

Ensuring that plans are realistic and feasible

PI Objectives and Metrics:

Dedicated time for teams to set clear PI objectives

Discussion of how success will be measured

Alignment of objectives with the larger strategic goals

Post-PI planning

The conclusion of the two-day SAFe PI planning event marks the beginning of the Program Increment. However, the journey doesn't end here. Several post-PI planning activities are essential for ensuring the successful execution of the plans:

Execution - teams begin working on implementing the plans outlined during the PI planning event. They execute their work according to the commitments made and strive to deliver value to customers.

Inspect and Adapt (I&A) - regular I&A sessions continue throughout the Program Increment. These retrospectives and problem-solving sessions allow teams to reflect on their progress, identify areas for improvement, and adapt their plans as needed to optimize their performance.

Customer Feedback - continuous gathering of customer feedback is integral to the Agile mindset. Teams should actively seek and incorporate feedback from customers and end-users throughout the Program Increment. Customer feedback helps teams refine their work and ensure that it aligns with customer expectations.

Demo and Review - at the end of the Program Increment, teams conduct a demo and review session. During this, they showcase completed features and functionality to stakeholders, providing a tangible demonstration of the value delivered. This not only validates the work but also serves as an opportunity to gather additional feedback and make any necessary adjustments.

Improve your scaled agile capabilities with SpiraPlan

In the realm of software development, scaling Agile for large enterprises is crucial, and SAFe PI planning aligns teams and delivers value efficiently.

SpiraPlan offers a comprehensive solution, seamlessly integrating requirements management , release planning , task estimation, and defect tracking from day one. It enables unified program backlogs, allowing you to plan program-wide capabilities with features from multiple projects, ensuring alignment and transparency. SpiraPlan is also methodology-agnostic, adaptable to any scaled Agile approach , including SAFe, Nexus, Scrum of Scrums, or your own custom methodology.

To learn more about SpiraPlan and how it can improve your agile software development processes please:

Take a tour of the available features

Read testimonials from customers

Sign up for a 30-day trial to try it out for yourself

safe scaled agile

Spira Helps You Deliver Quality Software, Faster and with Lower Risk.

And if you have any questions, please email or call us at +1 (202) 558-6885

Are you looking for a platform that helps you deliver better software, faster?

• Integrations
• Testimonials
• Documentation
• System Requirements
• Add-Ons & Downloads
• RemoteLaunch® Centralize Your Automated Testing in Spira
• TaraVault® Integrated Git Code Management for Spira
• SpiraCapture Capture Exploratory Testing Sessions, Safely
• Data Synchronization
• SpiraApps™
• Accelerators Speed up your deployment and adoption of our products
• Free Trials
• Cloud Services
• On-Premise Solutions
• Case Studies
• Product News
• Micro Focus ALM
• Atlassian Jira
• Microsoft Azure DevOps
• HP QualityCenter
• Aviation & Aerospace
• Healthcare & BioTechnology
• Education & Non-Profit
• Energy & Industrial
• Government & Defense
• Telecommunications
• Financial Services
• Information Technology
• Media & Entertainment
• Retail & Consumer Goods
• Transportation & Hospitality

Methodologies

• Extreme Programming
• Scaled Agile
• Waterfall & Hybrid
• Robotic Process Automation (RPA)
• Load Testing with JMeter
• OpenText / Micro Focus
• IBM Rational

To ensure your satisfaction, we provide product support free with every subscription purchase, which guarantees you unlimited access to our knowledge base, customer forums and helpdesk. Review our support policy .

Knowledge Base

The Inflectra knowledge base includes a wide variety of helpful support articles written by Inflectra's customer support specialists.

Discover great tips, discussions, and technical solutions from fellow customers and Inflectra's technical experts.

If you can't find the answer you're looking for, please get in touch with us: over email, phone, or online.

Thought Leadership

• Whitepapers
• Background Topics
• Presentations
• Tool Listings
• Differentiators
• Leadership Team
• Culture & Values
• Opportunities
• Global Technology Initiative™

News & Events

• Company News
• Press Releases
• Partnerships Home
• Solution Partners
• Technology Partners
• Become a Partner
• Legal Notices
• Security Info
• Privacy Policy
• Licensed Patents
• Responsible Disclosure
• Environmental Impact
• Cookies List

Introduction to SAFe PI planning

Lucid Content Team

Reading time: about 8 min

Companies are always looking for ways to streamline operations and improve time to market. As companies grow, it can be harder to coordinate work among many different teams. This is where Program Increment (PI) planning comes in.

Let’s discuss what PI planning is, how it unifies multiple teams to work toward the same goals, and how to prepare for and run your PI planning meetings.

What is PI planning? 

PI planning is integral to ensuring that large corporations can work within an Agile framework. Here are a few terms that are used throughout this article that can help you understand how PI planning fits into an Agile environment.

Scaled Agile Framework (SAFe): A set of procedures and practices designed to help large organizations with multiple teams to be more agile. Its aim is to unify multiple groups to collaborate, be more flexible, have greater transparency, and align project strategies and goals.

Agile Release Train (ART): A team that is made up of Agile teams. This cross-functional group of 50 to 125 people who work on the same project. The members of the ART are aligned to a shared business and technological mission. This team plans and commits to the work that will be completed in the PI.

PI planning: An activity with the intent of ensuring that the ART is on the same track moving in the same direction. PI planning events are face-to-face meetings held every eight to 12 weeks after the previous PI. Multiple teams come together to plan and define the work that needs to be done, review backlogs, discuss which features will add value, create or update the product roadmap, and identify risks and dependencies.  

What is the goal of the PI planning event?

Often in large companies, there is a tendency for different teams to work in silos with little or no communication unless a problem arises. Senior management and the executives may be in alignment and share a vision for the company, but that vision can get lost in translation as it is communicated down through the various levels of management.

PI planning opens the lines of communication among various teams and asks that all teams agree on the direction the business is taking.

In addition to opening lines of communication, the goal of a PI planning event is to: 

Create an Agile Release Train (ART). The ART aligns vision, planning, risks, and dependencies among the various teams to focus on fast, flexible development and release.

Plan and update the product roadmap.

Define Agile SMART goals or objectives. Following this acronym, these objectives should be specific, measurable, achievable, relevant, and timely.

Create a program board so all teams and stakeholders can have an easily accessible visual summary of the goals, features, risks, dependencies, and timelines defined in the program increment plan.

Benefits of PI planning

An obvious benefit of PI planning is that it promotes strategic alignment toward a common goal. In addition, PI planning helps companies:

• Establish open and face-to-face communication among all teams and stakeholders.
• Agree on common goals, vision, and objectives.
• Effectively plan each team’s work for the PI time period.
• Have a better understanding of their individual roles and how they align with the PI plan’s vision and business goals.
• Identify risks and dependencies and ensure that team members know who to contact when they need help.
• Collaborate among cross-functional teams.
• Increase business production.
• Keep focused and on track.

Steps of PI planning

PI planning sessions cannot be completed in one afternoon. These events are typically scheduled for two days and require a significant amount of preparation before the event and can benefit from post-event review to make improvements for the next PI.

Step 1: Pre-PI planning and preparation

Pre-PI planning events ensure that the teams for the train are set up, the necessary people have been invited, and the facilities and location are scheduled and ready to go.

You will need to prepare for the PI planning sessions in the following areas:

Organizational readiness: PI planning events need to be scheduled early enough to ensure that all team members, leaders, and stakeholders can make arrangements to attend. Your organization may consider making this a regular quarterly meeting so it’s already on the schedule. In addition, the organizers should prepare a common planning scope and context and assemble Agile teams.

Content readiness: Ensure that senior leadership has prepared a clear vision and context and is prepared to present this information.

Facility readiness: Find and schedule a large room that can accommodate all participants. The room needs to be big enough so that teams can move around and hold their breakout sessions. If team members cannot be physically in attendance, make sure that all connections are ready so people can participate and contribute remotely.

Step 2: Create a PI planning agenda

SAFe suggests the following standard agenda for your planning sessions.

8:00 a.m. to 9:00 a.m.

Business context Senior management lets the ART know how the business is doing in relation to market and consumer needs.

9:00 a.m. to 10:30 a.m.

Product/solution vision Product managers present the business vision for the upcoming PI.

10:30 a.m. to 11:30 a.m.

Architecture vision and development practices IT infrastructure improvements that will improve the time to market are outlined.

11:30 a.m. to 1:00 p.m.

Planning context and lunch The release train engineer (RTE) outlines the planning process and communicates the meeting outcome expectations.

1:00 p.m. to 4:00 p.m.

Team breakout sessions Teams look at the planning boards to estimate the capacity to accomplish the tasks in each iteration. Digital planning boards that can be accessed by remote team members are ideal to ensure that all team members can work on the same document at the same time.

4:00 p.m. to 5:00 p.m.

Draft plan review Teams create a draft of their plans for the PI and present to get feedback from business owners, product owners, stakeholders, and other teams.

5:00 p.m. to 6:00 p.m.

Management review and problem-solving The RTE and management teams address issues that are identified in the draft plans. This meeting should result in a new set of priorities and/or features that the teams can use on day two.

Planning adjustments Management communicates any changes in scope, people, and resources made in the problem-solving meeting. 

9:00 a.m. to 11:00 a.m.

Team breakout sessions The teams regroup around their planning boards and develop a new plan based on the adjustments made by management.

11:00 a.m. to 1:00 p.m.

Final plan review and lunch Each team presents its plans and identifies risks and dependencies.

1:00 p.m. to 2:00 p.m.

Program risks The teams address the risks that were identified in the final plan review meeting and determine how or if they can be overcome.

2:00 p.m. to 2:15 p.m.

Confidence vote All objectives are known and all risks have been identified. Teams vote on their confidence in accomplishing their PI objectives. Team members hold up one to five fingers to vote. One or two fingers indicates that the team needs to rework the plan and vote again.

2:15 p.m to finish

Plan rework (if needed) This time is used to rework the plan to address items that got less than a three-finger vote.

Planning retrospective and moving forward The RTE holds a small retrospective to determine what went well in the PI planning sessions and what could be improved for next time.

Step 3: Post-PI planning

Post-planning sessions are used to integrate the results from the PI planning meetings into the vision and roadmap. At the end of the PI, everybody involved should agree on objectives to be implemented and demonstrated at the next solution demo.

As companies grow and have a larger global footprint, teams are much more globally distributed. SAFe PI planning makes it easier for large organizations to work in an Agile environment by aligning multiple teams to work toward the same goals in a scheduled, timeboxed process. Digital planning tools help to bring global teams together in virtual meetings to participate in planning sessions that define work that needs to be accomplished in each PI. 

Learn more about how a SAFe program board works and how you can use one effectively.

Receive product tips and expert advice straight to your inbox.

Topic: PI Planning

6 pi planning tips for rtes.

Five years ago, I had the opportunity to participate in the 5 Things I Wish I’d Known before My First PI Planning video series for piplanning.io . Now, I’m reflecting on those tips and sharing them in this blog.

My journey with SAFe® started with SAFe 2.5. Since then, I’ve enjoyed coaching and mentoring other coaches and leaders. 

As an RTE, I’ve had the chance to facilitate PI planning and coach others to take over that role. While facilitating and coaching, I identified six key tips that created the smoothest PI planning experience for everyone. 

Here they are:

• Communicate the core message
• Plan social activities  
• Be mindful of the start time
• Prepare, don’t over-prepare
• Cleary visualize features
• Take care of basic needs

PI Planning Tip 1: Communicate the Core Message

In the standard agenda , the first half-day of PI planning focuses on the vision, desired deliverables for the PI, features, and architecture.

As the RTE, it’s important to check that the messages from management, including executives, are inspiring and motivational. These speeches should reflect on achievements from the previous PI, address the current state, and provide insight into the organization’s future, specifically how the organization will contribute to building that future in the next PI. 

It’s helpful to review and rehearse the message while supporting effective storytelling. Think of a traditional story arc. Assign you and your customers to a specific role and place in the story. Are you the hero or is the customer the hero while you’re the fairy godmother? What obstacles have you helped your customers overcome? What happy endings have you or your customers created? Sequencing your presentations in this way (if only loosely) will make it easier for your audience to connect with your organization’s purpose.     

One important ingredient of effective storytelling is an executive who knows the customer and the business. They can create a truly captivating story based on real experience in the field. Put yourself in your customer’s shoes and share the story or problem you’re trying to solve from their perspective. This will capture the audience and show your people exactly what they helped create for your customer or will create in the upcoming PI. 

In summary, follow these pointers to create a core message that resonates with teams. 

• Do a rehearsal beforehand to ensure smooth transitions between segments
• Support storytelling from one presentation to the next
• Share customer success stories or examples from the field
• Invite executives who know the customer and business to present and tell the story

PI Planning Tip 2: Plan Social Activities

Between days one and two, organize an activity like a fox trail or a bowling night. This unstructured time allows people to connect, converse, and build relationships. 

However, it’s important to remember that there is still a second day of PI planning. Do not party too long!

Social activity ideas:  

• Bowling night
• Escape room 
• Team dinners featuring local and international foods

If you don’t want to use outside work hours for social time, you can add icebreaker activities to the PI planning agenda. These are short, no more than 10-minute activities that allow people to learn about each other in a different context than work. However, it’s important to note that icebreaker activities don’t work in all cultural contexts, so use discretion when deciding whether or not to include them. 

Here are some quick icebreaker activities:

• Chat surveys or questions: Use the survey tool that comes with online meeting applications like Google or Zoom to poll the group on things like their favorite candy 
• Breakout groups/partners to answer a question or share favorites
• Rapidfire, round robbin question and answer (better in smaller groups): Ask the group a series of “This or that” questions (for example, horror or mystery?)
• Get to know you Bingo: Give everyone a card with different traits listed on it, like “Owns a dog” or “Has lived abroad;” during breaks, fill out your card with people who have those traits until someone shouts “Bingo” when they get five boxes checked in a row on their board

You can even get creative and pick an activity that matches your PI planning theme . 

Because virtual PI planning is here to stay, we need to get creative with social activities you can do from afar. Plan time for structured exchanges and organize remote socials.

During Covid, we had “blind dates” during lunch for those who did not want to eat alone. Participants were assigned to another teammate to dine with. This meant they socialized via video call during their lunch from the comfort of their own kitchens.  

Human interaction is important, and PI planning is a great opportunity to get everyone together, even virtually, to create relationships that make collaboration a seamless and enjoyable experience.

PI Planning Tip 3: Be Mindful of Start Time

During the first half day of PI planning, a lot of conversations take place. My SAFe experience is primarily in Europe, particularly Switzerland and Austria, where many people take public transportation to work. Therefore, it’s important to be mindful of the start time. Beginning at 8:00 in the morning might not be suitable as people often travel by train or bus. Starting around 9:00 A.M. allows for a more feasible and effective schedule.

Additionally, it’s common for fatigue to set in during the first half day, potentially due to cultural factors. Different cultures practice different presentation methods. This means some cultures are more tolerant of longer presentations than others. 

To maintain high energy levels, it’s beneficial to keep some talks shorter and initiate breakouts earlier than the proposed agenda . 

My remote agenda is different than for on-site PI planning. In remote settings, you’ll need more breaks than you have for on-site PI planning. Plan these breaks. Ask your Scrum Masters/Team Coaches to insist on these breaks. I have 15-minute breaks on my agenda every 60 – 75 minutes. During these breaks, I ask people to stand up and leave their desks to walk around, drink water, and do something physical. Remind your Scrum Masters/Team Coaches to do the same in the breakouts.

PI Planning Tip 4: Prepare, Don’t Over-Prepare

When preparing for PI planning, there are two approaches: A) Going in without stories and focusing on known features, or B) Going in with all the stories. 

From my European experience, starting with fewer prepared stories yields better results.

Over-preparing with excessive detail can lead to wasted time. Imagine if each team spends three days preparing stories for their “assigned” features. They might then complain that two days of PI planning is wasted because they now have nothing to do. 

The real waste lies in excessive pre-planning. What happens if the dependencies aren’t properly identified? Or if the business owner asks to reduce scope during PI planning due to a competitor’s actions? Valuable time would be wasted if the work that took time to plan is then descoped or deprioritized. 

The magic of PI planning lies in the opportunity to learn together and collaborate closely.

PI Planning Tip 5: Visualize Features

It’s important to share planning progress while teams are working. Therefore, it’s good practice to visualize features so they’re accessible to the entire organization. 

There are different ways to visualize features based on whether you plan in-person or virtual. 

To track progress and provide visibility, pin the features on a board using multiple instances and colors. For example, use two blue slips and one gray slip—all pinned over each other. When a team selects a feature, they remove the blue slips and write their names on the gray slip on the board. 

This allows the RTE, Product Manager, or Business Owner to see the progress visually. The more gray slips, the greater the progress. It also helps the team members understand who is working on what and provides an overview. The blue slips can be kept in the team area, pinned to the iteration where the feature is finished, while the other blue slip goes to the ART planning board.

You can accomplish this same goal without physical stickies if you’re working in a virtual environment.  

piplanning.io has a color-coding system for the feature stickies. Once a feature has been assigned to a team, it will change color. It will also list the name of the team assigned to the work.  

This is a simple and easy way to see which features have been planned and which haven’t.

PI Planning Tip 6: Take Care of Basic Needs

Maintaining wellbeing is crucial for a productive session. 

As the saying goes, “A hungry bear makes no tricks,” or as participants in a German implementation training described it, “Ohne Mampf kein Kampf,” which translates to “No food, no fight.” 

It’s impossible to concentrate when you’re basic needs aren’t being met. Food, hydration, and bathroom breaks are essential for productive PI planning. 

Designate someone to organize snacks, coffee machines, water, brain food, and other refreshments to ensure everyone stays energized and focused during the sessions.

If you’re virtual, ensure there’s a lunch built into the schedule and breaks during long meetings, especially during the first day. Encourage people to take breaks as needed throughout.

Now that I have dozens of PI plannings under my belt, I can safely say these six tips will provide you with a strong event that provides the right amount of certainty to an uncertain and challenging, but rewarding, experience.

In addition to these tips, here are some SAFe PI planning resources.

• piplanning.io
• PI Planning page in SAFe Studio™
• How to Run a Hybrid PI Planning Event blog
• Facilitation Tips to Excel at the RTE Role blog
• SAFe PI Planning Toolkit

About Nikolaos Kaintantzis

Nikolaos has always been driven by improving people’s working lives. As a developer, he wrote UIs that made work easier. As an organizational developer, systemic coach, and SPCT, he has added skills to that ambitious endeavor. In partnership with organizations, he develops them so both the organization and all employees benefit.

Connect with Nikolaos on LinkedIn .

PI Planning gone sideways

Pi planning gone sideways – correct your course with piplanning.io.

Explore strategies to enhance real-time collaboration and reduce cognitive load in PI Planning with our insightful webinar tailored for RTEs.

August 31, 2023, 1:00 am – August 23, 2023, 9:00 am MST

SAFe® Practice Consultant, SAFe® Release Train Engineer

Event Overview

Struggling with PI Planning? Join us for a thoughtful exploration of strategies that enhance real-time collaboration and minimize cognitive load in PI Planning.

This session is designed to be interactive and focused on providing value to participants, with an emphasis on learning and growth. Whether you’re new to the field or an experienced RTE, we invite you to join us in this informative webinar.

Highlights include:

Real-Time Synchronization: Explore how bi-directional sync with ALM tools can eliminate delays, fostering efficient communication and information sharing.

Effortless Planning to Execution: An exploration of methodologies that ensure a smooth transition from planning stages to actionable execution, keeping aligned with overall objectives.

Collaboration Beyond Boundaries: Insights into tools and practices that enable effective collaboration, regardless of location.

Smart Visualization: Get insights into optimal planning through visual aids that guide, rather than dictate, the planning process.

Silvio Wandfluh

Senior Director, Product, SAFe Enterprise Applications

With a focus on customer success and a user-first approach, I leverage my expertise in product/market strategy and execution to deliver tangible results that delight end-users and propel the business forward. Whether it’s identifying pain points, uncovering unmet needs, or discover hidden opportunities, I thrive on the challenge of creating innovative and impactful products that customers love.

Rosana Johnson

SPCT Candidate / SAFe Strategic Advisor

Rosana has twenty-five years of experience and is a successful result driven leader. She has an extensive background in transforming people, systems, tools and processes. Her expertise ranges from creating deliverables for complex tooling deployments to transforming teams to agile ways of working to drive productivity while delivering a solid customer/employee experience by accelerating time to market and ensuring quality and business agility.

Your Guide to Writing Great Iteration and PI Objectives

Agile is disciplined; not reckless.

Writing useful Iteration Goals and Planning Interval (PI) Objectives requires focus and discipline to achieve proper agility transformation. Bad objectives are one of the most common reasons organizations stop using them. This guide will help you write objectives that get results.

For simplicity, I will use “objectives” interchangeably when talking about iteration goals and PI objectives. Iteration goals are a scaled-down version of PI objectives, which means you can apply my guidance to both metric types.  

Why We Write Iteration and PI Objectives

Before you can write effective iteration and PI objectives, you must understand why we write them. It’s common for organizations to treat objectives as summaries of the features or stories teams commit to in the PI or iteration. But that is a misunderstanding of the objectives’ purpose.

Objectives represent the Agile Team’s commitment to delivery in the PI or iteration. They create a feedback loop from the business to the team. This loop ensures both parties understand the organizational vision:

• Teams can confirm their understanding of the business’s desired outcomes
• The business can clarify or further refine its value priorities

During an iteration or PI Planning, teams neither commit to all the features brought to PI Planning nor to whole features. So it’s important to understand what outcomes the features create. This gives everyone a chance to weigh in on those outcomes.

How PI Objectives Support PI Planning

At PI Planning, the business gives its prioritized feature list to the Agile Release Train (ART). Then, teams on the ART sequence their stories and features based on their priorities and capacities.

During this process, teams will only commit to a subset of the business requests. PI objectives ensure teams commit to the proper subset of the business’s requests. Business value scores and conversations with business owners and key stakeholders also support team commitments.

Teams can then sequence stories and features into a delivery plan that leads to business outcomes. They communicate this plan through the objectives and summarize the business and technical goals in language the business understands. It’s much more than a summary of the planned work.

Another benefit of well-written objectives is they create an opportunity for alignment. Teams should be able to connect their features and stories to the highest value objectives. This makes it easier for the team(s) to see if they’re doing the most valuable work first. If not, they need to address priorities or technical dependencies.

How PI Objectives Are Evaluated by Business Owners

Besides understanding what objectives are for, we must also consider who objectives are for.

Teams write iteration and PI objectives for the Business Owners and key stakeholders. Teams do not write objectives for the Product Managers and Product Owners (POs) who manage the backlogs. The Product Managers and POs know what work they asked for.

Objectives communicate which business outcomes the team contributes to and why they matter . Teams then understand the deeper purpose behind their work, thus helping employee engagement. 

Business Owners evaluate PI objectives at the end of the PI to help the ART measure its performance and business value achieved. This helps determine ART predictability . 

One caveat to note: uncommitted objectives do not count towards a team’s predictability measure. Therefore, it’s important to write uncommitted objectives during PI planning to demonstrate that the team plans to complete the work but understands there are factors out of their control that may prevent them from delivering the value named in the objective. 

Near the end of PI planning, the Business Owners assign a business value to each PI objective. The business value is a number between 1 (lowest) and 10 (highest). Business Owners quantify the value of PI objectives through a conversation with the team. To determine the business value, they consider questions like

• Is the work customer-facing?
• Will the work improve future velocity and value delivery?
• When will the value be delivered? 
• How much of the organization will contribute to the objective?
• How large will the impact be if the objective is not completed in the PI?

Once the PI is over, Business Owners assign Actual Business Value to the PI objectives. Actual Business Value is the amount of value that was delivered toward the objective in the PI.

For example, if one of your objectives was assigned a business value of 7, Business Owners will decide based on the team’s completed work how many of the 7 points were delivered. Like in PI planning, the scores are determined through conversations between the team and Business Owners. 

The structure of your PI objectives impacts how smoothly the Actual Business Value assignments go. Well-structured and clear objectives help Business Owners and teams easily measure what was delivered in the PI. The tips in the following sections outline how to write objectives Business Owners and teams will understand.

How to Write Meaningful Iteration and PI Objectives

Now that we’ve identified what objectives are and who they’re for, let’s inspect some PI objective examples from the field.

• Implement Jenkins
• Build 2 APIs
• Build a database
• Design a template

These examples do not effectively communicate the business outcomes the work produces. Additionally, these example objectives are written solely from the perspective of development or engineering teams and have no connection to why the work matters. If the objectives just restate the names of the features, they are a waste of time and energy.

Let’s review how to write objectives that create a meaningful connection between the technical work and the business.

First, all objectives should be S.M.A.R.T .

Second, a good objective has five components that effectively communicate a business outcome and why it matters:

• Activity : What will we be doing?
• Scope: What are the boundaries of the work we will touch?
• Beneficiary: Who is the intended recipient of the new work?
• User Value: Why does this work matter to the new user?
• Business Value: Why does this work matter to the business?

Examples of each component include:

• Activity : Create, Implement, Define, Design, Enable, Modify, Etc.
• Scope : App, API, Mobile, Web, Database, Dashboards, Etc.
• Beneficiary : Customer, End-user, System Team, Mobile Users, Etc.
• User Value : Faster, Better, Cheaper, Enhanced, New Features, Etc.
• Business Value : Reduced Call Times, Increased Sales, Increased Data Efficacy, Reduced Loss to Fraud, Etc.

You can put these two steps together using the following formula.

Iteration and PI Objectives Examples from the Field

Here are a few examples of good iteration and PI objectives from three different contexts.

Financial services company example

• Activity : Add
• Scope : three new methods of e-payment
• Beneficiary : so that mobile users with digital wallets
• User Value : have an improved checkout experience
• Business Value : to drive a three-percent revenue increase

“Add three new methods of e-payment so that mobile users with digital wallets have an improved checkout experience to drive a 3 percent revenue increase.”

Digital transformation team example

• Activity : Create
• Scope : an Agile Ways of Working guide
• Beneficiary : so that {Company} employees
• User Value : have clear guidance on implementing Agile behaviors
• Business Value: to enable a faster flow of value with higher quality delivery

“ Create an Agile Ways of Working guide so that {Company} employees have clear guidance on implementing Agile behaviors to enable faster flow of value with higher quality delivery.”

An example from a team building a new customer data platform

• Scope : a single source of truth customer database
• Beneficiary : so that customers who call us
• User Value : have an improved customer experience
• Business Value : with a 25 percent shorter time to resolution

“Create a single-source of truth customer database so that customers who call us have an improved customer experience with a 25 percent shorter time to resolution.”

Using the above approaches creates a powerful statement of business value. And it creates greater alignment between the teams’ work and business strategy. Tip: teams can write their objectives using the bulleted format to make them even clearer.

Find More Objectives Resources in SAFe® Studio

Iteration and PI objectives create feedback loops between the teams and the business. They also assess how well the team’s work aligns with organizational goals. When you understand this connection, you can improve your implementation of these objectives.

If you have objective-writing stories, good or bad, in your organization, share them with me. Together, we can improve this process for everyone.

Objective-writing resources in SAFe® Studio:

• Tactical Tuesday: Iteration Goals and PI Objectives podcast
• Measuring Business Value – PI Objectives Overview video  
• Smarter S.M.A.R.T. Objectives video  
• Shared Objectives and Collaborative Sense-Making: Key to Success blog
• Assigning Business Value During PI Planning video

About Saahil Panikar

Saahil is a SAFe® Practice Consultant Trainer (SPCT) and certified Enterprise Business Agility Strategist. He is determined to help organizations extend their Agility beyond IT. He started his career as a Data Scientist, and Saahil is still passionate about the metrics behind successful transformations. As a former collegiate rugby player for the University of Florida, Saahil bleeds Orange and Blue and is a die-hard fan of Gator Football. Connect with Saahil on LinkedIn

How To Run a Hybrid PI Planning Event

As we approach 2023, you’re probably mulling over your next PI Planning event. Will it be in person? Will it be remote? Will it be something in between? How will that look?

Before 2020, most organizations held PI Planning events in person, but COVID-19 forced an abrupt shift to remote/virtual events. However, in recent months it has become clear that many organizations have fundamentally changed, and a new hybrid format is necessary. This hybrid format brings many challenges around facilitation, tools, and collaboration.

We just held our first hybrid PI Planning event at Fred IT Group . I wrote this blog post based on that experience. In this post, I discuss the following:

• The four types or formats of PI Planning
• The main challenges of hybrid PI Planning
• How we prepared for our first hybrid PI Planning event
• My key learnings as the Release Train Engineer for our first hybrid event

PI Planning Four Different Ways

Before we go any further, it is essential to define the four types of PI Planning that are now commonly occurring: 

• In-person PI Planning  — Everyone on the Agile Release Train (ART) is in one location (collocated). The planning is done face-to-face, in “a big room”, using physical tools. This format was the recommended and most common format before COVID-19.
• Distributed PI Planning (Scenario 1)  — Teams are collocated but distributed from other teams on the ART. This scenario occurs when teams are based in different countries or states, and it is impractical for them to travel. 
• Distributed PI Planning (Scenario 2)  — Individuals are distributed, and there are no common or shared locations. Everyone joins remotely (typically from their homes), so facilitation is carried out using digital tools exclusively. This scenario is sometimes called remote, online, or virtual PI Planning. This format became prevalent in 2020 due to COVID-19.
• Hybrid PI Planning  — A subset of the attendees are located in the same place (a large meeting room). Other participants join remotely from individual locations (their homes). Teams may have a mix of in-person and remote attendees. Facilitation and tools are therefore needed to accommodate both types of participants throughout the event. Due to increased flexible working arrangements and remote-first hiring, hybrid PI Planning is likely to become increasingly common. 

Although they might seem similar, there are key differences between distributed (scenario 1) and hybrid PI Planning. In the distributed scenario, the ART is spread across a few locations only, with a facilitator at each. Teams with strong dependencies will ideally be collocated, so most key interactions are still in-person. In hybrid PI Planning, there is one group in a central location and individuals joining from dozens of remote locations. This context is much more complex as all interactions are potentially a mix of in-person and remote. Additionally, hybrid events carry a unique challenge around ensuring that the in-person subset (effectively the largest group) does not disproportionally dominate the event.

The Challenges of Hybrid PI Planning

We suspected that hybrid PI Planning would likely need to differ from the in-person and distributed events we had previously held. Some of the initial questions that we knew we would have to address were:  

• How do we facilitate the event so as not to privilege people in the office over people at home? or vice versa? 
• How do we create equal opportunities to participate? 
• How do we help people returning to the office feel safe at their first large-scale work event in several years?
• What are the challenges for people who have only attended fully remote, distributed PI Planning events?
• What are the logistics of a hybrid event? 
• What tools and equipment are needed? 
• Do we use any physical tools? Or do we exclusively use digital tools?
• How do we ensure that everyone can hear and be heard? And see and be seen?
• Do teams do their breakout planning in the “big room”? Or do we need to provide physical breakout rooms? How do we help foster cross-team collaboration if the latter? 
• How do we communicate expectations?
• How do we support our team facilitators ( Scrum Masters )?  

These questions are mainly looking to answer a broader one: How do we create an event that values and includes both in-person and online participants equally in a shared experience?

How We Prepared for Our First Hybrid PI Planning Event

Having established that hybrid PI Planning would involve unique challenges, we made some critical decisions and took the following steps to prepare.

Communication and alignment with the teams

Several weeks before the hybrid event, we held a meeting with the ART to share our plans and offer the team members a chance to ask questions or provide feedback. This pre-work helped us set expectations and create alignment. We also made and distributed an information pack, which contained information such as: 

• Floor plans and locations of the team breakout rooms
• Instructions on how to use video conferencing equipment 
• Facilitation tips 

Collaboration tools

We decided to primarily use digital tools over physical ones. We knew our remote team members would not be able to see or contribute to physical boards. We used Miro for whiteboards, Mentimeter for polls (including confidence votes) and feedback, and MS Teams for calls.

Facilitation

In our Scrum Master Community of Practice , we ran a Futurespective workshop (AKA Pre-mortem Workshop ) where we discussed what the worst and best hybrid PI Planning event would look and feel like. This helped our Scrum Masters anticipate issues, find solutions, and discuss the best outcomes.

Moving team breakouts out of the big room

During in-person PI Planning, the entire event usually takes place in a single big room. Given the hybrid setup, we realized this would not work well for the team breakout sessions. So we booked individual breakout rooms for each team instead. We then used the main room for sessions with the entire ART, such as the Business Context and Plan Reviews. 

Testing equipment

We spent significant time testing the equipment in both the main and team breakout rooms before the event. We also had backup plans in case of equipment failure.

My Key Hybrid PI Planning Learnings as Release Train Engineer

The two days were pretty intense, and we learned a lot. We collected feedback throughout the event so that we could continually make adjustments. We collected in-person feedback on physical boards and remote feedback on a digital board. This ensured we understood the context of the feedback we received. Keep reading for some of our key learnings.

Quality of internet connection and audio/video

Two of the most important success factors for a hybrid event are a stable internet connection and clear sound and video. We had a great audio and video setup, but unfortunately, the internet connection was poor in our main room on day one. After receiving feedback from our online participants, we moved to a location with a better internet connection for day two.

Consider what you share on the screen

We discovered during the main group sessions that it was really important that both the in-person and remote participants could see:

• The screen share
• The chat window
• The videos of the other participants 

If the chat window was not visible for in-person participants, they were not able to follow some of the conversations that were happening online.

We also realised it was important the online participants could see all the people in the room, not just the people presenting. Likewise, it was important for in-person participants to see the videos of the people online.

Microphone use and etiquette 

Most of us were not accustomed to using microphones and struggled to hold them consistently at an appropriate distance (myself included). In-person attendees needed occasional reminders to wait for a microphone to reach them before speaking so that online participants could hear them.

It had been several years since most of us had attended a large-scale work event in person, and many people understandably felt quite nervous. We chose to acknowledge this in the opening address, which I think helped calm nerves and establish an appropriately supportive environment. 

The social benefit

One thing that was universally agreed on was that it was great to get a chance to meet or reconnect with all of our colleagues. We provided coffee, snacks, and lunch so people could spend their breaks socializing and not searching for food.

It takes a team

I learned that it takes a team to pull off a good large-scale hybrid event. If you are the RTE facilitating hybrid PI Planning, find people who can assist you with AV setup, office logistics, tech support, etc. It’s far too much for one person to attempt on their own.

Tips and Resources for Release Train Engineers Facilitating Hybrid PI Planning

Facilitating PI Planning as a hybrid event is a lot of work, particularly the first time around, but it is definitely worth trying. Although we are still learning, my key takeaways so far are:

• Be intentional in how you design and facilitate the event, and do not underestimate the work required.
• Expect to learn a lot and to make adjustments and improvements as you go.
• Make sure you focus on both perspectives, in-person and online. Be extra mindful of the experience you are not having!
• While we still value flexible working arrangements, the communal and social benefits of coming together for PI Planning are real, tangible, and significant. 

Additional Resources

• Distributed PI Planning article
• Remote PIs, ARTs, and Teams podcast
• Learn How Planview Executed a Successful Virtual PI Planning blog post

Resources for SAFe® Community members

• SAFe Virtual PI Planning workshop
• SAFe Remote ARTs toolkit 
• Remote PI Planning and I&A Facilitation webinar recording

About Tom Boswell

Tom Boswell is an Enterprise Agile Coach and certified SPC and RTE. He has worked at multiple organizations using SAFe, coaching at the team, program, and enterprise levels. He is passionate about lifelong learning, helping others grow, empowering teams, and co-creating more meaningful workplaces. Connect with Tom on LinkedIn or at www.tomboswell.com .

Year in Review for Release Train Engineers and Scrum Masters

Events > Webinars > Year in Review for Release Train Engineers and Scrum Masters

Year in Review for Release Train Engineers and Scrum Masters

Review features released in 2022 specifically for Release Train Engineers and Scrum Masters to succeed in 2023.

December 13, 2022, 9:00 am – December 13, 2022, 10:00 am MST

Release Train Engineer, Scrum Master

This interactive session walks through updates with the Scaled Agile Product team to cover the following releases: Updated SASM Course Role-Based Home Page PI Planning in Collaborate Collaborate Improvements PI Event Facilitator Guides (ART & Team Events)

How Does a Scrum Master Coach a Team with More Experience Than Them?

I’ve found myself in many different contexts throughout my career as a SAFe scrum master:

• Multimedia 
• Instructional design 
• Marketing 
• Globalization 
• Data analytics

Make no mistake. I am neither an animation artist nor an instructional designer, nor a digital marketer, nor fluent in a second language, nor can I write SQL (or any code for that matter).

So how do I effectively work as a scrum master when I don’t share technical experience with my teammates? I’ll help you answer that common question by focusing on three areas: 

What does a scrum master do?

What if i’m a scrum master without experience, setting scrum master improvement areas.

This sounds simplistic, but there’s a reason! Reviewing the basics, in this case the role of scrum master , can help reaffirm your role on the team you serve and help you clearly state it to others. 

Your goals are simple (not easy), and they often include:

• Helping the team navigate ART practices and processes. In doing so, the team can participate fully and have their interests, concerns, questions, ideas, and voices heard. This is especially true for new team members. Everyone will need time and support to adjust to a new way of working, no matter their experience level. Scrum masters are a little bit like the glue that holds cross-functional teams and ARTs together.
• Allowing teammates to focus on execution. As experts in their domain, your team members are usually deep in the trenches of value delivery. Most other team responsibilities are shared between you, the product owner, and the product manager. This means scrum masters need to be experts at supporting the PO, PM, and other team members at defining the why, gathering requirements, prioritizing work, and knocking on doors to unblock progress.
• Being a champion of relentless improvement. You should help define success metrics, measure the team’s value delivery, and create a forum for the group to view and discuss the results. Teams might think they’ve defined value delivery well, but scrum masters are uniquely positioned to provide essential perspectives from the ART, customers, business owners, and other teams. Aside from objective metrics, you can also discuss qualitative experiences like team dynamics . In partnership with the product owner, you can create a system to start incrementally improving. The organizational value realized from increasing and sustaining employee participation is always significant.

The full SAFe® scrum master article has more extensive guidance to help you define role expectations and responsibilities. As a quick reference, the image below will help you visualize three core areas where any scrum master can immediately start to add value.

Does this work require you to know what the team is making and how? Yes, to an extent. But it often doesn’t require the depth of specialized knowledge needed to build end solutions. In fact, another voice with the same experience and biases might only add to a myopic perspective and goals.

Starting as a scrum master without experience is a little overwhelming.

When it feels like too much, there are some foundational concepts you can use to stay grounded and help your team succeed.

Below are three key reminders for scrum masters that are new to their role or serving an experienced team in an unfamiliar domain.

1 | The team is expert in their way, you are expert in your way

To coach a team effectively, you need to understand and maintain focus on:

• The team’s value flow
• Typical bottlenecks
• Impediments to high quality

The rest is simply nice to have. Understanding flow, bottlenecks, and quality will allow you to quickly grasp what holds the team back and how they achieve success. This will also help you relate to your team’s emotional dynamics, including what makes them personally frustrated or fulfilled. Empathy will break through differences in experience levels and foster lasting relationships.

If you’re still skeptical, think of it this way; the product owner is backlog and content authority for the team. They still do backlog refinement with the team. Why? Because team members are the experts! That’s their thing. That’s why they were hired.

A scrum master isn’t an expert in the same areas. That’s not their job. Their job is coaching and enhancing the PDCA cycle, customer centricity, flow, dependency visualization, bottleneck identification and removal, conflict management, and listening.

2 | Build initial trust levels with authenticity

The not-so-secret ingredient in serving any team is trust. If you share technical expertise with your teammates, building initial trust may be easier. Teammates will know that you understand their impediments and have insight into root causes because you may have experienced them before. Your coaching may be well received because “you know what you’re talking about,” and teammates can immediately talk shop with you.

There may be some initial distrust if you don’t share technical knowledge with your teammates and they don’t understand how you contribute. If this situation sounds familiar, it’s best to start with openness about your background and willingness to learn. Emphasize that you’re not a technical expert but you do fill many other roles that help them work better, including:

• Servant leader
• Live-in consultant
• Team protector

Your expertise starts with process, method, and people.

Trust is particularly key when your work environment prioritizes honesty, candid feedback, and personal responsibility. Technical competency is a must for most roles, but emotional intelligence and interpersonal skills are vital for helping teams and individuals thrive. Organizations using SAFe should create ample space for digging into messy issues, feedback, processes, and team performance. Scrum masters can build trust in these complex emotional environments in several critical ways: 

• Help everyone approach discussions in good faith
• Create a safe environment for all feedback
• Find and equip team members with the right tools and methods to provide feedback
• Encourage participation by all; not only the loudest or most persistent voices
• Communicate feedback clearly to others, demonstrating advocacy for the team

3 | Promote self-organizing teams

A scrum master’s best tools are powerful questions and intentional listening. If you share deep technical expertise with your teammates, you may have a bias when determining problems and solutions.

You might make more assumptions and be more suggestive because you have so much familiarity with the team’s work. Scrum masters without technical experience have the benefit of an outsider’s perspective and have no choice but to truly listen, clarify, and guide the team to their own solutions.

It’s helpful to build trust and develop personal relationships. But you’ll need concrete growth goals to gain competency and confidence.

The list of scrum master improvement areas below will give you a big head start in owning your role:

Identify the team’s value stream(s). The team might already have a value stream visualization. Maybe the product owner knows it well. Or maybe there’s a great opportunity for the team to work on identification. This will help both you and your team understand how work flows and the most essential tools and processes the team uses. You’ll likely find areas for immediate improvement!

Ask obvious questions. Though it might feel like you’re slowing the team down, asking foundational questions is actually beneficial for everyone. Here are just a few obvious benefits:

• You need to learn more about team content
• The teammate receiving the question needs to think about the purpose and processes behind their work
• Other team members who aren’t involved in that work may have the same question 

Schedule one-on-one meetings. Learn team member’s professional goals and interests. Ask about their pain points, what keeps them up at night, dynamics within the team, dynamics with other teams, etc. Build empathy to help smooth over inevitable future difficulties. Also, if your teammate is comfortable with it, you can ask to shadow their work while they narrate and complete day-to-day tasks. 

Always have a Google tab open. Answers to technical questions are often difficult to grasp. You can’t expect to know everything your team does. Instead of scheduling an hour lecture with a teammate every time curiosity strikes, try checking internal directories, knowledge wikis, and even Google to find a quick answer. Continuous learning is imperative.

Use an assessment to measure your progress. The AgilityHealth Scrum Master Radar Assessment (or a similar tool) can help you understand your current performance and identify areas for improvement. 

Learn more about the team’s work. This shouldn’t necessarily be your first priority, but it’s definitely worth your time. Common examples include joining a lunch book club, attending a conference, creating content that requires you to learn new material, and reading technical articles. You’ll deepen your knowledge and show that you truly care about the team’s work.

Hone your craft. Consistently prioritizing professional development will demonstrate your growing expertise to the team. Whether you’re trying new approaches to retrospectives or diligently protecting and coaching team members, your efforts will earn trust.

If you’re still unsure about exactly where to spend your time, the graphic below breaks down how real scrum masters (in our company) spend a typical week. You can use this tool as a gut check for balancing priorities, assessing your time management skills, and planning for a productive iteration.

More Resources for You, Scrum Masters!

Even with prior scrum master work experience, serving a team with technical expertise that you don’t have can feel daunting. But a skilled scrum master can quickly bring significant value. By clarifying how you serve the team, building trust, and continuously learning, you and your teammates can work together to build a self-organizing, high-performing team.

Here are some additional resources to help you learn more about how scrum masters of all experience levels can continue improving and serving well:

• Read about the scrum master role in improving team dynamics and productivity
• Learn how to assess your team’s agility from a scrum master Q&A
• See how scrum masters help handle conflict resolution
• Join the Scrum Master forum in the Scaled Agile Community Platform (available to current community members)
• Attend a SAFe® Advanced Scrum Master course

About Emma Ropski

Emma is a Certified SPC and scrum master at Scaled Agile, Inc. As a lifelong learner and teacher, she loves to illustrate, clarify, and simplify to keep all teammates and SAFe learners engaged. Connect with Emma on  LinkedIn .

View all posts by Emma Ropski

Facilitation Tips to Excel at the RTE Role – Agility Planning

I spend most of my time in the Release Train Engineer (RTE) role facilitating groups from all levels of the organization.

When I facilitate poorly, people notice, and the Agile Release Train (ART) struggles to align on objectives and mitigate risks.

When I facilitate well, meetings blend into daily work, and the ART runs smoothly.

In this blog post, I focus on facilitation tips and tools that have worked for me in agility planning with three ceremonies that RTEs facilitate:

• PI Planning
• Scrum of Scrums (SoS)
• System Demo

Let’s take a look at how I prepare for and facilitate each.

Prepare for the RTE Role in PI Planning

PI Planning is the most important event the RTE role facilitates. A well-run PI Planning aligns the ART to:

• business context

It creates the space for tough conversations about dependencies and tradeoffs. Teams have the autonomy to plan to achieve the desired value delivery within their capacity.

How to prepare for a successful PI Planning

It’s helpful for me to think about PI Planning preparation in the following sections.

Organization

This includes the tools and tips I use to stay organized before and during PI Planning.

Book calendars in advance

If you want 125 people available at the same time in the same location, you need to get dates on the calendar a year ahead of PI Planning. When I have not met this criterion, key stakeholders miss the event due to scheduling conflicts.

ART Readiness Workbook

We use an updated version of the readiness checklist in the ART Readiness Workbook. The SAFe® PI Planning Toolkit on the SAFe Community Platform includes this checklist.

It includes everything we need to prepare our teams and ARTs for PI Planning, from the program backlog to video call links. We’ve started calling it “the dream” because it keeps us so organized that the event runs like a dream.

This is how I think about the information I want to convey during PI Planning.

Business context

Work with leaders to prepare a strong business context presentation. As a facilitator, it’s my job to ensure the connection from strategy to execution is clear. That connection starts with the business context.

As an RTE, I work with our leaders to paint the picture of:

• Our progress so far
• Our priorities moving forward
• What we want to do with those priorities
• Why it matters

A motivating message will resonate with people and set the tone for the event.

Note: Leaders can be your GM for the business unit or CEO for smaller organizations.

Product strategy

The product strategy connects the business context to the prioritized backlog. It shows the research, customer feedback, and PI roadmap that will achieve our strategic themes.

This means RTEs work with the head of product to create a presentation that encourages engagement with the content. It should also include plenty of time for Q&A.

I know I’m successful when, in the Q&A, team members make clear connections between the product strategy and top features in the program backlog.

Prioritized program backlog

Our product team prepares early for the upcoming PI by:

• Understanding customer needs and desired outcomes
• Defining, sizing, and prioritizing features

This process gives teams plenty of time to understand priorities. It also helps them understand how to do the work and which features to pull first. If I have done a good job of facilitating through the business context and product strategy, the teams will have confidence in the backlog. They’ll also understand how to engage with it to achieve the most value in the PI.

How you set up impacts how your teams engage and where they focus during planning.

We use the Virtual PI Planning Collaborate template for virtual PI planning. This template allows us to set up all the things we would have on the walls if we were in person in one easy-to-use online location. It cuts down on logistical questions during PI Planning and allows people to focus on their tasks.

We spend a lot of time thinking about tables, breakout rooms, and supplies:

• Does all the in-room tech work?
• Are there clear instructions for how to use it in the room?
• Are there snacks and fidget toys on the table for idle hands?
• Plenty of sticky notes in different colors with pens and markers?

The less time people spend looking for supplies or troubleshooting tech, the more engaged and focused they will be.

Snacks and fun

Whether in person or virtual, planning for snacks and fun is crucial. We send out a theme for planning in advance. We also provide engagement ideas like:

• virtual backgrounds
• table decorations

In-person, we plan for snacks and catering; virtually, we send meal kits or snack boxes to people’s homes. Themes bring fun and create camaraderie and empathy that make difficult conversations easier. Snacks keep people focused and stave off the hangry moments.

How to facilitate a successful PI Planning

No matter how well you prepare and set up, facilitation will be tricky, and there will be many twists and turns. Here are my top tips for facilitating successful PI Planning.

Use a detailed facilitator’s agenda

We write a script and annotate every transition, timebox, and tool used. As a facilitator, I plan out:

• How long to give each team for read-out, Q&A, and transition to the next team
• Who will present on which screen and from where, and so on

Scripting this prevents worry in the moment and allows us to focus on active facilitation.

Know your end goal so you can pivot

These down-to-the-minute agendas will go off the rails at some point. It may be because a meaningful conversation runs past the timebox. Or we need to discuss a risk or de-scoping in real-time. With a detailed facilitator’s plan, we can adjust in the moment and still achieve our goal.

Embrace crucial conversations

PI Planning includes difficult trade-offs, scoping conversations, and cross-team dependencies and risks. Emotions are high, and the content is high stakes. We must model and facilitate embracing these conversations in productive ways. As a facilitator, I ensure these conversations are happening by coaching people through them.

When people come to me with problems and risks they want me to solve, it is often something they can solve themselves with a crucial conversation. I coach them to use:

• “I” statements
• Clear, transparent communication

The pain caused by avoidance or indirect communication is always worth this time and effort. For more detailed PI Planning facilitation guides and templates, check out the SAFe PI Planning toolkit. Find it on the PI Planning SAFe Community Platform page .

Prepare for the RTE Role in Scrum of Scrums

After PI Planning, it’s essential to manage dependencies in a clear and consistent way. The RTE role helps create clear visibility on impediments to and progress toward our objectives.

For the ART, Scrum of Scrums (SoS) acts like a train-level stand-up. As an RTE, preparing well for SoS ensures we get the right outcomes. Facilitating well ensures it does not become a status meeting.

How to prepare for a successful SoS

Here are my tips and tricks for preparing a successful SoS in the RTE role.

Agenda and purpose

It’s important to provide a clear and visible agenda and purpose for SoS. This enables all the teams in the ART to prepare and show up with the right information to work dependencies and remove impediments.

Visuals to help review dependencies and progress toward objectives

We use the program board we built in SAFe Collaborate at PI Planning during SoS. We also use an iteration-by-iteration cross-team dependency board in our ALM tool.

Knowing we will use these in advance gives a clear place for everyone to prepare for the event. It also creates a visible place for dependencies and risks.

Representation from every team

Schedules can make it hard for every Scrum Master or team representative to attend SoS, but it must be a priority.

When Scrum Masters don’t represent their teams at SoS, questions go unanswered, and dependencies are harder to manage or make visible.

How to facilitate a successful SoS

Once I’ve prepared for SoS, here’s how I facilitate smoothly in the RTE role.

Pre-fill items in shared notes so you can spend time discussing risks, dependencies, and releases

A single, visible place for all SoS notes allows teams to add updates before the meeting. It allows others to review and show up to SoS ready to ask questions or share related information.

Ask questions that go beyond status updates to uncover dependencies

Ask clarifying questions about the work and related data in the ALM tool. Asking for visuals or links to related documents ensures everyone understands.

Mix up your questions each time. This prevents automatic responses and encourages thinking about the work from new angles.

Invite guests and people new to the company

This orients new people to your organization to your process for managing dependencies and risks. It also shows them where to find the information they may need about other teams’ work.

Check out the SoS Facilitator’s guide on the ART Events page of the SAFe Community Platform to improve your SoS facilitation.

Prepare for the RTE Role in System Demo

The System Demo is the flashiest of ceremonies the RTE role facilitates. It’s when the teams get to show off the work they’ve completed during the iteration (or PI if it’s the PI system demo).

How to prepare for a successful system demo

Because System Demo is about showing off the work of the ARTs, it’s important that I prepare them for a smooth experience.

Prepare presenters in advance

I provide a timebox and share my agenda deck two days before the demo. Participants to leave a “live demo” slide if they plan to share their screens during the event.

Then I meet with speakers half an hour before the demo. We test the timing of presentations, handoffs, and technology. This ensures a smooth delivery.

Create a reusable template

Using a template that follows the same pattern makes it easy to prepare topics. The topics I select show the progress toward our objectives and strategic themes.

A familiar template and standard format will make preparations easy and calm the nerves of those not used to presenting.

Build in time for Q&A and space for the conversation to continue past the timebox

While the demo of the end-to-end solution is critical, it is as important that stakeholders have the opportunity to ask questions and provide feedback.

We often only have time for a few questions, so we create a thread in our company messaging app for more questions and discussions.

How to facilitate a successful system demo

Once I prepare everyone, facilitating a successful system demo is pretty straightforward. Here are a few essential tips.

Open the meeting with purpose and expectations

I always take the first few minutes of the system demo to remind everyone why we are there. I also remind them of their role in ensuring we meet the purpose:

• Paying close attention
• Asking questions
• Giving feedback
• Looking for ways what they saw affects or improves their work

Connect demo topics to objectives and strategic themes

I structure the agenda by grouping demos by strategic theme. As part of the agenda overview, I discuss each theme and how each demo will connect to the theme and the team’s objective.

Embrace silence

The group often hesitates to speak up when there are over 100 people on a call or in a room, including key stakeholders and customers.

As a facilitator, I open the floor to questions and feedback. Or I ask questions and then count to 10 in my head. This can feel like an eternity of silence that you want to fill. But nine times out of ten, right toward the end of the silence, someone will come forward with a question. If you don’t allow for silence, you will lose much of that engagement.

Looking for more tips and tricks? Check out:

• The Lost Art of the Demo video
• Facilitator’s Guide to System Demo on the Toolkits and Templates page

Conclusion and Additional Resources

The RTE role of preparing for and facilitating ART-level events impacts the ART’s ability to:

• Connect strategy to execution
• Manage risks and dependencies
• Understand the end-to-end value delivered during the PI

Preparing ourselves and others in advance removes in-the-moment confusion. It also increases understanding and transparency.

We create space to pivot and shift in the moment while achieving desired outcomes.

Coaching and modeling crucial conversations means more productive team engagement and outcomes.

I hope this blog post has inspired you to explore new ways to approach facilitating your events. To help you on your journey:

• Review SAFe’s facilitator guides
• Check out ART and Team events resources
• Reach out to the SAFe Release Train Engineer Community Forum

About Lieschen Gargano Quilling

Lieschen Gargano is a Release Train Engineer and conflict guru – thanks in part to her master’s degree in conflict resolution. As the RTE for the development value stream at Scaled Agile, Lieschen loves cultivating new ideas and approaches to Agile to keep things fresh and engaging. She also has a passion for developing practices for happy teams of teams across the full business value stream.

View all posts by Lieschen Gargano Quilling

PI Planning—Plan to Discover the Next PI – Improving SAFe Journey

Note: This is the third post in the Practice Makes Permanent series. Read the first post here and the second post here . You can watch my webinar on PI Planning here .

Is your SAFe® implementation slowing? Has the energy and enthusiasm faded and it feels like just one more process change? Maybe you’re just not seeing the value you expected? That’s OK because PI Planning presents significant opportunities for your relentless improvement of the SAFe journey.

If you’ve read the previous posts in this series, you know that the right kind of SAFe practice doesn’t make perfect, it makes permanent. And you know that using creative tension will help you find the right outlook to discover new opportunities and foster relentless improvement. The reality is that many Agile Release Trains (ARTs) have a distorted view of PI Planning —they see it as a readout of the already created plan or a time to direct teams toward a plan rather than the discovery session it’s intended to be. This makes it a great place to get your implementation back on track. PI Planning is an opportunity to discover the plan for the next PI. Discovery is exciting, it’s engaging, and it’s about learning.

Through my years of teaching and implementing SAFe , I’ve identified key practices to help organizations successfully discover a plan for the upcoming PI. My goal in providing these tips and techniques is to give you practical ideas on how to revolutionize your PI Planning and improve the quality of your plans.

Consider these key practices to make PI Planning a discovery session:

• Breadth vs. depth planning
• Good objectives start early
• Iteration plans from PI Planning are “what if?” scenarios
• Raise the levels evenly
• Preconceived is pre-committed—limit pre-PI Planning

Breadth vs. Depth Planning

During PI Planning, the Agile teams are instrumental in converting the ART vision and roadmap into team-committed objectives while discovering the risks, dependencies, and delivery goals for the PI.

The anti-pattern

A very common anti-pattern in PI Planning is when teams focus on one iteration at a time, attempting to create a solid plan for iteration one, followed by a deep dive in iteration two, and so on. This is dangerous because we’re not seeing the big picture of the whole PI. And often we get to the draft plan review, and the teams don’t have a high-level, end-to-end plan, which is critical for the management (adjustment) review and problem-solving activity.

Additionally, because teams have gone iteration by iteration, concentrating on creating and loading stories, they haven’t collaborated sufficiently on with other teams on dependencies. This can potentially lead to radical plan changes during team breakouts on day two.

Implement breadth vs. depth

This is where breadth vs depth comes in. Encourage your teams to think across the whole PI and create a very high-level plan within the first 60–90 minutes of the first breakout session. This will include initial starter objectives, the discovery of some initial dependencies on other teams, high-level goals for each iteration, and some initial stories (perhaps slotted into an iteration). These activities give teams a broad, overall approach.

Now, they can use the remaining time in the breakout to improve the depth by:

• Discovering more stories
• Identifying more dependencies
• Refining objectives
• Identifying and (perhaps) mitigating more risks

This breadth vs. depth strategy ensures that there’s always a draft plan to review and helps teams align on the approach and effort distribution.

Here’s a quick recap of the key principles of breadth vs. depth:

• Start with a high-level, end-to-end plan that’s full of holes.
• As time permits, go back and fill in those gaps.
• Focus on “based on what we currently know, this is our plan. However, we know we have more to learn to fill in some gaps.”
• Raise the water level evenly. Create some story placeholders, which will generate some objectives, which will raise some dependencies, which will identify more stories, which will update objectives, and so on.

Apply SAFe ® Principle #3: Assume variability; preserve options. Start with minimal constraints and a high-level approach and add details as they emerge.

Good Objectives Start Early

Team objectives are one of the key outputs of the planning effort. Objectives are a team’s opportunity to say:

“Hey, ART leadership, we saw the vision, we saw the roadmap from the top x features. Here’s our contribution to the success of the ART for this PI.”

This is a powerful opportunity to engage SAFe Principle #8 and SAFe Principle #9 and is a critical component to ensuring alignment.

Many teams struggle with understanding objectives because they’re not used to being asked, “What can you contribute to our success?” Instead, they’re used to being told “this is what needs to be done.” I like to explain objectives with an analogy.

Team objectives

Imagine you’ve just read a really powerful, thought-changing book (such as Donald Reinertsen’s Principles of Product Development Flow ). Most likely you’ve read the book chapter by chapter. You want to share the power of that book with your friend, and you’ll probably share highlights and key areas and concepts from your perspective. Now, another friend reads the same book and shares their key takeaways from their perspective. While there may be similarities in key concepts (for example, Economic Sequencing) each perspective may pick up on different areas and ideas that were key to them but that maybe didn’t stand out to you.

The chapters in the book are the features. All the teams read the features and come away with their key areas and contributions. These are the team objectives. Some teams may have shared contributions across the ART (Program Objectives), but many will have specific contributions unique to their own team (Team Objectives).

Start early, iterate often

So, how do you achieve these powerful objectives within PI Planning? That’s where the phrase “good objectives start early” comes in. Objectives should start as early thoughts and concepts and grow in clarity and alignment as the breakout continues.

These are the key principles to successfully writing objectives:

• Start writing objectives early in the first breakout.
• Don’t wait until you have ‘perfect’ objectives; perfect is the enemy of good.
• As you learn more about the plan during the breakout conversations, potential objectives will emerge. Write these down, no matter how incomplete they are.
• As you learn more about the objective through further planning-fueled learning, update the objectives.
• Don’t try to start with SMART objectives, work toward them.

Iteration Plans from PI Planning Are What-If Scenarios

A common issue that limits the self-organization aspect of SAFe Agile teams is the mistaken belief that teams are creating iteration plans that must be locked in and committed to. This is a highly critical point: teams do not commit to iteration plans in PI Planning. They’re committing to the objectives they discover, and to the Program Board, which identifies when they believe they can deliver on the features and what dependencies are needed to deliver. When teams have the false belief that they’re going to be held accountable for plans for four iterations in sequence, they become nervous, realizing they can’t really know exactly what will be needed for each iteration. They believe they’re being held to a mini-waterfall approach. Actually, the opposite is true.

We ask teams to create iteration plans so that they can discover the objectives they want to commit to, discover the significant dependencies needed to deliver the features they pull in and discover the risks that may threaten the plan. The plan they create is one of many possible ways they can deliver, and many of the details of the actual plan will surface as they execute that plan. In my experience, the specific iteration plans the teams create are about 60-percent accurate. As long as we have the significant dependencies and risks identified, that level of accuracy is good enough to get started.

Key principles around the what-if scenario approach:

• Teams do not commit to iteration plans. They commit to objectives and the Program Board’s dependencies and Feature deliveries.
• Teams create iteration plans to unearth dependencies, discover objectives, and learn how to deliver to the business.
• The iteration plans will almost certainly change as we iterate through the Program Increment. Understanding that we are only identifying one of many possible scenarios to deliver on these objectives helps the teams focus on what’s important.

Raise the Levels Evenly

Closely associated with the breadth vs. depth concept is ensuring you have a good balance of focus on each component of the Draft Plan Review. Following SAFe Principle #4, we want to shorten our Plan-Do-Check-Adjust (PDCA) cycles to increase the pace of learning. If you think of each key area of focus in the team breakout, we have:

• Creating, sizing, prioritizing user stories and enabler stories
• Identifying and improving team objectives
• Identifying and attempting to mitigate risks
• Discovering, discussing, and gaining commitment to cross-team dependencies
• Updating the Program Board as we discover new feature delivery and dependency aspects in the emerging plan

Consider each of these areas as buckets to fill. We don’t want to fill one bucket to the top and then go to the next. Instead, we want to evenly bring up the level on all buckets together. That means we want the teams to generate some stories, which can lead to updated objectives, which can lead to new risks identified or mitigated, leading to new commitments with other teams, and leading to updates to the Program Board. This order is not rigid, there’s nothing wrong with discovering a dependency, adding some stories to cover this dependency, and then updating Program Board. The idea is to make sure that we are keeping the levels (amount of recorded information) approximately even across all the buckets.

These are the key principles to raising the levels evenly:

• Don’t try to create a full iteration-by-iteration plan too early.
• Use the energy and knowledge from adding to one bucket to add to the next bucket.
• At regular intervals, step back and review the levels in each bucket. Are these relatively evenly filled? If not, do we need to revert to focus on a particular bucket?
• At key points, review the entire plan we have created so far. Do we see major gaps? Dangerous assumptions? Note: a great time to do this is about five minutes before the next Scrum of Scrums team breakout. It provides a really clear view of the current progress that will help us identify any systemic issues in our planning process.

Preconceived Is Precommitted—Limit Pre-PI Planning

Before we start PI Planning, we need the right level of readiness. But too much can lose the discovery aspect of PI Planning. Finding that balance is a learning journey, but there are key elements to balance.

Too much pre-PI Planning:

• Takes away from the current PI effort. The focus should be on this PI’s objectives, not pre-planning for the next.
• Locks into a plan that is not well-informed. PI Planning is about learning, not perfecting. The best objectives come from shared learning during PI Planning.
• Damages the team-of-teams culture in the ART.

Too little pre-PI Planning:

• Leaves the teams anxious
• Can waste time in PI Planning trying to answer foundational questions

The right balance of PI Planning:

• Allows teams to ask intelligent questions during the morning briefings. The test I apply is to verify: are the questions probing and refining (good) or are they high level and more about initial alignment (not so good).
• Ensures we have the right people in the room. For this PI’s features, we may need other shared services and assistance. Knowing this in advance helps us extend invites to the right people.
• Sets the stage for PDCA-based learning cycles during PI Planning. When teams come into PI Planning thinking they already have the right plan, it leads to a fixed mindset for the next PI, which blocks the true discovery needed. We want the team of teams (ART) to iterate through these PDCA cycles together as they discover the plan.

I use a very simple approach—called the five-sticky rule—to help teams understand a good starting point for the level of pre-planning needed. Each team is encouraged to bring five sticky notes into PI Planning that represent potential stories. This requires the team to do enough discovery around the features, vision, and other elements needed in the next PI but keeps them from creating a deep-dive plan that loses the discovery aspect. Please note that the five-sticky rule is more of a guideline than a rule and can be adjusted as needed.

These are the key principles to finding a balance of pre-planning:

• Prepare to create the plan, don’t pre-create the plan
• Look for intelligent, informed questions during the briefings
• Beware of a fixed mindset view of the plan coming into PI Planning

PI Planning is one of the Ten Critical Success Factors to achieve transformational progress with SAFe. By applying the above ideas, you can make it the dynamic, engaging, energetic event it’s intended to be. So, go make your PI Planning a discovery session!

Check back soon for the next post in the series.

About Dwayne Stroman

Dwayne is an Enterprise Transformation Coach and Trainer and SAFe® Program Consultant Trainer (SPCT) with more than 20 years of experience. He is ultra-passionate about helping large organizations learn how to build the right products and deliver optimal value through learning and customer validation. Dwayne uses his SPCT role to help several Fortune 100 companies, as well as many growing companies in finance, retail, healthcare, and logistics, realize the benefits of a Lean-Agile mindset. Connect with Dwayne on LinkedIn .

Practical Tips for the New RTE – Business Agility

Release Train Engineers (RTEs) play an important role in aligning the organization and maintaining it during PI Planning. In this episode, we talk to Kimberly Lejonö and Carl Starendal, both former RTEs and experienced Agile coaches, who share their tips for RTEs just getting started in their role. And we’ll dive into some questions we hear from RTEs in the field around inspiring change across teams and Agile Release Trains (ARTs) and managing the flow of value.

Click the “Subscribe” button to subscribe to the SAFe Business Agility podcast on Apple Podcasts

Release Train Engineers (RTEs) play an important role in aligning the organization. In this episode, we talk to Kimberly Lejonö and Carl Starendal, both former RTEs and experienced Agile coaches, who share their tips for RTEs just getting started in their role. We’ll also dive into some questions we hear from RTEs in the field around inspiring change across teams and Agile Release Trains (ARTs) and managing the flow of value.

 Topics that Kimberly and Carl touch on include:

• PI Planning preparation and execution
• Maintaining alignment during the PI
• Supporting cultural change
• Metrics, and what not to measure

Hosted by: Melissa Reeve

Melissa Reeve is the Vice President of Marketing at Scaled Agile, Inc. In this role, Melissa guides the marketing team, helping people better understand Scaled Agile, the Scaled Agile Framework (SAFe) and its mission.

Guest: Kimberly Lejonö

Tapping into her background working as an RTE, project leader, and scrum master, Kimberly brings a high-energy and curious mindset to affect change in others. She loves connecting with the people around her and unlocking their potential to help organizations move in their desired direction. Connect with Kimberly on  LinkedIn .

Guest: Carl Starendal

With a background in game development and a decade of hands-on experience at the center of global Lean-Agile transformations across multiple industries, Carl co-founded We Are Movement, an Agile and Lean advisory team based in Stockholm. A highly regarded trainer, advisor, and facilitator, he is a passionate advocate and resource for organizations throughout all stages of the Agile journey. Carl is recognized internationally as a speaker on leadership, Agile, and product development. Find Carl on  LinkedIn .

Creating Your PI Backlog Content – Agility Planning

Glenn Smith and Darren Wilmshurst with Radtac , a Scaled Agile Partner, co-wrote this blog post. 

At the conclusion of Program Increment (PI) Planning, we’re always reminded of something one of our colleagues always says. There’s much to celebrate because we’ve created a set of committed plans. But we first have to complete a retrospective of the PI Planning event (cue groans from everyone in the room) and we “start preparing tomorrow” for the next PI (more groans).

Moreover, the critical path for any PI Planning is the creation of the content, suitably refined and prioritized. Without this, we can’t do any planning! But what does this look like in practice? 

This blog post is aimed at coaches who need to think about the content preparation for the next PI. By that we mean SAFe ® Program Consultants (SPCs) supporting the Agile Release Train (ART) and Release Train Engineers (RTEs). But more importantly, Product Management (PM) and System Architects (SA) need to create, refine, prioritize, and socialize the content supported by Product Owners (POs) and Business Owners (BOs). We will explore each of these roles in turn during the course of this post. 

The traditional siloed hierarchy of organizations can engender a ‘this isn’t my job’ attitude. Yet many people and roles need to work together to create a compelling backlog that delivers economic benefits and satisfies your customers.

The visual model below is a high-level view of the intensity of the preparation activity for each of these roles. It isn’t meant to represent the number of hours. That is, high intensity does not mean 100 percent of your time, we just expect more time spent on preparation while recognizing that there will be other things to be done.

You will also notice that there is a significant spike in preparation during the Innovation and Planning (IP) Sprint for PM, BOs, POs, and the Teams. This is when PI Planning happens.

Product Management and System Architect

PM and the SA will follow a similar pattern to each other, as their roles are two sides of the same coin—one focused on the outward market and the other technically oriented. They are going to be collaborating and working closely to make sure their respected needs are met and the right balance of the work is correctly scheduled.

Crafting backlog items for an ART, whether they are Business Features or Enabler Features, follow a pattern of Creating, Refining, Prioritising, and Socialising. While overly simplistic, each step could follow the first four iterations of a PI. In the first half of the PI, expect PM and the SA to be looking to the future. This will include looking at upcoming Epics, decomposing existing Epics, and the ART roadmap and associated Architecture Runway.

A common pattern is to see poorly defined Features with weak benefit hypothesis statements and acceptance criteria. It shouldn’t be overlooked how much effort this takes to do well. This is because the work involved isn’t just writing them down in your Agile Lifecycle Management tooling, but working with BOs, talking to a wider stakeholder cohort, including customers, and reviewing market trends. Improving their own understanding of the value proposition and scope enables people on the ART to more easily deliver against it. Through the PI, their effort tapers as other cohorts take the backlog content and prepare for PI Planning.

Business Owners

BOs are key stakeholders and critical friends of the ART. As such, they gradually experience an increasing demand on their time to support creating backlog content throughout the PI—with the most involvement happening during PI Planning. As a cohort, BOs are available when needed by the likes of PM, and actively participate in the System Demos every iteration. Here, they not only get to see the progress of delivery but give feedback to help PM and the POs inspect and adapt the backlog.

We recommend that prioritization be a ‘little and often’ affair. And as it is a team sport, BOs must attend these sessions (these are the little spikes on the BO line in the model).

Product Owners

In a scaled environment, POs serve both the team and the train. In the initial periods of the PI, as you might expect, the PO has both a team execution focus and needs to support PM with Feature creation and refinement. As the content starts to get in better shape for the upcoming PI Planning, PO involvement increases, but with a shift in focus to Feature elaboration and decomposition into drafting user stories to later socialize with the team.

Through most of the PI, the team is execution-focused, although on hand for those ad hoc, short whiteboard sessions with PM, SAs, and POs. Larger demands on the team’s time should be scheduled like any other demand on their time—after all, work is work! This will be done through the use of exploration enablers in a future PI, or spikes and innovation activities that occur during the IP iteration. Either way, the outcome is gaining knowledge that reduces the uncertainty of future work.

The team’s involvement, however, peaks during the IP iteration when the POs socialize the upcoming backlog of work—the Features and the draft stories they have created. It is during the preparation for PI Planning that the team takes time to understand what is needed and answer questions that need “I’ll look in the code” to find out.

Release Train Engineer and Scrum Master

Hey wait, you didn’t forget about the RTE and Scrum Master (SM) , did you? Surely they are just facilitators, we hear you say, what do they have to do with backlog items? But let’s think about this. As facilitators at the train or team level, they are key advocates for the improvement of flow and value delivery. Therefore, it is not unreasonable to expect them to create improvement items that require effort from the teams during the PI. And we know that anything that requires effort from the teams should be planned accordingly.

The items that the RTE and SM will bring to the table for inclusion will likely come from team retrospectives, the Inspect and Adapt problem-solving workshop, or from insight gained from activities like the SAFe ® DevOps course.

Creating Content During PI Planning

During each PI Planning session, PM presents the vision, which highlights the proposed features of the solution, along with any relevant upcoming Milestones. While some may feel that at this point in the proceedings the content creation is over for PM, there is actually still work to do. During the planning, there will likely be scope negotiations and prioritization calls needed as the teams get deeper into understanding and scheduling in their breakout sessions.

Similarly, the BOs have a role in adaptive content creation too. Beyond providing the business context in the briefings, they will work with the team to discuss the needed outcomes from the work. And they’ll support PM and the SAs in adapting the scope from what was originally crafted—because tradeoffs need to be made during planning. Discussions with the teams during the assignment of Business Value could influence what gets produced in the upcoming PI too.

While the POs and the Teams need to sequence and plan their stories to maximize economic results, there will almost certainly be variability of scope that will need to be accommodated as new information emerges. This will involve further elaboration, negotiation, planning, and reworking of the content during PI Planning.

In addition, the model shouldn’t be followed religiously, but used to identify who, when, and by how much focus the different roles on the train need to spend to make this happen. While putting an emphasis on the quality of the backlog items is going to help your ART, it alone won’t fix your delivery problems but will act as a key enabler in doing so. 

It is important to give a government health warning at this stage: context is king! While we have given our view on the preparation activities and the intensity, your context will provide a different reflection. In fact, when creating this post, we both had a slightly different approach for prioritization based on our respective experiences. Neither is right or wrong but a reflection on the clients that we have worked with. So please treat the model we have created as a ‘mental model’ and something you can use with your trains to frame a discussion. 

The pattern, while broadly accurate, will change in some situations, particularly if you are preparing for a training launch and this is your first PI. Here, the cadence may be condensed and more focused, but this will be guided by the quality of the backlog content you already have. A final thought and back to our colleague who says that “PI Planning starts tomorrow.” So does PI Execution. There’s no point in making a team committed to the plans that you have created and then not executing on them. Otherwise, what was the point of PI Planning in the first place?

If we’ve piqued your interest, check out this post about changing a feature in the middle of the PI. It’s a question we always get asked when we teach the Implementing SAFe ® class.

About Glenn

Glenn Smith is SAFe Program Consultant Trainer (SPCT), SPC, and RTE working for Radtac as a consultant and trainer out of the UK. He is a techie at heart, now with a people and process focus supporting organizations globally to improve how they operate in a Lean-Agile way. You will find him regularly talking at conferences and writing about his experiences to share his knowledge.

Back to: All Blog Posts

Next: we’re giving more than a donation for pride month, privacy overview.