O SAFe® Day Brazil realizado pela Adaptworksé um encontro imperdível na agenda de executivos, líderes e especialistas da comunidade ágil brasileira em busca de insights sobre como escalar a agilidade no setor público, aprender e debater sobre impulsionar a transformação Lean-Agile com SAFe® ou desejam conhecer os casos reais de aplicação no Banco do Brasil e Petrobras.
Speakers
Stosh Misiaszek
Senior Director of Federal Business Development, (Scaled Agile)
Together with our partner Deloitte, we are bringing together leading minds from administration and Agile transformation to discuss solutions for the future.
Speakers
Felix Dinnessen
Partner | Government & Public Services, (Deliotte)
Dr. Thomas Karl
Director | Technology Strategy & Transformation – Industry Lead GPS, (Deliotte)
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
Fox trail
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.
In-person
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.
Virtual
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.
Feature stickies in piplanning.io
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.
Conclusion
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.
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.
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.
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.
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.
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
Activity: Create
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.
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.
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
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:
Agenda
Floor plans and locations of the team breakout rooms
Instructions on how to use video conferencing equipment
Facilitation tips
Excerpt from the information pack (floor plans blurred for this blog post)
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.
(Left) physical Program Board (Right) digital Program Board
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.
Futurespective workshop
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.
PI Planning event feedback
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.
Nerves
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.
Time for a break
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.
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.
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)
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
What does a scrum master do?
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.
What if I’m a scrum master without experience?
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
Advisor
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.
Setting scrum master improvement areas
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:
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.
I spend most of my time in theRelease 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:
strategy
business context
priorities
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.
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.
Content
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.
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.
Space
How you set up impacts how your teams engage and where they focus during planning.
Virtual
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.
In-person
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:
costumes
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.
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.
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.
![PI Objective Formula
[Activity] + [Scope] so that [Beneficiary] have [User Value] to [Business Value]](https://scaledagile.com/wp-content/uploads/2022/11/SAi_Blog_Header_PI_Formula_103122-1-1024x244.jpg)
