the management review and problem solving workshop

Ask a question

Start a discussion.

• Jira Jira Software
• 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

Get product advice from experts

Join a community group

Advance your career with learning paths

Earn badges and rewards

Connect and share ideas at events

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

142 total posts

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

• Shop Card Decks
• Video Libary

Engineering , Leadership , User experience , User experience , Product management

Problem-Solving Workshop

A collaborative learning environment designed to help participants develop skills to identify and solve problems. product glossary problem-solving workshop also called: problem-solving session and problem-solving exercise see also: how might we , hypothesis statement , premortem , problem statement , six thinking hats , swot analysis , affinity diagram , circles method , design thinking , jobs-to-be-done framework (jtbd) relevant metrics: attendance and engagement, pre- and post-workshop assessments, goal achievement, participant satisfaction, knowledge retention, application of skills, networking and collaboration, and commitment to continuous improvement in this article what is a problem-solving workshop.

A Problem-Solving Workshop is a collaborative event in which a group of people come together to identify and solve a problem. It is a structured process that involves brainstorming, analyzing, and developing solutions to a problem. A problem-solving workshop is a rapid session that helps you:

• Unlocking the Core of the Issue . A problem-solving workshop serves as an accelerated session designed to delve into the underlying cause of a dilemma, enabling participants to better comprehend its complexities.
• Generate ideas . With a deeper understanding of the problem at hand, participants rapidly brainstorm potential solutions. They then carefully assess these ideas, ensuring their feasibility and effectiveness in addressing the issue.
• Evaluating ideas . Participants scrutinize their proposed ideas, determining their robustness and ability to withstand potential challenges to ensure that only the most viable and reliable solutions are considered for implementation, enhancing the likelihood of successfully resolving the problem.
• Make a plan to test or implement . Equipped with a well-rounded perspective and carefully evaluated solutions, the workshop empowers attendees to devise a strategic plan for testing or implementing their chosen resolution, ultimately guiding them toward the ideal solution to their problem.

The workshop typically begins with a discussion of the problem and its context. Participants then brainstorm potential solutions and evaluate them based on their feasibility and potential impact. After the brainstorming session, the group works together to develop a plan of action to address the problem. This plan may include changes to existing processes, new procedures, or other solutions.

The Problem-Solving Workshop is an effective way to identify and solve problems in the context of Product Management and User Experience. It allows for a collaborative approach to problem-solving, which can lead to more creative and effective solutions. It also allows for a structured approach to problem-solving, which can help ensure that the problem is addressed in a timely and efficient manner.

Where did Problem-Solving Workshops come from?

The idea of coming together to solve problems can be traced back to ancient human societies that held gatherings to discuss issues and find solutions. In modern times, problem-solving workshops have been shaped by developments in various fields like psychology, education, management, design, and innovation.

Some significant influences on problem-solving workshops include:

• Brainstorming . Alex Osborn, an advertising executive, introduced brainstorming in the 1940s as a group creativity technique to generate ideas and solve problems. This method encouraged people to share their ideas freely, no matter how wild, and suspend judgment during the idea-generation process. Brainstorming has since been incorporated into many problem-solving workshops.
• Quality circles . In the 1960s, Japanese companies introduced quality circles, which are small groups of employees who meet regularly to discuss and solve work-related problems. These circles aimed to improve the quality of products and processes by involving employees in problem-solving and decision-making. The concept of quality circles has inspired many problem-solving workshops in various industries.
• Design thinking . The design thinking methodology, pioneered by companies like IDEO and Stanford University’s d.school, has played a crucial role in shaping modern problem-solving workshops. Design thinking is a human-centered approach to problem-solving that encourages empathy, experimentation, and collaboration. It involves a series of steps, such as empathizing, defining, ideating, prototyping, and testing, which can be adapted to various problem-solving workshop formats.
• Lean and Agile methodologies . Lean and Agile methodologies, which originated in the manufacturing and software development sectors, respectively, have also influenced problem-solving workshops. These approaches emphasize collaboration, continuous improvement, and rapid iteration to achieve better results.
• Facilitation techniques . The growth of professional facilitation has also impacted problem-solving workshops. Skilled facilitators use various tools and techniques to guide groups through problem-solving processes, ensuring that the workshop’s objectives are met and that participants stay engaged and focused.

Why should I conduct a problem-solving workshop?

Conducting a problem-solving exercise can be beneficial in several ways. It can help individuals or teams to:

• Identify the root cause of a problem . By engaging in a structured problem-solving exercise, participants can gain a deeper understanding of the issue and identify the underlying causes.
• Generate new ideas and solutions . By brainstorming and evaluating various solutions, individuals or teams can develop creative and effective solutions that they may not have thought of otherwise.
• Encourage collaboration and teamwork . Collaborative problem-solving exercises can foster a sense of teamwork and create a shared sense of ownership and responsibility for the problem and the solution.
• Improve decision-making . By evaluating various options and considering different perspectives, participants can make informed and effective decisions that take into account a wide range of factors.
• Enhance learning and development . Problem-solving exercises can provide opportunities for individuals or teams to learn new skills, practice critical thinking, and develop problem-solving abilities that can be applied to future challenges.

How to run a problem-solving workshop

Step 1: assemble a well-rounded team.

Gather individuals with diverse backgrounds, skill sets, and perspectives who are relevant to the problem at hand. This may include team members, cross-functional collaborators, subject matter experts, or stakeholders. A diverse group will enhance the ideation process and facilitate a more comprehensive understanding of the issue.

Consider the following factors:

• Diversity . Assemble a team with a mix of expertise, backgrounds, perspectives, and roles relevant to the problem. Diversity encourages creative thinking and helps avoid groupthink or blind spots.
• Relevant stakeholders . Ensure that key stakeholders, including decision-makers, subject matter experts, and those directly affected by the problem, are included in the workshop. Their insights and buy-in are crucial for the success of the proposed solutions.
• Size of the group . Aim for a group size that allows for effective collaboration and communication. Ideally, the group should be large enough to generate a variety of ideas but small enough to facilitate productive discussions. Typically, a group of 6-10 participants is considered optimal for a problem-solving workshop.
• Team dynamics . Select participants who are open-minded, willing to collaborate, and capable of engaging in constructive discussions. The right balance of personalities is essential for fostering a positive atmosphere and effective teamwork.
• Establish clear roles . Assign roles and responsibilities to participants, such as a facilitator to guide the workshop, a timekeeper to monitor progress, and a note-taker to document key points and decisions. Clearly defined roles help ensure the smooth flow of the workshop.
• Preparation . Communicate the workshop’s purpose, goals, and expectations to participants beforehand. Encourage them to familiarize themselves with the problem and come prepared with any relevant data or insights. This will enable a more focused and productive discussion during the workshop.

Step 2: Establish the Objective and Scope

Clearly define the purpose and goals of the workshop. Ensure that all participants understand the problem to be addressed, its context, and any constraints or limitations. Set a time limit for the workshop to maintain focus and efficiency.

Consider the following:

• Preparation and research . A facilitator should be well-prepared with a thorough understanding of the problem, its context, and the workshop’s objectives. This may involve conducting research, reviewing relevant materials, and consulting with key stakeholders or subject matter experts beforehand.
• Active listening . Practice active listening during the workshop to ensure participants feel heard and understood. Encourage questions and clarifications to address any misunderstandings or ambiguities regarding the problem, scope, or objectives.
• Flexibility and adaptability . Be prepared to adjust the workshop’s objectives or scope if new information or insights emerge during the discussion. Maintain an open-minded approach and adapt to the needs of the group while ensuring that the workshop remains focused and productive.
• Time management . Monitor the workshop’s progress and allocate time appropriately for each stage. If necessary, intervene to refocus the discussion, maintain momentum, or transition to the next step in the problem-solving process.

Each of the following workshop exercises can contribute to the success of establishing a clear objective and scope by helping participants gain a deeper understanding of the problem, its context, and the needs of those affected, leading to a clearer definition of the objective and scope:

• Six Thinking Hats . This exercise, developed by Edward de Bono, encourages participants to approach the problem from six different perspectives, represented by metaphorical “hats.” These perspectives are: facts and information (white hat), emotions and feelings (red hat), cautious and critical thinking (black hat), optimistic and positive thinking (yellow hat), creative and alternative thinking (green hat), and process and organization (blue hat). This technique can help the group establish a more comprehensive understanding of the problem, its context, and potential constraints, leading to a clearer definition of the objective and scope.
• Stakeholder Mapping . In this exercise, participants identify and analyze the key stakeholders involved in or affected by the problem. This helps the group understand the different perspectives, priorities, and needs of these stakeholders, providing valuable context for the problem-solving process. By considering stakeholder needs and concerns, the workshop can better define the objective and scope while ensuring that potential solutions address relevant issues.
• Empathy Mapping . This exercise helps participants gain insight into the needs, motivations, and challenges of the individuals affected by the problem, such as customers, users, or team members. By creating an empathy map, the group can better understand the problem from the perspective of those who are directly impacted. This understanding can help the group establish a clearer and more focused objective and scope for the workshop, ensuring that potential solutions address the most critical concerns of the affected individuals.

Step 3: Identify the Right Problem and Root Cause

Begin the workshop by collectively discussing the problem to gain a deeper understanding of its nuances. Use techniques like the 5 Whys or Fishbone Diagram to identify the root cause of the problem, ensuring that the team’s efforts are directed towards solving the underlying issue rather than merely addressing symptoms.

Approach this step with a well-defined strategy that guides participants through the process of understanding the problem and its underlying factors. The facilitator plays a pivotal role in creating an environment that encourages open and honest dialogue, allowing participants to share their insights and collectively work towards identifying the root cause.

Strike a balance between allowing sufficient time for discussions and ensuring that the workshop maintains momentum and stays on track. The facilitator may need to intervene occasionally to refocus the conversation or steer the group towards the desired outcome.

Be prepared to adapt to the evolving dynamics of the workshop. They must be flexible and responsive to new insights or challenges that emerge during the discussions. If necessary, the facilitator may need to adjust the workshop’s objectives, scope, or methodology to ensure that the group remains focused on addressing the problem’s root cause.

Consider using one of these workshop exercises to identify the right problem:

• Five Whys . This technique involves asking “Why?” repeatedly to dig deeper into the problem and uncover the root cause. By using this approach in the workshop, participants can move beyond surface-level symptoms to identify the true source of the issue. The facilitator can guide the group through the Five Whys exercise, ensuring that the discussion stays focused and productive.
• Fishbone Diagram . Also known as the Ishikawa or cause-and-effect diagram, this tool visually represents the relationship between a problem and its potential causes. Participants brainstorm and categorize potential causes into distinct branches, which can help the group identify the root cause. The facilitator can lead the group through the Fishbone Diagram exercise, encouraging them to consider various aspects of the problem and promoting a comprehensive understanding.
• Round Robin . This brainstorming technique involves giving each participant a chance to contribute an idea or perspective on the problem in a structured and organized manner. This ensures equal participation and helps to gather diverse insights. Using the Round Robin method, the facilitator can facilitate discussions on the problem’s root cause by encouraging participants to share their thoughts and perspectives without interruption.
• Force Field Analysis . This exercise helps participants identify the driving and restraining forces that influence a problem. By analyzing these forces, the group can gain a deeper understanding of the underlying factors contributing to the issue. The facilitator can guide participants through the Force Field Analysis, helping them to identify and assess the various forces at play and facilitating discussions on how these forces might relate to the root cause of the problem.

Step 4: Generate Ideas to Solve the Problem

Encourage participants to brainstorm solutions, emphasizing the importance of open-mindedness and creativity. Utilize techniques like mind mapping, round-robin, or the six thinking hats to foster an environment conducive to idea generation. Ensure that all participants have an opportunity to share their thoughts, and discourage judgment or criticism during this stage.

Make sure that all participants feel comfortable sharing their ideas, no matter how unconventional they may seem. This requires the facilitator to create a non-judgmental and supportive atmosphere that promotes inclusivity and equal participation.

One critical aspect for the facilitator is the use of various brainstorming techniques and ideation exercises that can stimulate creative thinking and encourage diverse perspectives. By employing a mix of individual and group activities, the facilitator can cater to different thinking styles and preferences, ensuring that everyone contributes to the ideation process.

These workshop exercises are great for generating ideas to solve the problem you identified:

• Mind Mapping . This technique helps to visually organize information around a central concept, allowing participants to generate ideas in a structured manner. It encourages them to think about the problem from different perspectives and make connections between seemingly unrelated ideas, which can lead to creative solutions.
• Crazy Eights . In this exercise, participants are given eight minutes to sketch out eight different ideas on a piece of paper. The time constraint forces them to think quickly and encourages them to generate a wide variety of ideas. By sharing and discussing their sketches afterward, the group can build upon each other’s ideas and develop more innovative solutions.
• Reverse Brainstorming . This technique prompts participants to think about the problem from an opposite perspective, by asking them to come up with ways to make the situation worse. By challenging conventional thinking, reverse brainstorming helps uncover new insights and approaches that may not have been considered otherwise.
• How Might We . This exercise frames the problem as an open-ended question, starting with the phrase “How might we…?”. This positive and optimistic framing encourages participants to think creatively and generate ideas without constraints. The open-ended nature of the question also promotes collaboration, as participants can build on each other’s ideas to find innovative solutions.
• Forced Analogy . In this exercise, participants are asked to draw analogies between the problem at hand and unrelated objects or scenarios. This encourages them to think about the problem from a new perspective and come up with creative ideas that they may not have considered otherwise. The forced analogy technique can reveal hidden connections and inspire innovative solutions.
• SCAMPER . This is an acronym for Substitute, Combine, Adapt, Modify, Put to another use, Eliminate, and Reverse. Participants are prompted to think about the problem and generate ideas using each of these seven approaches. The SCAMPER technique encourages participants to look at the problem from different angles and find unique solutions.

Step 5: Evaluate and Refine Ideas

Once a range of potential solutions has been generated, evaluate their robustness and viability. Encourage participants to consider potential challenges, drawbacks, and risks associated with each idea. Use a decision matrix, SWOT analysis, or other evaluation tools to help compare and prioritize the proposed solutions.

Seek to create an environment where participants feel comfortable sharing their opinions and ideas while also being open to constructive feedback. The facilitator must balance encouragement and critical thinking, promoting an atmosphere where ideas are assessed objectively, and their merits and drawbacks are examined thoroughly.

Be aware of any biases, power imbalances, or dominant personalities that may influence the evaluation process. By skillfully navigating these dynamics, the facilitator can ensure that all voices are heard and that the evaluation process remains objective and fair.

These workshop exercises are great for evaluating and refining ideas.

• SWOT Analysis . This exercise requires participants to analyze the strengths, weaknesses, opportunities, and threats associated with each proposed solution. By conducting a SWOT Analysis, the group can thoroughly evaluate the viability and potential impact of each idea, identifying potential challenges and opportunities.
• Pros and Cons . In this exercise, participants list the advantages and disadvantages of each proposed solution. This method encourages participants to think critically about the potential outcomes of each idea, enabling the group to make a more informed decision.
• Poster Session . In this exercise, each proposed solution is presented on a poster, and participants are given time to review and provide feedback on each idea. The Poster Session promotes thoughtful consideration of each solution and allows for open discussion and collaborative evaluation.
• Plus/Delta . This exercise involves participants identifying the positive and negative aspects of an idea or solution. It can help to refine ideas by focusing on the strengths and weaknesses of each one.
• Affinity Mapping . This exercise involves grouping similar ideas together and can help to identify common themes and patterns. It can help to refine ideas by clarifying the relationships between different solutions.
• Assumptions Collection . This exercise involves identifying assumptions that have been made about the problem or solution and testing them to see if they are valid. It can help to refine ideas by identifying any flawed assumptions and correcting them.
• Force Field Analysis . This exercise involves identifying the forces that are supporting and opposing a proposed solution. It can help to refine ideas by addressing the barriers and challenges that need to be overcome for the solution to be successful.

By incorporating these workshop exercises, participants can thoroughly evaluate the proposed ideas to ensure they are robust and viable. These

Step 6: Select the Best Solution

As a group, decide on the most promising solution(s) based on the evaluation process. Discuss the reasoning behind the selection and ensure that all participants are on board with the decision.

To promote objectivity, encourage the use of predefined criteria or frameworks for evaluating the proposed solutions. By providing a structured approach to decision-making, participants will be better equipped to weigh the pros and cons of each idea, ultimately leading to a more informed choice.

This will also help you maintain a neutral stance throughout the selection process, allowing the group to discuss and debate the merits of each solution without bias. As a facilitator, your goal is to ensure that the group focuses on the problem at hand and avoids getting sidetracked by personal preferences or interpersonal conflicts.

If you see that the group is struggling to reach a consensus, you might need to guide them toward a decision. By summarizing the key points of the discussion and highlighting the most promising solutions, the facilitator can help the group make a well-informed decision that best addresses the problem.

The following workshop exercises are great for facilitating the selection process:

• Dot Voting . This method helps participants prioritize solutions by giving them a limited number of dots or stickers that they can distribute among the proposed ideas. The solutions with the most votes are considered the most promising and can be further discussed or refined.
• Fist to Five . This technique allows the group to quickly gauge the level of support for each solution. Participants indicate their level of agreement by raising a certain number of fingers (1 to 5), with five fingers signifying strong support. The solutions with the highest average scores are deemed the most favorable.
• Stack Ranking . In this exercise, participants rank the proposed solutions in order of preference, assigning a unique position to each idea. The facilitator then tallies the rankings and determines the overall order of preference for the group. This helps identify the top solutions based on collective input.
• Trade-off Sliders . This method encourages participants to consider the pros and cons of each solution by using sliders to represent various criteria, such as cost, time, or quality. Participants adjust the sliders to visually represent the trade-offs they are willing to make, and the facilitator synthesizes the results to identify the most viable solutions.
• SWOT Analysis . By evaluating each solution’s strengths, weaknesses, opportunities, and threats, participants can gain a comprehensive understanding of the potential outcomes and risks associated with each idea. This structured analysis helps the group make a more informed decision about which solution is best suited to address the problem.
• Decision Matrix . The facilitator creates a matrix with the proposed solutions as rows and the evaluation criteria as columns. Participants then score each solution based on how well it meets the criteria. The solution with the highest total score is considered the best option. This method promotes objective decision-making and allows for a clear comparison of the proposed solutions.
• Priority Mapping . This technique involves visually mapping ideas based on their importance and urgency. By using Priority Mapping, the group can quickly identify the most critical and time-sensitive ideas, ensuring that the most pressing solutions are prioritized for implementation.

Step 7: Develop a Plan for Implementation or Testing

With the chosen solution(s) in hand, create a detailed plan outlining the steps required for implementation or testing. Assign responsibilities, establish deadlines, and set milestones to ensure accountability and progress. Consider creating a pilot project or running tests to validate the effectiveness of the solution before a full-scale implementation.

Seek to guide the group in setting realistic timelines and defining clear roles and responsibilities. This involves promoting open communication, ensuring that everyone’s input is valued, and addressing any concerns that may emerge.

You might also consider to spend time establishing key metrics for monitoring success and setting up checkpoints to evaluate the success of the implementation, enabling the team to learn from their experiences and iterate on the solution as necessary.

The following workshop exercises work great for exploring an creating an implementation plan.

• Project timeline . A project timeline is an effective way to help the team map out the key milestones, tasks, and deadlines involved in implementing the chosen solution. It allows the team to visualize the project’s overall progress and identify potential issues that may arise during the implementation process.
• Future-Back Planning . Future-Back Planning is a technique that helps the team envision what success will look like in the future and work backward to identify the necessary steps to achieve that success. This approach can help the team develop a clear vision and strategy for implementing the solution.
• RACI Matrix . A RACI Matrix is a tool that can be used to clarify roles and responsibilities during the implementation process. It helps ensure that each team member understands their role in the project and can help prevent confusion or misunderstandings.
• Dependency Map . A Dependency Map is a visual tool that helps the team identify the interdependencies between different tasks or components of the project. This can help the team develop a more realistic and feasible plan for implementing the solution.
• Sailboat . The Sailboat exercise can be used to help the team identify potential obstacles or challenges that may arise during the implementation process. It involves visualizing the solution as a sailboat and identifying the factors that may help or hinder its progress towards the desired destination. This exercise can help the team proactively address any potential roadblocks and develop a plan to overcome them.

Step 8: Follow Up and Iterate

After the workshop, monitor the progress of the solution’s implementation or testing. Gather feedback, evaluate results, and make any necessary adjustments or refinements. Encourage open communication among participants, and consider scheduling follow-up meetings to review progress and address any emerging challenges.

The solution that was chosen may need to be adjusted or refined based on feedback or unexpected challenges that arise. As a facilitator, you should encourage team members to share their thoughts and ideas and foster an environment where experimentation and iteration are encouraged.

Find ways celebrate successes and acknowledge the efforts of the team throughout the process. This can help maintain morale and motivation for continued improvement and innovation.

Typical pitfalls when running a Problem-Solving Workshop

• Finding the Right Facilitator . Finding a facilitator who is knowledgeable and experienced in problem-solving techniques can be a challenge. It is important to find someone who can effectively lead the workshop and ensure that all participants are engaged and productive.
• Establishing Clear Goals . Establishing clear goals for the workshop is essential for its success. Without a clear understanding of the objectives, it can be difficult to ensure that the workshop is productive and successful.
• Creating an Engaging Environment . Creating an engaging environment for the workshop is key to its success. Participants need to feel comfortable and be able to focus on the task at hand.
• Managing Time . Time management is essential for a successful workshop. It is important to ensure that the workshop is structured in a way that allows for productive discussion and problem-solving.
• Ensuring Participation . Ensuring that all participants are actively engaged in the workshop is essential. It is important to create an environment where everyone feels comfortable to contribute and share their ideas.

Google is known for its commitment to fostering a culture of innovation and continuous improvement. The company regularly conducts workshops, hackathons, and brainstorming sessions to encourage creative problem-solving among employees. Google’s “20% time” policy, which allowed employees to dedicate 20% of their time to side projects, has led to the development of successful products like Gmail and Google Maps.

IDEO, a global design consultancy, is renowned for its human-centered, collaborative approach to problem-solving called “design thinking.” The company conducts workshops, both internally and for clients, to tackle complex challenges and create innovative solutions. This approach has helped IDEO to develop breakthrough products, such as the Apple mouse and the Palm V PDA.

Procter & Gamble (P&G)

P&G is a consumer goods company that has leveraged problem-solving workshops and open innovation programs to drive growth. They have held workshops and innovation sessions, such as the “Clay Street Project,” where cross-functional teams come together to tackle complex challenges and create new products. The company’s innovation initiatives have resulted in successful products like Swiffer, Febreze, and Mr. Clean Magic Eraser.

LEGO, the toy company known for its iconic plastic bricks, has used problem-solving workshops to foster innovation and drive business growth. The company has employed design thinking workshops to explore new product ideas and refine existing ones. LEGO’s commitment to problem-solving and innovation has led to the creation of successful product lines such as LEGO Mindstorms, LEGO Architecture, and LEGO Ideas.

• What is the purpose of the workshop?
• What are the objectives of the workshop?
• Who will be attending the workshop?
• What topics will be covered in the workshop?
• What methods will be used to facilitate problem-solving?
• What is the expected outcome of the workshop?
• How will the success of the workshop be measured?
• What is the timeline for the workshop?
• What is the budget for the workshop?

You might also be interested in reading up on:

• How Might We
• Hypothesis Statement
• Problem Statement
• Six Thinking Hats
• SWOT Analysis
• Affinity Diagram
• CIRCLES Method
• Design Thinking
• Jobs-To-Be-Done Framework (JTBD)
• Tim Brown @tceb62
• Tom Kelley @TomKelley74
• Jeanne Liedtka @jeanneliedtka
• Tendayi Viki @tendayiviki
• Dave Gray @davegray
• Lateral Thinking : Creativity Step by Step by Edward de Bono (1970)
• Thinkertoys : A Handbook of CreativeThinking Techniques by Michael Michalko (1991)
• Problem Solving and Decision Making : A Guide for Managers by Barry K. Baines (2000)
• The 5 Elements of Effective Thinking by Edward B. Burger and Michael Starbird (2012)
• Six Thinking Hats by Edward de Bono (1985)
• Innovation Games : Creating Breakthrough Products Through Collaborative Play by Luke Hohmann (2006)
• Gamestorming by Dave Gray (2010)

Want to learn more?

Receive a hand picked list of the best reads on building products that matter every week. Curated by Anders Toxboe. Published every Tuesday.

No spam! Unsubscribe with a single click at any time.

Community events Product Loop

Product Loop provides an opportunity for Product professionals and their peers to exchange ideas and experiences about Product Design, Development and Management, Business Modelling, Metrics, User Experience and all the other things that get us excited.

• Become a mentee
• Become a mentor
• Product Management glossary
• User Experience glossary
• Product playbooks
• Product & UX video library
• Privacy Policy
• Terms and Conditions
• Code of Ethics

Made with in Copenhagen, Denmark

Want to learn more about about good product development, then browse our product playbooks .

Back to Guides

How to run a problem-solving workshop.

What is a problem-solving workshop?

A problem-solving workshop is a rapid session that helps you:

• Understand the root cause of a problem
• Quickly generate ideas to solve it
• Evaluate the ideas to ensure they’re robust
• Make a plan to test or implement the solution

This workshop critically assesses what’s going wrong and helps you find out what your options are to solve it, before you decide on the perfect solution.

Who should run a problem-solving workshop?

Product team leads, such as designers, product managers or engineers can run this type of workshop. There’s no one right person to lead something as important as this.

In fact, the core of your product development should start with the problem rather than the solution itself. It can be tempting to jump straight into features, but until you understand the problem well, you can’t begin to solve it.

When to run a problem-solving workshop

This workshop can be used in various circumstances:

• A show-stopping problem that grinds everything to a halt
• An intermittent problem that you want to get to the bottom of
• A customer or user problem, such as a pain point when using a service or product
• A high-level business problem, for example “too many customer complaints”, “conversion rate is too low”, or “operating costs are too high”

1. Get the right people together

2. identify the right problem.

• 3. Come up with ideas to solve the problem

4. Evaluate the ideas to ensure they’re robust

5. make a plan to test or implement the solution.

Read on to find out how to do all that, and more.

Invite all affected parties to a session. These are people that the problem has a direct impact on. Including those that aren’t impacted may offer a more objective view, but ultimately; more people equals more time. We want to solve problems with haste, so we can find out if it’s the right solution sooner rather than later!

What may appear like the problem, could be one of many observable results of a deeper underlying problem. To identify the ‘right’ or ‘true’ problem, we need to delve into it. This method is often called “Root Cause Analysis”.

There are many ways to conduct a Root Cause Analysis, but the easiest and most pragmatic way is to use the  Five Whys Analysis tactic .

Simply put, asking “why?” at least five times will lead you to the real problem. Solving this root problem subsequently solves all of the surface problems associated with it.

Learn how to run the Five Whys Analysis tactic

3. Come up with ideas to solve your problem

What normally follows identifying the right problem is a flurry of ideas. This usually takes the form of blurting them out at each other – but there are better, more structured ways to capture ideas.  Generating ideas in a structured way gives you time and space to think, as well as building on others’ ideas. The result means more thorough and refined ideas, over a back of the napkin sketch that the loudest person in the room decides is the best thing to do.

Idea-generation tactics for problem solving:

• Mind Map  – Get your brain on to paper, so you can start to form ideas for the methods below.
• Crazy Eights  – Eight ideas in eight minutes
• Reverse Brainstorm  – Come up with ways to make the problem  worse,  then reverse it to get the solution
• Round Robin  – Generate an idea, then have the person next to you build on it
• Storyboard  – Turn your idea into a sequence of events to understand how it might actually work in reality

Once you have a suite of ideas, you’ll want to review them and try some  evaluative tactics .

If you have a lot of ideas, you might want to prioritise the most promising ones to take forward with a decision tactic such as  Priority Map  or  Blind Vote .

Once you have a shortlist of ideas it can be tempting to go with the one that appears most promising. If time is of the essence, and it’s low risk – it might be the right call to just try it out.

However, it’s vital to evaluate ideas for solutions that may be more costly or complicated. Kick the tyres, so to speak.

Evaluating ideas gives you the confidence that your promising idea truly is promising, and is worthy of taking forward to the next stage: prototyping and implementation.

Evaluation tactics for ideas:

• Idea Beetle  –  a set of questions that help you assess if your idea is robust before you progress with it
• Rose, Thorn, Bud  –  a way to review the good, the bad and the potential of an idea
• SWOT Analysis  –  articulate an idea’s strengths, weaknesses, opportunities or threats

If you still have a lot of ideas, you might want to prioritise the most promising ones to take forward with a decision tactic such as  Priority Map  or  Blind Vote .

Now you should have one or two (or more!) evaluated, robust and promising ideas that you want to try out to solve the problem.

Whether you need to work out how to prototype and test the idea, or go ahead and implement the solution right away – you need a plan.

To work out a plan, use the  Sticky Steps tactic , which mentally starts you off at having the solution implemented or prototype tested, then works backwards to today in order to see what steps you need to take.

Once you have a solid plan, create accountability by creating a list of tasks to do, and assigning them to people with a deadline. You can do this with the  Who, What, When tactic .

2 thoughts on “How to run a problem-solving workshop”

Hi I’d love to know approx about how long it should take to run one of these workshops. If you could include that in your very helpful summaries – I think that would be very helpful to plan and market these types of servies.

Appreciate all you do! R

All activities are very helpful.

Appreciate you Nazia Psychologist

Leave a Comment Cancel reply

Let us know what thoughts or questions you have about this guide so we can improve it.

If you leave us your email, we'll let you know if we update this guide based on your feedback.

What is PI planning?

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.

MEET US AT ATLASSIAN TEAM 24

Las Vegas | April 30 - May 2

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.

How To Prepare For A Problem-solving Workshop

Imagine sitting in a room with a firm of doctors. Each specialist carefully analyses every facet of a patient’s case. Everyone with their knowledge at play is geared to provide viable solutions to address the challenges they face.

Although the software design world may seem like a far cry from the medical field, they share a fundamental similarity: both revolve around problem-solving. Designers apply multiple practices to validate and authenticate solutions with our partners.

To align everyone, we set up Problem-Solving Workshops (PSWs). At its core, PSWs are a space to solve problems. Our team will dissect every aspect of the problem, identify potential challenges, and find the best solutions. Finally, we validate the process through testing.

Neil Webb, Design Producer and problem-solving workshop facilitator at MOHARA, shed light on how this process works by answering a few of our probing questions.

What Are Problem-Solving Workshops?

A problem-solving workshop is a collaborative event or session where participants come together to identify, analyse, and develop solutions for a specific problem or set of problems.

It could be a show-stopper of a problem that has stopped work or a way to identify improvement backlog items for your next sprint. The main goal of this process is to foster creative thinking, encourage teamwork, and facilitate learning by sharing ideas, experiences, and perspectives.

A typical problem-solving workshop can take many forms but include the following steps:

➡️ Define the problem: Clearly define and understand the problem(s) to be addressed.

➡️ Brainstorming: Encourage open discussion and the sharing of ideas, allowing participants to think freely and creatively.

➡️ Analysis and evaluation: Analyse and evaluate the proposed ideas, considering their feasibility, effectiveness, and potential impact.

➡️ Solution development: While considering available resources and constraints, develop and refine the most promising ideas into actionable solutions.

➡️ Implementation planning: Create a detailed plan for implementing the chosen solution(s), including timelines, responsibilities, and resource allocation.

At MOHARA, our problem-solving workshops are our take on a Google design sprint . It is a time-constrained, rapid five-stage process to answer essential product questions. It speeds up the design process and lets you quickly test and iterate your ideas.

As a result, you can shortcut the endless debate cycle and compress months of thinking and iteration into a single idea. Therefore, you are reducing risk at a basic level and saving a founder time and money.

What Are the Fundamentals of Setting Up a Problem-Solving Workshop?

Running a successful problem-solving workshop needs the founder’s support. Given that it is their idea and they have already devoted considerable time and effort to research, their insights are extremely valuable. Communicate the workshop’s objectives and deliverables to get the founder’s buy-in.

Assemble a workshop team of five to seven people including a Facilitator, a Lead Designer, a Lead Engineer, and possibly an Engagement Lead. In the case of a large organisation, including more than one stakeholder from the company – ideally subject matter experts – enriches the collaboration and decision-making process.

How Do You Facilitate a Problem-Solving Workshop?

The process should begin with a week of research, onboarding, and setup. To start with, one has to understand the most significant root cause of any given problem.

To achieve this, we interview the client and other key stakeholders and ask them to fill out a pre-workshop questionnaire. This information helps the MOHARA team understand the founder’s vision and long-term goals.

A traditional in-person workshop happens over four to five days. The activities on the first day are all about aligning ourselves as a team to understand the users, their needs, and the different challenges they may face during the product development cycle.

Several problem-solving techniques can be used to brainstorm solutions and get the best outcome. The idea is to choose your product’s most suitable and effective strategy.

How Does Conducting Remote Problem-Solving Workshops Impact the Process?

The shift to remote work has altered our approach to conducting workshops. While we at MOHARA are accustomed to working remotely, the absence of in-person sessions does pose some challenges.

Usually, we can go through the different phases within a week. But, remotely, it’s slightly different: you can’t have someone in a workshop call all day long; the sessions are intense and require a lot of focus.

We must slow things down for the sake of everyone taking part because these sessions help us understand whether users will receive a feature or product well.

We split the PSWs into one or two workshops a week. We then build the prototype, providing daily feedback and ensuring the founder understands what we’re doing, and why.

Having the Right Setup Is Essential for a Remote PSW

For a problem-solving workshop to be successful, the right setup is critical. When we are conducting a session remotely, we do the following:

➡️ Prebuilt templates: Templates are designed in advance for different sessions. The templates help guide all participants through multiple activities and checkpoints and revisit relevant information at any point.

➡️ Set up whiteboard software: We also use interactive whiteboard products to create a space for collaboration and review. Timelines, key deliverables, and communication are other significant factors in ensuring the process is smooth, and that the client feels comfortable and understands where we are going.

What Are the Next Steps?

Participants envision the solution to an identified problem during an ideation session where they sketch out ideas and concepts. The aim is to look for as many ideas as possible and examine examples and relevant cases they have come across elsewhere.

The team will then consider how certain features could resolve a critical challenge. There may be many ideas on how to solve the challenge faced, so the next decision-making stage is very valuable. The team and stakeholders decide which solution and critical features they would like to test and then turn that solution into a high-fidelity prototype.

The last part of the problem-solving workshop focuses on qualitative testing. We want to gain valuable feedback from actual users, so selecting them carefully is imperative. We ask participants to perform tasks, usually using specific user interfaces. While the participant completes each task, we observe the participant’s behaviour and listen for feedback.

What Role Does Prototyping Have in a Workshop Process?

Much of this process is about speed. We do not want to start building anything in code at this stage. Instead, using Figma – our prototyping tool of choice – the designer will lay out various screens and connect them with the specific steps we want users to take.

Based on some of the critical questions defined in our sessions, we will share a link with the users and then give them particular tasks we want them to carry out. We can then test which, if any, of our assumptions were correct, and start to think about some of the primary user journeys, the user experience, and other core features.

What Are the Most Overlooked Aspects of a Problem-Solving Workshop?

There are three aspects of a problem-solving workshop that is often overlooked:

🔶 It’s not a design sprint

It’s important to understand that the entire process is not just about design. There needs to be some technical expertise as well. That is why we don’t call these Design Sprints but rather PSWs. It’s about using design and engineering to solve a problem.

🔶 It’s essential to keep the energy up

One of the significant challenges regarding remote workshops is how much energy is required. If you’re in a room full of people like we used to be, you could generate solutions, get everyone together and build up the excitement.

However, doing it over a screen is tricky. It’s challenging to keep things energised and to avoid reviewing the same points and using valuable time.

🔶 Inclusion is also essential

The idea, especially with remote PSWs, is to ensure everyone has a voice. Only some people will speak up in a session. Naturally, some people are more vocal than others, and these people will generally lead the conversation.

If someone else, however, is given the opportunity to share even the slightest valuable insight, it could change the whole direction of the team’s solutions. It only takes one comment, or perhaps a note. For this reason, everyone must have a voice.

Are There Any Pitfalls?

Several things can go wrong during the process. Someone might drop off a call or have connectivity issues interrupting the flow. We’ve also had situations where the hardware doesn’t work correctly.

From a facilitation point of view, having a plan for each product-solving workshop and a clear outline of what will take place, are essential. That means mapping out the different activities and ensuring people know how long each activity will take. This plan keeps everyone aligned, and the PSW will only be successful with it completed ahead of time.

Lastly, user testing has to be qualitative rather than quantitative because, at this point, you’re asking for detailed information and feedback on the tasks they’ve had to do, particularly to identify any problems. You would need more than quantitative research to get that kind of data.

Do You Have to Check In with Various Stakeholders After the Workshop?

Yes. Client feedback is always valuable. It’s essential to get an update on how they are getting on from a product perspective, as well as gather their insights and feedback on the PSWs process.

Suppose we agree with the client to do further design work post-prototyping or engineering (or both). We would already have discussed those later-stage design phases in more detail during some of the sessions. By the way, this is another reason why having an engineering representative there during these sessions is so valuable.

During the PSWs, we would then compile a list of challenges to write up as questions that we aim to answer with our solution by the end of the workshops. After the PSWs have concluded, we provide feedback in the form of reports with user testing results, including data, a breakdown, and evidence of all the conducted activities.

What Do You Enjoy Most About Setting Up Problem-Solving Workshops?

It’s creative problem-solving at its finest! I enjoy engaging with founders and experiencing their passion for their products. It’s also great to work with the engineers, watch how they engage in the sessions, and identify solutions; having those different viewpoints is essential.

Setting up the workshop is enjoyable, too, because it involves using design tools that are constantly evolving; I am a designer at heart, after all.

Effective planning is the way to foresee risks and aim for success. Now that you have the lowdown on Problem-Solving Workshops, we suggest calling the relevant troops to get started.

It takes a team of experts to navigate challenges and produce a product that makes one proud. So get your tools packed; with Neil’s guidance and tips, you’re certainly off to a good start!

If you find you need more help with problem-solving, why not get in touch with MOHARA?

Related Insights

Prompt Engineering: The Key to Enhancing AI’s Contextual Understanding

Optimising Artificial Intelligence: The Power of Retrieval-Augmented Generation

Diversity in Tech: How We #InspireInclusion at MOHARA

Pioneering together.

Laxmi Building 57 Bermondsey Street London SE1 3XJ

6th Floor, The Hudson 30 Hudson St De Waterkant Cape Town 8001

26th Floor, 246 Times Square Shopping Center Sukhumvit 12-14 Road Khlong Toei Thailand 10110

WeWork, 5th Ave, Manila, 1634 Metro Manila, Philippines

Guadalajara

Colabora Av Chapultepec Sur 480, 44140 Guadalajara, Jalisco, Mexico

WeWork, 240 Richmond Street W, Toronto, ON, M5V 1V6

Join our newsletter

We’ll bring you the latest updates from our ventures, share exciting news from MOHARA and offer insights from our latest blog posts.

Our Partners

© MOHARA 2024. All rights reserved.

Privacy Policy   |  Cookie Policy   |  Terms and Conditions

Sandeep Kashyap

A Step-By-Step Guide to PI Planning (2024)

If you are a business owner like me, I am sure there must have been times when you found that everybody has their own management rituals in the name of “Agile”.

It’s a wild world out there.

During my journey from a software developer to a CEO, I have witnessed Agile going through a significant evolution since its inception.

One such standout is the Scaled Agile Framework (SAFe), a comprehensive and structured methodology designed to tackle the complexities of modern software development head-on. Among SAFe’s key pillars lies the heartbeat of effective execution —PI planning.

Now, I understand that some people have their opinion on SAFe not being agile enough, but that’s a discussion for some other article.

In this article, however, we will decipher PI planning, a vital strategic event that perfectly aligns with the principles of the Agile manifesto .

Check out how these top five software can help you with project planning. 

What is PI Planning?

PI planning, short for Program Increment planning, is a vital planning process in Scale Agile Framework (SAFe) where agile teams conduct a face-to-face meeting event, either virtually or in person, to plan out what they are going to work on in the upcoming Program Increment. 

A Program Increment refers to a set period of time during which a group of agile teams, also known as Agile Release Train (ART),  work collaboratively on delivering the defined value proposition.

You can think of Program Increment as a long-term sprint, where it’s not just your team working on improving website navigation, but the whole ART is working collaboratively on project-level deliverables such as search functionality and overall design consistency, in addition to the improved navigation.

Program Increment planning is a repetitive process that occurs every 8-12 weeks, depending on the length of the PI. ART reviews the previous PI and, if required, adapts to the changes by addressing and re-establishing the dependencies.  

Now, PI planning might seem at odds with the Agile principle of valuing “ Responding to change over following a plan. ” Well, the key here is to strike a balance. While Agile promotes adaptive planning and short iterations, it also values the need for effective coordination and alignment in bigger projects. 

That’s why PI planning falls primarily under the Scaled Agile Framework (SAFe) of software development, where you scale the agile methodologies to incorporate the complexities associated with large-scale projects.

Let’s try to understand what value PI planning adds to SAFe.

Cut the fluff and get to the stuff. Streamline your planning process with these project planning tools in 2024. 

Why do you need PI planning?

Large-scale projects are inherently complex, demanding more than just weekly meetings and retrospectives for effective project management . Such projects require multiple agile teams working together on a common objective, thus necessitating a more comprehensive planning process. 

This is where PI planning comes in. A strategically designed event that ensures complete alignment among all teams within an Agile Release Train (ART) for the upcoming project phase, called program increment.

The essence of PI planning lies in aligning all the agile teams within your ART by setting cross-departmental tasks and team interdependencies. 

In contrast, a lack of well-executed PI planning may cause functional silos to creep in and create a major obstacle to effective execution.

For instance, your design team might work on the user interface independently, while the backend team focuses solely on data integration. As the project progresses, the user interface elements don’t fit well with the data flow, leading to glitches and user experience issues. 

Now, that’s just one situation PI planning helps the ART avoid. Following is the comprehensive list of benefits PI brings to Scaled Agile Framework (SAFe). 

Benefits of well-executed PI planning

• Value stream alignment: SAFe relies heavily on development and business stakeholders working together. PI planning provides a platform for business planners and development teams to find a middle ground for the most effective business growth. It helps to prioritize work, align scopes, and create the most effective product roadmap. 
• Risk mitigation: PI planning involves team members coming from diverse backgrounds, including business, technical, and operational. This mix of talent provides better insights, from both technical and overall business perspectives; subsequently, allowing for better contingency plans. 
• Enhanced visibility: With everyone in the ART having a clear understanding of what they need to do, and how their work may impact the overall progress of the project, ensures a streamlined execution of tasks and flexibility to adapt to dynamic changes. 
• Delivery predictability: As mentioned earlier, business teams rely heavily on development teams to formulate business plans and outcomes under SAFe. PI planning allows development teams and business teams to collaborate and define mutually agreeable and realistic PI objectives. A common method is to design the objectives under SMART criteria . This way, there is less confusion and a better predictability of delivery . 
• Improved collaboration: Collaboration is an essential part of any project’s success. This importance amplifies even more when you are working with diverse teams, not just individuals. PI planning plays an important role in bringing together cross-functional teams. Additionally, a coordinated effort of all stakeholders, including teams, product owners, managers, and other relevant parties, ensure better execution and fewer surprises. 

💡 Read More: How to effectively establish cross-functional collaboration among your teams.

Who should be involved in PI planning?

PI planning is a collaborative process and involves individuals from several departments in an organization. Nonetheless, they are primarily designated under the following roles:

• Release Train Engineer: The Release Train Engineer (RTE) oversees the overall PI planning event. The key responsibilities of the RTE are to guide the participants throughout the event, conduct pre- and post-event meetings, and ensure everything runs smoothly.
• Business owners: A business owner describes the business context to the rest of the participants. 
• Product Owner: Describes the overall product vision and development priorities.
• Product Managers: Describes the feature vision, and prioritizes backlog items. 
• Architects:  System architects and solution architects, offering architectural design insights. 
• Scrum Masters: Scrum masters operate at a team level to facilitate PI planning. They assist RTE and ensure everyone on their team is on the same page.
• Developers: Developers are responsible for estimating the work that needs to be done to deliver the features in the upcoming PI. 

💡 Read More: Project Manager roles and responsibilities .

PI Planning preparation checklist

Program Increment (PI) planning requires planning of its own.  Whether you are a seasoned agile practitioner or just starting out, here’s a handy checklist to guide you through the “planning” for a PI planning event.

1. Identify Participants

The first step is to assemble the right ART members depending on the scope of your project. This includes assigning roles to participants, such as the Release Train Engineer (RTE) to facilitate the event, business owners to guide business priorities, product managers to present feature vision, system architects to provide architectural insights, etc.

2. Organizational Readiness

Next, RTE needs to ensure that strategic alignment exists among participants and stakeholders. Confirm the scope, priorities, and roles, and validate that agile teams have designated members, Scrum Masters, and Product Owners.

3. Content Readiness

Prepare essential briefings, including an executive-level context briefing, product vision presentations, and architectural insights. These briefings provide a clear understanding of the current state, future goals, and technical direction.

4. Logistics Readiness

If the event is virtual, ensure the technical infrastructure is in place for remote participation. Set up communication tools , audio, video, and collaboration platforms for real-time feedback sharing.

Step-by-step PI planning agenda

PI planning events follow a standard agenda to ensure consistency, alignment, and effective communication among ARTs. Usually, the agenda is planned for two days, which can be tweaked to create a split agenda of 2.5 days to coincide with members located across different time zones.

Day 1: 

1. business context: .

Day 1 kicks off with senior executives and business owners setting up the business context, where they reflect on the current state of business and consumer take on the previous PI. 

2. Product/solution vision:

Product owners and managers present the vision for upcoming features and changes in the previous PI. 

3. Architecture vision and development practices:

System and solution architects discuss the architectural vision and changes teams will adopt in the upcoming PI.

4. Planning context: 

RTE sets the stage and explains the planning process and outcomes.

5. Team breakout #1:

The breakout session is for teams to decide on their capacity planning, identify backlogs, identify risks and dependencies, and prepare an initial PI objective.

Team members segregate these objectives into committed and uncommitted objectives based on the risk and uncertainty associated with each one. 

6. Draft Plan review:

During the draft plan review, business owners, stakeholders, and other management review the initial drafts that include the PI objective, capacity & load, risks, and dependencies. 

7. Management review and problem-solving:

The draft plan usually includes some challenges like resource constraints, scopes, and dependencies. Management and team members then negotiate to find a middle ground for aligning the scope with achievable objectives. 

Day 2: 

1. planning adjustments:.

Day 2 begins with management adjusting the planning scope, people, and resources. 

2. Team breakouts #2:

The team continues to plan and present business owners with adjusted PI objectives, to which business owners assign business values as prioritization scores. 

3. Final Plan and Review:

During this session, all teams present their final plan, with all the potential risks and impediments, to the group. If all the business owners agree to the final plan, the PI objectives are shared with everyone.  

4. ART PI risk evaluation:

All the identified risks and impediments in the previous session are evaluated by the ARTs under the ROAM framework .

• Resolved: Teams agree that risk is no longer a concern.
• Owned: The risk can’t be resolved during PI planning, so one of the team takes ownership to eliminate the risk later.
• Accepted: The risk must be accepted as it is since there is no workaround.
• Mitigated: Teams identify a workaround plan for risk.

4. Confidence vote

A confidence vote ceremony is conducted to make sure that attendees are in alignment with PI objectives and that they agree that the plan is achievable. Attendees cast votes with the show of fingers, or digital counters if the PI planning event is online. If the average count is above three, the plan is green-flagged for a go. If not, the plan is reworked. 

5. Plan rework

The plans with low confidence are reworked until agreed upon by everyone.

6. Planning retrospective and moving forward

Finally, the RTE runs a retrospective where they reflect on what went well during the PI planning event, what didn’t, and what could be done better. 

7. Post-PI planning events

After the planning event, RTE and other ART stakeholders write down and communicate the PI objectives with other team members in the ART. The product management breaks down and distributes the tasks among the team members and prepares a roadmap outline for individual teams. Additionally, teams also decide on the timeframe for Innovation and Planning (IP) iteration during the next PI. 

Navigating the PI Planning challenges: Common pitfalls

PI planning is an extensive event with a tightly packed schedule for many things to include. Surely, things are not going to go exactly as planned. Nonetheless, here are some pitfalls that are completely avoidable with a little effort. 

1. Lack of planning

PI planning requires planning. Though the event unfolds according to a standard agenda every time, neglecting to map out the event structure, and role allocation, and providing necessary briefings to the attendees can cause serious disarray and confusion during the event. 

2. Lack of prioritization in your agenda

Since all the individual events in your PI planning are time-boxed, it is important to prioritize the time allocation accordingly. For instance, allocating too much time for events that do not directly contribute to the PI objectives, risk identification, or plan refinement, may force you to make hasty decisions in the planning process. 

3. Running long-boring sessions

You don’t want a PI planning event to be a long presentation given by leaders, just to be preached by the teams. Given the time constraints, it is important for your agenda items to be short and straightforward, leaving more room for actual planning. Additionally, every session should be engaging to keep the participants invested and bring the best out of each other. 

4. Missing out on retrospective insights

Neglecting the insights from previous PI can lead to repeated mistakes and stagnation. Retrospectives are the goldmines for teams to make well-informed decisions. It becomes easier for teams to identify the areas where they are overcommitting or underperforming based on historical data. Encouraging team members to talk about what worked and what didn’t provides you with tested and proven information that you can integrate into your planning process for better results. 

5. Ignoring technical debt

Technical debt refers to the accumulated cost of undone development work, shortcuts, code patches, and other suboptimal coding practices that compromises the quality of your product. Failing to address these issues in the PI planning process can cost teams the flexibility to adapt to new changes quickly. By deliberately addressing these issues head-on in the PI planning process, teams can allocate time for cleanup and mitigation. 

💡Read More: 10 most common Project management challenges (and solutions)

PI Planning vs. Sprint Planning: What is the difference?

PI planning and sprint planning are both planning processes that agile teams rely on to get things done. Nonetheless, they are quite different in terms of scale and context. 

Sprint planning is done by development teams to map out the task they need to complete within the next sprint, a time-boxed period usually lasting 1-4 weeks. 

PI planning entails planning objectives, for the next program increment, a project phase that usually lasts 8-12 weeks. 

Sprint planning involves selecting an item from the product backlog, estimating the effort required, and creating a plan to deliver that item within a sprint.

PI planning has a more comprehensive scope than sprint planning. It includes defining objectives for the next program increment, evaluating the risks associated, and establishing cross-departmental dependencies for streamlining the progress. 

The primary objective of sprint planning is effective workload distribution and resource allocation for the on-time delivery of the user story. 

PI planning involves a more holistic approach to overall business growth. The primary objective of PI planning is to align the scope of all the teams in the ART with business objectives. This requires input from several participants, such as business owners, product owners, development teams, etc. 

Streamline PI planning process with ProofHub

A project management and team collaboration tool resides at the heart of a PI planning event. In today’s dynamic landscape of teams distributed around the globe, having a centralized platform that seamlessly brings everyone together is a must. 

This is where ProofHub comes in. With an array of diverse features , ProofHub is not just a project management and team collaboration tool for agile teams, but also a strategic asset for orchestrating effective planning events. 

1. Seamless collaboration

PI planning is all about effective communication and collaboration. Teams in the ART need to collaborate, share insights, align their goals, and plan objectives cohesively. With ProofHub , this key aspect is taken care of with an array of features that enable real-time discussions and document sharing, ensuring that every team member is on the same page.

From refining user stories to identifying dependencies, ProofHub’s collaboration capabilities facilitate the seamless flow of information, even when the team members are located miles apart.

2. Centralized planning and visibility

PI planning events are always short of time. Juggling spreadsheets, emails, and numerous tools is not the most effective way to manage your PI planning event. 

ProofHub provides everything you need under one roof. The centralized platform allows you to create and manage user stories, prioritize tasks , and assign responsibilities.

This level of consolidation not only saves time but also provides unparalleled visibility into the planning process. Stakeholders can quickly access timelines, progress charts, and updates, eliminating confusion and ensuring everyone remains aligned with the end business objectives.

3. Risk Mitigation

With ProofHub , you can monitor the progress of events, identify potential delays, and make necessary adjustments on the go. Moreover, ProofHub facilitates risk evaluation and contingency planning through its intuitive interface. You can assess potential bottlenecks with Gantt charts , evaluate risks associated with dependencies by highlighting the critical path, and devise contingency plans to mitigate potential disruptions. 

This comprehensive approach to risk management ensures that your PI planning remains flexible.

The best tool for everything from planning to delivery.

PI (Program Increment) planning is not just an event where business leaders gather to hash out a schedule for the upcoming development cycle. It’s a dynamic and strategic process that serves as the heartbeat of an Agile organization. 

This event manifests the essence of Agile principles, fostering an environment of open communication, transparency, and collective ownership. It’s a time to connect the dots between the overarching business goals and the tangible work that teams will undertake.

Unwind the full potential of your agile teams with the 20 best agile project management tools.  

FAQs about PI planning

Is pi planning a match for scrum.

PI planning involves teams coming from diverse departments, whereas scrum is a framework for software development under agile methodology. While technically you can have a two-day planning event for developing the next feature, it does not seem the most effective way to go about it. Sprint planning is beneficial when it comes to Scrum while PI planning is suitable for Scaled Agile Framework.

Who is responsible for PI planning?

Program Increment (PI) planning is a collaborative effort of agile teams to ensure the successful delivery of customer values in the next Program Increment. The key roles involved in PI planning include the Release Train Engineer (RTE), Product owners and managers, Scrum Master, System Architects, and other stakeholders.

How long is PI planning in Agile?

PI planning is usually a two-day-long planning event, which can be extended to incorporate the remote teams located in different time zones.

How do I prepare for PI planning?

The pre-planning phase of PI planning primarily includes four readiness aspects: identifying participants, organizational readiness, content readiness, and logistic readiness. First, identify the participants and assign the roles accordingly. 

Next, Product owners ensure that their team’s backlog is refined with well-defined user stories and acceptance criteria. Collaborate with Product Managers to clarify objectives and align priorities. Furthermore, if your organization is hosting an online PI planning event, make sure that teams are equipped with the necessary tools.

Who organizes PI planning?

PI planning is typically organized by the Release Train Engineer (RTE), who is responsible for coordinating and facilitating the PI planning event. They work closely with Product Management, Scrum Masters, Agile teams, and other stakeholders to ensure that the planning process is smooth, well-structured, and aligned with the organization’s goals. The RTE sets the agenda, schedules the event, and guides the participants through the various activities during the planning session.

What are the inputs and outputs of PI planning?

PI planning involves several inputs and outputs that contribute to the successful alignment of agile teams across the ART. 

• Business context
• Product and architecture vision
• Capacity and velocity
• Customer insights
• PI objectives
• Comprehensive risk evaluation
• Dependencies

What tool is used for PI planning?

Tools that are essential for PI planning are:

• A whiteboard tool, like Microsoft Whiteboard, for creating a collaborative program board. 
• A project management and team collaboration tool, like ProofHub, for documenting processes, file sharing, real-time communication, and contingency planning. 
• A video conferencing tool, like Zoom or Google Meet, for facilitating face-to-face communication.

What is the role of PI planning?

Program Increment planning plays an important role in the Scaled Agile Framework of software development. It provides a platform for the alignment of all the agile teams in the ART with overall business objectives. Additionally, it helps with mapping out and establishing dependencies for streamlined development in the next PI.

• Share on LinkedIn
• Email this Page
• Share on Facebook
• Share on WhatsApp

Try ProofHub, our powerful project management and team collaboration software, for free !

 No per user fee.    No credit card required.    Cancel anytime.

The ART of SAFe

Applying Lean and Agile techniques at scale to bring about effective, sustainable improvement in Culture, Execution and Business Results

Saturday, November 26, 2016

Getting the most from the management problem solving session at safe pi planning.

• Present the vision (Leadership)
• Create a draft plan revealing the flaws and challenges in achieving the vision (Teams)
• Face into the insights generated by the teams (Leadership)
• Communicate the response to the team insights (Leadership)
• Breathe a sigh of relief and craft an achievable set of objectives with a supporting plan (Teams)

Expectation Setting

Structuring the facilitation.

The Retrospective Option

The Simple Study Option

The "Hello Game" Study Option

• How have we improved since our last PI planning event? 
• How could we have improved our preparation activities to enable a more effective PI Planning? 
• What systemic issues are evident in the teams planning that we do not have improvement plans in train to address? 
• What are the top issues most likely to derail our PI execution? 
• What issues are most likely to prevent the teams reaching a committed plan tomorrow if not addressed? 
• In which areas are we facing scope trade-offs, and what is the extent and contributing factors of those causes? 
• What are the key factors contributing to the overabunce of tech stories and widget based objective statements?

“What have we not yet discussed that we should have?”

Preparing for Playback

• Agree who will present the “positive feedback” 
• For each identified action and decision, identify whether it needs to be fed back to the team in the morning and who (RTE or Product Manager) will speak to it. 
• Agree on any pre-briefing that will be given to the Scrum Masters and Product Owners prior to the general Playback session.

Selecting a facilitation approach

13 comments:.

This is a great post Mark - too often I've seen tired management and participants not prepared for or even aware they may be required for anything other than superficial conversation. I love the idea of walking the room after everybody has gone and facilitating each participant to volunteer their own concerns. I've tried before to facilitate this session in a circle with a notepad and nobody really has sufficient time or energy to bring up anything other than the really obvious problems. I will definitely try and use some of these techniques the next opportunity I get to RTE or help facilitate. Thanks, Hamish

Thanks for the feedback Hamish. Would love to hear how you go once you try it. BTW, one of my colleagues tried out the "Hello Game" approach after reading the draft version of this post and decided it should actually be called the "Harry Potter" approach - because it created magic!

A very awesome blog post. We are really grateful for your blog post. You will find a lot of approaches after visiting your post. resource management

I was surfing net and fortunately came across this site and found very interesting stuff here. Its really fun to read. I enjoyed a lot. Thanks for sharing this wonderful information. Aegean College

i love reading this article so beautiful!!great job! best instagram followers app

This article includes very good information. I really enjoyed reading it. Thanks for sharing such an interesting piece of content. Keep sharing. leadership development activities

Sands Casino Resort - Overview, News & Competitors Overview of Sands Casino kadangpintar Resort in Las worrione Vegas, septcasino NV - See Wynn Resorts Casino Resort revenue, industry and

Offering Comprehensive Digital Marketing Services To Businesses Looking To Improve Their Online Presence marketing companies Minneapolis

$21K BUY-IN $500 - $1500 HANDS Good Action with a Nice Comeback and Tons of 토토사이트추천 토토사이트 종류 s

HIGH LIMIT DEALER SHARES HER PERSONAL 파워볼사이트 네임드 SYSTEM

3 SECRET 카지노사이트 안전카지노사이트 Work Missions At The Diamond Resort In GTA 5 Online That You Might Not Know About!

EXCLUSIVE: Crown 바카라검증사이트 토토 먹튀 exposed. Sex trafficking, drugs, money laundering

I'm One of the Best 텍사스 홀덤 게임 Players in the World

Members-only Content

• Monthly Member Events
• Event Session Videos
• Experience Reports
• Research Papers
• Share a Community Event
• Submit an Article to the Blog
• Submit a Member Initiative
• Promote a Training Event

Become an Agile Alliance member!

Your membership enables us to offer a wealth of resources, present renowned international events, support global community groups, and so much more! And, while you’re supporting our non-profit mission, you’ll also gain access to a range of valuable member benefits. Learn more

• Join Us Today
• Member Portal
• Membership FAQs
• Terms and Conditions
• Corporate Members

Agile Conferences

• Agile en Chile 2024
• Agile Executive Forum
• Agile2024 European Experience
• All Agile Alliance Events
• Past Conferences
• Become an Event Sponsor

Virtual Events

• Member Events Calendar
• Agile MiniCon
• BYOC Lean Coffee
• Agile Tech Talks
• Member Meet & Greet
• Agile Coaching Network
• Full Events Calendar
• Community Events
• Non-profit Events
• Agile Training
• Sponsored Meetup Groups
• Submit a Non-profit Event
• Submit a For-profit Training
• Event Funding Request
• Global Events Calendars

Agile en Chile – 2024

• Events Calendar
• BYOC – Lean Coffee
• Member Meet & Greet
• View All Events
• Submit an Event
• Meetup Groups
• Past Conferences & Events

Agile Essentials is designed to bring you up to speed on the basic concepts and principles of Agile with articles, videos, glossary terms, and more.

Agile Essentials

Download the Agile Manifesto

To download a free PDF copy of the Agile Manifesto and 12 Principles of Agile, simply sign-up for our newsletter. Agile Alliance members can download it for free.

• Agile Essentials Overview
• Agile Manifesto
• 12 Principles Behind the Manifesto
• A Short History of Agile
• Subway Map to Agile Practices
• Agile Glossary
• Introductory Videos

Recent Blog Posts

Agile Coach Camp Worldwide is going to Costa Rica

Agile Alliance Call for Nominations for the Board of Directors

Agile Alliance Launches Young Professionals Committee

View all blog posts

Agile Resources

The new agile resource guide.

Find Agile services and products from our member companies in our new Agile Resource Guide . Many listings in the guide feature exclusive offers just for Agile Alliance members. View the guide 

• Remote Working Guide
• Event Sessions
• Content Library

Sustainability Manifesto

The  Agile Sustainability Initiative has created the Agile Sustainability Manifesto in an effort to grow awareness about sustainability within the Agile community and inspire a more sustainable way of working. Read and sign now

MEMBER INITIATIVES

• Agile Sustainability Initiative
• Principle 12 Initiative
• Agile in Color Initiative
• Agile Coach Camp Worldwide
• Agile Coaching Ethics

View all initiatives

Your Community

Global development.

• LATAM Community
• India Community

Global Affiliates

• Community Groups
• Community Services
• Member Initiatives
• LATAM Community Development
• India Community Development
• Volunteer Signup

OUR POLICIES

Become a sponsor.

Being an Agile Alliance sponsor is a great way to introduce your company to our members to build awareness around your products and services. The Call for Agile2024 Sponsorships is now open, and there are great options and opportunities still available! Learn more >

• About Agile Alliance
• Code of Conduct
• Board of Directors
• Agile Alliance Brazil
• Agile Alliance New Zealand
• Policies, Reports & Bylaws
• Logo and Media Files
• Become a Sponsor

Experience Report

The sun never sets on the problem-solving workshop, about this publication.

A fundamental agile principle is  “…the team reflects at regular intervals how to become more effective”  The SAFe Inspect and Adapt Problem Solving workshop is a wonderful opportunity for everyone on an Agile Release Train (ART) to reflect on becoming more effective. However, what happens when the ART teams are massively distributed, such that the Sun truly never sets on the ART? How do you provide everyone on the ART an opportunity to reflect and collaborate with others who have similar interests, and not just their local cohorts? How do you enable all to participate in the problem-solving session, to raise and solve problems that are important to them, and not just the problems that are important and visible to “home base” or as we called it, the mother ship? This is the situation we faced at a large multi-national energy company preparing to conduct their first SAFe problem-solving workshop. This is our story for how we executed a problem-solving workshop for an ART on which the Sun never set.

1.     INTRODUCTION: “ The Team Reflects at Regular Intervals How to Become More Effective ” – Agile Principles

Agility is not just about continuously learning and adapting the work product, but also reflecting on and adapting the work process itself. Continuous improvement is fundamental to high performing teams and most agile methodologies have a built-in process review like Scrum’s retrospective. The Scaled Agile Framework (SAFe  tm ) builds on top of this team level view with a problem-solving workshop that is conducted at the end of a Program Increment (big time box) to understand the opportunities for improvement across all teams on the Agile Release Train (ART).

2.     BACKGROUND

Our client is a marquee multi-national energy company with operations around the globe and with an ART spanning the globe. While headquartered in US, teams are located across the US and around the world including London, Buenos Aires, Manila, Perth, and Kazakhstan. Literally, the Sun does no set on the program. Our program was moving applications from the on-premise data center to the cloud. While our program was organized on paper as SAFe Solution Train (a train of trains), it operated very much like an oversized single ART, with over 30 teams and with nearly 400 people involved. Our “train” ran 6 two-week iterations, including a 2-week IP sprint. This was our sixth PI and to date, and while the individual teams conducted team level retrospectives, there had not been an overall review of how the train(s) worked together. As the trains were growing rapidly beyond what heroic ad hoc problem solving could resolve, we decided it was important to start systematically “reflecting at regular intervals how to become more effective” and began planning a SAFe problem solving workshop.

3.     NO MOTHERSHIP

The SAFe problem-solving workshop is part of the SAFe Inspect and Adapt event. General guidance for the problem-solving workshop is that it is about a two-hour process, where all members of the ART participate. This creates a fantastic opportunity for people to collaborate with others beyond their immediate team members. There is an implied assumption that everyone is in the same room. This, of course, was totally impossible for us, unless we wanted to fly everyone to corporate head office in the US.

A typical solution to this distribution problem is what we sometimes referred to as the “mothership” approach. We could hold the problem-solving session at the head office – the mothership – and use video collaboration tools like WebEx or GotoMeeting or Zoom to engage everyone else. Unfortunately, this approach was most likely to only give us a North American point of view and not a true global view. We wanted to avoid a North America centric problem-solving session for as one plucky Australian noted, more than 50% of the value of the train came from outside of North America. Experience suggests when there is a face to face mothership style meeting with other members engaging online, the online members are not engaged and are at best lurkers.

Conducting a “mothership” problem solving workshop, could have reinforced the perception that head office was the center of the universe as most of the senior staff such as the RTEs, Program Managers, Architects, were located there. Finally, scheduling a single “mothership” session is not respectful of people because we would be asking a fair portion of the train to participate in the middle of their night. Therefore, we did not want to conduct a “mothership” style of problem-solving workshop. We needed an approach that created the same opportunity for everyone to participate.

4.     EVERYONE ONLINE

While co-location and face to face conversations are much touted in the agile community, the reality of large-scale systems development is that many people from around the world collaborate to create those large systems. The Agile Principles were written nearly 20 years ago when collaboration technology was at its infancy. Ideally teams that must work closely together are physically close together, but they still need to interact with their global colleagues. Online collaboration is a fact of life and modern tools offer a fair approximation of a physical face to face meeting. With the decision made to conduct the problem-solving workshop online, the next issue was determining how to run the meeting on a program with a never setting Sun.

5.     AN AGENDA FOR A GLOBAL WORKSHOP

SAFe outlines a six-step agenda for the two-hour problem-solving workshop:

• Agree on the problem to solve
• Apply root cause analysis (5 Whys)
• Identify the biggest root cause using Pareto analysis
• Restate the problem for the biggest root-cause
• Brainstorm solutions
• Identify improvement backlog items

It was apparent that we were not going to execute this agenda as a two-hour workshop, at least not if we wanted the entire train to actively participate. Instead, we devised a 1 week rolling agenda:

• Dec 12th by this date the teams are expected to have conducted a “mini retrospective” identifying what each team sees as the program level issues.
• Dec 13th Publish and collate Issues discovered during the mini retrospectives.
• Dec 13th Vote on the published issue list to select the top 5 issues.
• Dec 14th Schedule the problem-solving workshop published and name the facilitators.
• Dec 17th Conduct problem solving sessions
• Dec 19th Present a summary of the workshop

5.1       Step 0: Train the Scrum Masters on the Process

We were relying on the Scrum Masters to “fly solo” and work with their teams to facilitate the event. Thus, we trained our Scrum Masters with the intention behind the SAFe problem-solving workshop, our multi-day rolling agenda, and their role in making it happen. This was a two-hour training session with the agenda dates and activities.

5.2       Step 1: Agreeing on the problem to solve.

Step one in the SAFe problem-solving agenda is to come up with the three to five problems that are of the highest interest to everyone on the train. The intention of this step is to give everyone in the room a voice. In a text book problem-solving session, everyone is in the same room and usually writes issues of concern to them on a sticky note. These are posted on a board and everyone dot votes on the top five or so issues. Groups of people with a common interest can then collaborate. This creates a wonderful opportunity for greater social cohesion because people can collaborate with others who share a common interest rather than just their familiars.

Unfortunately, or fortunately, depending on your point of view, corporate IT is conservative While there are numerous cloud-based shared document tools, access to these tools are blocked through the corporate firewall due to security concerns. While this is often annoying, as one IT manager once remarked “we haven’t been in the news, and we don’t intend to be” Conservatism certainly has its virtues, but we needed the equivalent of an electronic flipchart. Fortunately, the organization used Microsoft OneNote which worked quite admirably for us.

Instead of writing issues on post-it notes and sticking the notes onto a flip chart sheet, the Scrum Master worked with their team to capture in Microsoft OneNote the issues the team believed were impeding progress at the “program level”. In our distributed agenda, we gave the Scrum Master three days to gather candidate issues and get them into a OneNote team page. After the issues were captured by the teams in OneNote, the three authors of this paper consolidated the issues and created a list of 20 program level issues. In retrospect it may have been more appropriate to have the teams themselves perform an affinity mapping exercise to consolidate the team issues. However, in our opinion at this time, this would have been a significant coordination effort with very little gain.

For the dot voting, we used PollEv.com and asked people vote on their top issues over a 2-day period. PollEv.com enables people to respond to online questionnaires using either their mobile device or desktop computer. We ran a quick spike to test PollEv.com to create familiarity with the tool by asking people to vote for their favourite science fiction movie. The poll response was at best disappointing, only 20 people responded to the poll or about 5% of the train. While we were disappointed by the lack of interest, we were also thankful that nearly 400 people were not eagerly waiting to collectively jump into the workshop.

Despite the low polling response, this problem identification step was an important step for us because the problems raised were the problems the teams were experiencing and not necessarily the problems program management at the mothership thought were relevant. Without this step, we would have had a very limited view of the problems the widely-distributed teams were experiencing.

The top 5 problems identified were:

• There is no visibility for which team owns certain features (e.g. monitoring and alerts). This has led to duplication of work.
• Dependencies between teams are not clear during sprints.
• Lack of team objectives and identity make it hard to understand what a team does.
• Compliance activities take a long time.
• How should support be structured for cloud migrations?

The benefit of this step was these issues caught head office – the mothership – a bit by surprise. For example, head office had good visibility into team ownership of features and therefore assumed that of course the teams must also have good visibility. By giving voice to all members of the train, we were able to draw attention to a real problem that was not on the management radar.

5.3       Steps 2 to 5: The Workshops

In the textbook version of the problem-solving workshop, after agreeing on the problem to solve, the group immediately rolls into the root cause analysis. That is the benefit of co-location and face to face communication: rapid decision-making action. Distribution across time zones, unfortunately, extends decision making time because of the coordination delays. It took us 3 days to get set up for the root cause analysis. The first day was spent setting up and verifying access to our pages in OneNote. The second day was spent scheduling the workshops. The third day was used to conduct the training to prepare the participants for the workshop.

Scheduling the workshop was at best a compromise between having the whole team present and respect for people. A consequence of having a program on which the Sun never sets is if we wanted to create the opportunity for everyone to simultaneously participate on the issue of their choice, then someone was losing sleep. This is not showing respect for people. The best compromise we came up with, was to schedule three, two-hour workshops throughout one day: one at noon central time (GMT-6), one at 6 pm central, and the final one at 10 pm central. While we had started with 5 issues, we reduced our list to the top three because we did not have enough facilitators to cover 5 workshops.

The intention behind our scheduling was to have at least one workshop scheduled for a time that someone could attend that would be reasonably convenient for them in their time zone. Of course, the topic for the reasonably convenient workshop may not be of interest to the participant. In addition, for someone who had a keen interest in a specific problem that was scheduled at an inconvenient time may have to choose between sleep and collaborating. Not ideal, but at least that would be their choice.

We continued to use Microsoft OneNote as our collaboration tool. In a OneNote document we created three sections, one for each problem and set up the SAFe fishbone diagram for each. OneNote allows multiple individuals to simultaneously create and edit content on the page; very much an electronic flip chart. The workshops were conducted in WebEx and we had two facilitators per workshop. One facilitator was the “driver” actively engaging and facilitating the session, while the other was the “navigator” keeping an eye on the chat window and engaging with individuals through chat.

Participation was voluntary for this first problem-solving session because we only needed to validate whether our agenda and tooling worked. While we were disappointed by the low participation rate of 20-30 per workshop, we were also grateful that we did not have to facilitate an interactive online workshop with 100+ people in it with our initial attempt in combining all the different technologies.

We timeboxed the root cause analysis to 20 minutes. Participants were initially a little hesitant to engage with the fishbone diagram but that is what the facilitators are for: to help participants move out of their comfort zones. Soon, issues began to, almost magically, appear on the shared page. It was fun to watch as participants engaged in the root cause analysis.

After root cause analysis, we moved to the next agenda item – identify the biggest root cause. We identified the biggest root cause by requesting participants “dot vote” on the fishbone diagram and simply place an “X” on what they believed was the biggest root cause. This was in a word, messy. It would certainly have not work well if we had a large group to work with. For future workshops we would have to transcribe the analysis to another OneNote page for the dot voting.

Once we identified the biggest root causes, we moved onto re-writing the problem statement. The SAFe training materials remind people that a problem well-stated is a problem half solved. In one workshop, the original problem “lack of team objectives make it hard to understand what a team does” was re-written as “I don’t know what other teams are doing and therefore I do not know who I depend on and therefore who I need to talk to” As facilitators, we probably overstepped our boundaries: rather than asking “powerful questions” we almost took the wheel ourselves. It is one thing to ask people to post their thoughts on a fishbone diagram. It is quite another to get people to collaboratively write a statement online. Part of our motivation to “grab the wheel” was to get something done within the timebox. This behaviour on our parts is something we will have to be more cautious about in future. We also took note that future participants will be more familiar with the process and will hopefully be less hesitant to participate.

After restating the problem, we moved to the next agenda item and brainstormed solutions. We simply used a blank page in OneNote to let everyone write their solutions, and then we followed up with a dot vote to pick the actions for us to take. These actions were either implemented as new “working agreements” or added to the program backlog:

• Establish a regular meeting between business owners and their POs where the business owners can make their goals clear to the PO
• Highlight the team’s objectives and benefits during PI Planning
• Scrum Masters add their team objectives to their team descriptions in MS Teams
• Build and maintain a SAFe program board

A day after the workshop we consolidated the contributions and outcomes in the problem-solving workshop page in OneNote and broadcast a summary to all members of the train.

6.     LESSONS LEARNED

This experience highlighted the importance of the problem-solving workshop and creating an opportunity for all voices to be heard. This was the sixth PI for these trains and yet this was their first problem solving workshop. The workshop revealed problems that the members of the trains were experiencing but were not on the management radar. Even with the best of intentions, on a very large distributed train, it is all too easy to become disconnected from the needs of the far-flung teams. This problem-solving workshop is a massive opportunity to mitigate this “mothership” syndrome. Our experience demonstrates the value of a globally distributed problem-solving workshop that creates equal opportunity for all voices to be heard.

While we were able to validate our global agenda, the next lesson learned is running a highly distributed workshop is a significant logistical undertaking. Potentially two orders of magnitude more planning than a comparable co-located workshop. The logistics for running the workshop had long been an impediment to scheduling the workshop. For a large distributed train, there will be considerable effort required to prepare and coordinate all teams around the globe. SAFe suggests the workshop only requires two hours. It took us over a week to plan and execute the workshop. One person was almost fully dedicated to this effort. The price of a large distributed team is an order of magnitude increase in both coordination effort and coordination delays. The value in learning what is really impeding work can be priceless.

Some other lessons learned:

• Surprise – a large logistically complex workshop will not happen unless leadership drives it.
• People do not mind losing sleep to solve a problem if the problem is of interest to them and it is their choice to participate or not.
• The problem causing the teams the most pain are often not what management thinks are the problems causing the teams the most pain.
• Managing the logistics of a globally distributed workshop are easily an order of magnitude more time consuming and complex than running a local face-to-face workshop.
• Even primitive collaboration tools can help you run a distributed problem-solving workshop(s).
• People require additional training ahead of time to run an effective distributed problem-solving workshop

Was it worth it? Yes, for if the Sun never sets on your program, then you owe it to everyone in the program to discover what their concerns and issues are and not what the mothership thinks they are.

7.     ACKNOWLEDGEMENTS

We would to thank Lise Hvatum our shepherd whose guidance and recommendation was greatly appreciated. Also we wish to express our gratitude to Rebecca Wirfs-Brock for her support and help.

• Download the Experience Report
• Rochelle Tan
• Steve Adolph
• Report Source
• Download Report

You must be an Agile Alliance member to download the report. Please log in to your account now, or join us to take advantage of all our members-only events and resources.

Your Bookmarks

No favorites to display. You must have cookies enabled to add bookmarks.

Have a comment? Join the conversation

Related agile experience reports, restarting scaled agile development at austrian post, navigating mobile robotics development & delivery using agile, making it stick: driving agile behaviours with influence, not authority, luck, design, tears & passion – my story of building an agile consulting practice in africa, discover the many benefits of membership.

Your membership enables Agile Alliance to offer a wealth of first-rate resources, present renowned international events, support global community groups, and more — all geared toward helping Agile practitioners reach their full potential and deliver innovative, Agile solutions.

Thank you to our valued Agile Alliance Annual Partners

Our new Annual Partner Program offers a new and exciting level of engagement beyond event sponsorship.

Our Cornerstone Corporate Supporting Members

Our Corporate Supporting Members are vital to the mission of Agile Alliance.  Click here to view all corporate members.

©2024 Agile Alliance  |  All Rights Reserved  |  Privacy Policy

©2024 Agile Alliance All Rights Reserved  |  Privacy Policy

• Welcome back!

Not yet a member? Sign up now

• Renew Membership
• Agile Alliance Events
• Agile en Español
• Agile en Chile
• Resources Overview
• Agile Books
• Content Library by Category
• Content Standards
• Privacy Policy
• Cookie Policy

Privacy Overview

10 Tips for Facilitating Your Problem-Solving Workshop

A problem-solving workshop is a structured approach to address a particular challenge or issue that a team or organization is facing. The workshop is designed to bring together a diverse group of individuals with different perspectives, skills, and knowledge to collaborate on identifying and solving the problem at hand.

The workshop typically involves a series of activities and exercises designed to help participants understand the problem, generate ideas for potential solutions, and evaluate and prioritise those solutions based on a set of criteria or metrics . Depending on the nature of the problem and the desired outcomes of the workshop, the exercises may include brainstorming sessions, group discussions, role-playing exercises, prototyping, or other activities.

The goal of a problem-solving workshop is to create a collaborative, creative, and open environment where participants feel empowered to share their ideas, challenge assumptions, and work together towards a common goal. By bringing together a diverse group of individuals with different perspectives and expertise, the workshop can tap into a wide range of knowledge and experience, which can lead to more innovative and effective solutions.

The workshop may be facilitated by an internal or external facilitator, who can help to guide the participants through the process and keep them focused on the problem at hand. Depending on the complexity of the problem and the size of the group, the workshop may take anywhere from a few hours to several days to complete.

Our top tips for facilitating a problem solving workshop are:

• Clearly define the problem: Before starting the workshop, make sure the problem is clearly defined and understood by all participants.
• Establish ground rule s: Set clear guidelines for how the workshop will be conducted, including rules for respectful communication and decision-making.
• Encourage diverse perspectives: Encourage participants to share their diverse perspectives and experiences, and consider using techniques such as brainstorming to generate a wide range of ideas.
• Use a structured process: Utilize a structured problem-solving process, such as the six-step process outlined by the International Association of Facilitators, to guide the workshop.
• Promote active listening : Encourage participants to actively listen to each other and seek to understand different viewpoints.
• Encourage collaboration : Foster a collaborative atmosphere by encouraging teamwork and shared ownership of the problem-solving process.
• Facilitate decision making : Help participants make informed decisions by providing them with the necessary information and resources.
• Encourage creativity : Encourage participants to think creatively and outside the box to generate new ideas and solutions.
• Monitor and manage group dynamics : Pay attention to group dynamics and intervene as needed to keep the workshop on track and prevent conflicts.
• Follow up and review: Follow up on the outcomes of the workshop and review the results to continually improve the problem-solving process.

Here are some exercises that may be more fun and engaging for a problem-solving workshop:

• Escape room : Create an escape room-style challenge that requires participants to solve a series of problems to escape the room.
• Treasure hunt: Create a treasure hunt that requires participants to solve clues and riddles to find hidden objects or reach a goal.
• Charades: Have participants act out different scenarios related to the problem and have the rest of the group guess what they are trying to communicate.
• Jigsaw puzzles : Use jigsaw puzzles as a metaphor for solving problems and have participants work together to piece the puzzle together.
• Improv games: Use improv games, such as “Yes, And,” to encourage creativity and build teamwork skills.
• Scavenger hunt : Create a scavenger hunt that requires participants to solve clues and challenges to find hidden objects or complete tasks.
• Board games : Use board games that require problem-solving skills, such as escape room-style games or strategy games, to make problem-solving more interactive and fun.
• Puzzle-based challenges: Create puzzle-based challenges that require participants to solve a series of interconnected problems to reach a goal.
• Role-playing games : Use role-playing games, such as Dungeons and Dragons, to encourage creative problem solving and teamwork.
• Creativity challenges : Use creativity challenges, such as “the Marshmallow Challenge,” to encourage out-of-the-box thinking and teamwork.

In conclusion, a problem-solving workshop can be a powerful tool for teams and organisations looking to tackle complex challenges and drive innovation. By bringing together a diverse group of individuals with different perspectives and expertise, the workshop can create a collaborative, creative, and open environment where participants feel empowered to share their ideas, challenge assumptions, and work towards a common goal.

While the success of a problem-solving workshop depends on many factors, such as the facilitation, the quality of the problem statement, and the engagement of the participants, the potential benefits are significant. By tapping into the collective intelligence of the group, the workshop can generate new ideas, identify blind spots, and build consensus around potential solutions. Moreover, the workshop can help to foster a culture of collaboration, learning, and innovation that can have a lasting impact on the team or organization.

Related Posts

The 16th Annual State of Agile Report

How Do Web3 and Agile Combine To Enhance Development

Difference Between Agile and Explain Organic Agile

Why Spillover Happens and Why You Shouldn’t Worry

The Johari Window and Agile Methodologies – An Explosive Combo

“Dual Track” Agile

Main Differences Between Three Concepts – Agile, Scrum, And Kanban

Why Teams Outcome Is More Important Than Its Velocity or Even Output

Leave a Comment Cancel reply

Your email address will not be published. Required fields are marked *

Save my name, email, and website in this browser for the next time I comment.

Copyright © 2023 Agile Heuristics. All rights reserved. Agile Heuristics Ltd is a private limited company, registered in the United Kingdom, with company number 14699131

• Skip to content

Problem-solving workshop: Step-by-Step

A problem-solving workshop is held by the Agile Release Train and its purpose is to address systematic problems. The workshop that concentrates on identifying the problems, not just addressing the symptoms, is facilitated by the Release Train Engineer and time-boxed to maximum of two hours. What are the six steps of the workshop?

In SAFe® (Scaled Agile Framework for Enterprises®), problem-solving workshop is done during the Inspect & Adapt (I & A) event. I & A  is held at the end of each Program Increment, and it forms the basis for relentless improvement, one of the four pillars of the SAFe House of Lean , and a dimension of the Continuous Learning Culture core competency.

During the three parts of I & A event (PI System Demo, Quantitative and Qualitative measurement, and Retrospective and problem-solving workshop), the ART demonstrates and evaluates the current state of the solution and teams reflect and identify improvement backlog items. In this article we are going to concentrate on the last part of the event, problem-solving workshop, during which teams systematically address the larger impediments that are limiting velocity.

Problem-solving workshop consists of 6 steps

Step 1: agree on the problem to solve.

Clearly stating the problem is key to problem identification and correction. It enables more focused investigation, time-saving, and avoids ‘ready, fire, aim’ approach. On the other hand, a problem that is not well defined, may result in failure to reach the proper countermeasure. To identify and agree on the problem to solve, the teams should spend a few minutes clearly stating the problem, highlighting the ‘what’, ‘where’, ‘when’, and ‘impact’ as succinctly as they can.

Step 2: Apply root-cause analysis and 5 whys

The Root-cause analysis and the ‘5 Whys’ technique is used to explore the cause-and-effect relationships underlying a particular problem. It helps to avoid assumptions and logic traps, trace the chain of causality in direct increments from the effect to a root cause.

The root cause analysis (fishbone or Ishikawa) diagram features 5 main ‘bones’ that represent typical sources of problems in development (tools, people, program, process, environment). Team members then brainstorm causes that they think contribute to the problem to be solved and group them into these categories. Once a cause is identified, its root cause is explored with the 5 Whys technique. By simply asking ‘why’ multiple times, the cause of the previous cause is uncovered, and added to the diagram. The process stops once a suitable root cause has been identified and the same process is then applied to the next cause (© Scaled Agile, Inc.).

Step 3: Identify the biggest root-cause using Pareto analysis

Team uses Pareto analysis (or 80/20 rule) to narrow down the number of actions that produce the most significant overall effect. It is based on the principle that 20% of root causes can cause 80% of problems and it has proved useful where many possible sources and actions are competing. Once the team writes down all the causes-of-causes, they identify the biggest root-cause using dot-voting – every team member has five dots on its disposal, and he can allocate them to one or more items he thinks are most problematic. Then they summarize votes in Pareto chart that shows collective consensus on the most significant root-cause.

Step 4: Restate the new problem for the biggest root-cause

Team picks the most voted item from Pareto chart. They restate it clearly as a problem and add economic impact of the problem to the description.

Step 5: Brainstorm solutions

During the brainstorming activity that lasts about 15 – 30 minutes, team brainstorms as many possible corrective actions as possible. The goal of activity is to generate as many ideas as possible, without criticism or debate. Team members should let their imagination soar and explore and combine all the ideas that arise and in the end dot-vote to identify top contenders.

Step 6: Identify improvement backlog items (NRFs)

In the end of the problem-solving workshop, up to three most voted solutions are identified. Solutions are then rephrased as improvement stories and features to be fed directly into the PI Planning event that follows the I & A event. During that event, the RTE helps ensure that the relevant work needed to deliver the identified improvements is planned. This closes the loop, thus ensuring that action will be taken, and that people and resources are dedicated as necessary to improve the current state. In this way, problem-solving becomes routine and systematic, and team members and ART stakeholders can be assured that the train is solidly on its journey of relentless improvement (© Scaled Agile, Inc. ).

You may also like

Business Agility Elevated: The Integral Role of SPCs

• Uncategorized

5 ways a Scrum Master can encourage learning

We are back in Europe and hope you join us!

Prague, Czech Republic, 15 – 17, May 2023

Evolving the Scaled Agile Framework:

Update to SAFe 5

Guidance for organizing around value, DevSecOps, and agility for business teams

• SAFe Contributors
• Extended SAFe Guidance
• Community Contributions
• SAFe Beyond IT
• Books on SAFe
• Download SAFe Posters & Graphics
• Presentations & Videos
• FAQs on how to use SAFe content and trademarks
• What’s new in the SAFe 5.1 Big Picture
• Recommended Reading
• Learn about the Community
• Member Login
• SAFe Implementation Roadmap
• Find a Transformation Partner
• Find a Platform Partner
• Customer Stories
• SAFe Training

Making and meeting small commitments builds trust. —Nonaka and Takeuchi, The Knowledge-Creating Company

PI Objectives

During PI Planning , teams create PI objectives, which are the things they intend to accomplish in the upcoming Program Increment (PI) . These provide several benefits:

• Provide a common language for communicating with business and technology stakeholders
• Creates the near-term focus and vision
• Enables the ART to assess its performance and the business value achieved via the  Program Predictability Measure
• Communicates and highlights each team’s contribution to business value
• Exposes dependencies that require coordination

SAFe relies on a rolling wave of short-term commitments from Agile teams and trains to assist with business planning and outcomes, resulting in improved alignment and trust between development and business stakeholders. These are communicated via PI objectives.

While, by its very nature, development is uncertain, the business depends on teams for some amount of reliable, predictable forecasting. Too little, and the business can’t plan. Too much, and the business has committed to longer term plans, which are at best unreliable, and also limit agility. Business and technology stakeholders need something in between, and that is a primary purpose of PI objectives. In addition to alignment, the process of setting realistic objectives also helps avoid too much work in process (WIP) in the system. PI objectives are built largely bottom-up as the teams identify them during PI planning.

Building the Team PI Objectives

During PI planning, the teams get presented with new Features and plan the Stories they need to deliver these alongside stories that represent work from their local context. This work is described as a set of specific team PI objectives. Doing so requires estimating and planning, knowledge of the team’s capacity, analysis of upcoming features, defining stories for the Team Backlog , and, finally, summarizing the information into simple business terms that can be understood by everyone.

As for the number of objectives a team should establish, there is no fixed rule, but 7-10 committed objectives (plus 2-3 uncommitted; see below) seem to work best. More, and the detail and specificity are hard to understand and process by other teams and the team’s business partners. Plus there are too many to review and process in a medium to large ART. Less, and the level of abstraction or aggregation is probably too high to be measured objectively at the end of the PI.

Figure 1 illustrates an example of one team’s PI objectives.

Differentiate between Features and PI Objectives

The team’s PI objectives often relate directly to intended features; indeed, many are the same. However, the mapping is not always straightforward, since some features require the collaboration of multiple teams, as Figure 2 illustrates.

Note that some features (such as Feature A) can be delivered by an individual team; others (Feature B) require the collaboration of several teams. In addition to features and inputs to features, other team objectives will appear as well. These can include technical objectives (for example, the proof of concept in Figure 1) that enable future features, enhancements to development infrastructure, Milestones and others. All the results of the planning process are captured in the team’s objectives.

Features and acceptance criteria are excellent tools to help understand, capture, and collaborate around the work that needs to be done, but it’s all too easy to get caught up in ‘finishing the features’ and missing the overall goals hiding inside. PI objectives help shift focus away from developing features to achieving the desired business outcomes.

A better understanding of the intent offered by direct conversations with the Business Owners often results in the teams providing new perspectives to System Architects/Engineering  and Product Management and quickly finding ways to apply their expertise to create better solutions.

(Note: The advanced topic article Role of PI Objectives further explains the differences between team PI objectives and features and provides additional insights into their usage and value.)

Committed and Uncommitted Objectives

Committing to, and delivering, a series of short-term objectives helps to build trust. Trust allows all stakeholders to move forward with confidence and to base decisions and plans on what is ‘very likely to be true very soon’. But planning with confidence in the face of the uncertainty inherent in research and development is difficult. Things don’t always go as planned, and it’s simply prudent to build some small amount of buffer into the system. If the buffer is too big, then less might be accomplished than would otherwise be the case. If the buffer is too small, many commitments may turn out not to be feasible and planning and confidence erodes. To address, this SAFe recommends teams use both committed and uncommitted objectives during planning. Uncommitted objectives help improve the predictability of delivering business value since they are not included in the team’s commitment or counted against teams in the program predictability measure.

Uncommitted objectives are used to identify work that can be variable within the scope of a PI. The work is planned, but the outcome is simply not certain. Teams can apply uncommitted objectives whenever there is low confidence in meeting the objective. This can be due to many circumstances:

• Dependencies with another team or supplier that cannot be guaranteed.
• The team has little to no experience with functionality of this type. In this case the teams may plan ‘Spikes’ early in the PI to reduce uncertainty.
• There are a large number of fairly critical objectives that the business is depending on and the team is already loaded close to full capacity.

In this case, a few (no more than 2-3) uncommitted objectives are prudent. However, teams do their best to deliver the uncommitted objectives, and they are included in the capacity and plan for the PI. However, since these objectives might not be finished in the PI, stakeholders plan accordingly.

Uncommitted objectives provide several benefits:

• Improved economics – Without uncommitted objectives, a team is committing to a 100 percent scope in a fixed timebox. This forces teams to trade off quality or build other buffers into the system. The other buffers can accumulate , and convert ‘uncertain earliness to certain lateness’, resulting in less overall throughput.
• Increased reliability – Uncommitted objectives represent variable scope, allowing confidence in the delivery of the main priorities. In turn, delivering on the stated commitments is the most important factor in building trust between the teams and the stakeholders.
• Adaptability to change – To reliably deliver on a cadence, uncommitted objectives provide the capacity margin needed to meet commitments, yet alter priorities if necessary, when fact patterns change.

Write SMART PI Objectives

Team PI objectives are a summary of a team’s plan for the PI. They are critically important. Sometimes the descriptions may be very technical and/or a little vague. As a countermeasure, teams make their objectives SMART:

• Specific – States the intended outcome concisely and explicitly as possible. (Hint: Try starting with an action verb.)
• Measurable – It should be clear what a team needs to do to achieve the objective. The measures may be descriptive, yes/no, quantitative, or provide a range.
• Achievable – Achieving the objective should be within the team’s control and influence.
• Realistic – Recognize factors that cannot be controlled. (Hint: Avoid making ‘happy path’ assumptions.)
• Time-bound – The time period for achievement must be within the PI, and therefore all objectives must be scoped appropriately.

Communicating Business Value with PI Objectives

As objectives are finalized during PI planning, Business Owners collaboratively assign ‘business value’ to each of the team’s objectives in a face-to-face conversation. The value of this particular conversation with the team cannot be overstated, as it communicates the strategy and context behind these weighting decisions. Business Owners use a scale from 1 (lowest) to 10 (highest) to rate each objective. They need not be ‘normalized’ across teams; every team has some highest priority (rated 10) items.

Business value is assigned, not calculated, and serves as an input to execution considerations. Many of the team’s objectives provide direct and immediate value to the solution. Others, such as Enablers  (e.g., advances in infrastructure, development environments, and quality initiatives) allow the faster creation of future business value. All of these factors must be weighed in the final balance.

Finalize Team PI Objectives

When objectives have been made ‘SMARTer,’ uncommitted objectives have been identified, and business value has been established, then the objectives in Figure 1 might evolve to look like those in Figure 3.

Commit to PI Objectives

A vote of confidence is held near the end of PI planning, where the teams commit to the PI objectives. (Uncommitted objectives are not included in this commitment.) However, it must be a reasonable ask for the people who do the work. Therefore, the SAFe commitment has two parts:

• Teams agree to do everything reasonably in their power to meet the committed objectives
• During the course of the PI, if it’s discovered that some objectives are not achievable, then the teams agree to escalate immediately so that stakeholders are informed and corrective action can be taken

In this way, all stakeholders know that either the program results will be achieved as planned, or they will be provided sufficient notice so as to be able to mitigate and take corrective action, minimizing business disruption. That’s about as good as it gets, because this is, after all, research and development.

Creating Program and Solution PI Objectives

The output of the PI planning process will be a collection of approved team PI objectives sheets; one per team. Teams vote on the confidence level for the objectives as a set, and if confidence is high enough, the aggregate set of objectives becomes the committed ART plan. The Release Train Engineer  summarizes the team objectives into the program PI objectives in a format suitable for management communication.

The summarized objectives should be SMART, much like the team PI objectives, and have uncommitted objectives. Also, like the team PI objectives, the program PI objectives might describe business features the ART is working on, enablers, or other business or technical goals.

If the ART is part of a Solution Train then during the Post-PI Planning event, after all the ARTs have planned, objectives are further rolled up by the Solution Train Engineer , and the solution PI objectives are synthesized and summarized. This is the top level of PI objectives in SAFe, and they communicate to stakeholders what the Solution Train will deliver in the upcoming PI. Figure 4 below illustrates this summary from team to program and from program to solution PI objectives.

It’s important that business value is only assigned to team PI objectives. The predictability metric itself is rolled up to determine predictability at a higher level.

Reduce WIP with Realistic PI Objectives

During the review of the team PI objectives, not everything that was envisioned by the various business stakeholders will likely be achieved in the PI timebox. Therefore, some of the planned work will need to be reevaluated with Business Owners to gain agreement to the PI objectives.

Those lower-priority work items get moved back into the Program Backlog . Decreasing excess WIP reduces overhead and thrashing, and it increases productivity and velocity. The net result is a feasible set of PI objectives that are agreed to by all business stakeholders and team members, as well as increased efficiency and a higher probability of delivery success.

Planning at the large solution level can be very similar; the planning of the ARTs will impact each other, pushing some work back into the Solution Backlog for re-evaluation in a later PI.

Last update: 04 October 2022

Privacy Overview

Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.

Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.

Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.

Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.

Other uncategorized cookies are those that are being analyzed and have not been classified into a category as yet.

Lean Events and Training / Events / Managing Strategy

Managing Strategy

Connecting Strategy, Operations, and Problem Solving Across Your Organization.

Available Dates

June 4, 2024 - June 25, 2024: 10:00am - 12:00pm ET

Coach-Led Online Course

Why you should attend

Join us for four sessions and enhance your understanding of how integrating A3 and daily management practices with the hoshin kanri strategic planning method helps ensure your organization achieves its strategic objectives. 

$999 Early bird price* $1,299 Regular price * Early bird expires April 20, 2024.

Discover and begin implementing a systematic approach to improve your organization’s ability to achieve its strategic objectives by integrating three powerful lean practices — hoshin kanri with A3 and daily management practices .  

Research shows that leaders struggle more with executing strategy than with developing it. In this workshop, you will discover how to link your hoshin (strategic plan) to the A3 management and problem-solving process and daily management practices to ensure everyone stays focused on executing their part of the organization’s plan. When effectively used, A3 and daily management practices help overcome strategy execution problems while developing the capabilities of everyone involved, from the executive suite to the front line.  

You’ll learn how to link hoshin objectives to three types of A3s — strategy, proposal, and problem-solving — to ensure plans get executed. And you’ll discover how to link the A3s with a daily management system that ensures daily frontline problem-solving stays focused on consistently hitting daily performance goals (KPIs) that contribute to achieving the organizational objectives.   

By the end of the course, you’ll understand how to implement this framework and process for executing strategy by aligning and engaging teams at all levels of the organization — including those operating remotely — to improve strategy execution and set the stage for achieving long-term competitiveness.  

Learning Objectives

• Understand the relationship between hoshin kanri and A3 and daily management practices, including the components necessary to ensure the success of long- and short-term planning.
• Understand the roles and when to use each of the three types of A3 processes.
• Use daily management processes to engage people at all levels in work improvements that help the organization achieve its hoshin objectives.
• Set strategic metrics for your hoshin (strategy) and link them to key process indicators (KPIs) to guide daily management, ensuring that the goals encourage daily problem-solving that helps execute the strategy.
• Establish PDCA improvement cycles and good problem-solving practices that enhance your teams’ ability to remove obstacles that keep them from achieving their KPIs.

Who Should Attend

• Organizational leaders and lean practitioners in any industry  
• Leaders, executives, and managers in any industry involved with strategy development who want to overcome obstacles that keep their organization from achieving their strategic objectives.  
• Leaders and managers across the enterprise, such as operations, supply chain, purchasing, logistics, delivery, service, marketing, and sales professionals    
• Continuous improvement professionals helping organizations adopt lean thinking and practices

Prerequisites

Although this class requires no prerequisites, it would be helpful for you to be familiar with the fundamentals of hoshin kanri , A3, and daily management.  

Learn more or get a head start learning about hoshin kanri . This ebook shares Logoplaste’s experience in adopting the approach to improve their strategic planning and execution .  

Group Discount

Register three or more attendees for the same workshop and save 12.5% off every registration. To receive a group discount, register as a group through the registration link and the discount will automatically apply.

Cancellation Policy

You can cancel your registration for online/live-streaming workshops two weeks before the course’s start date for a full refund. A cancellation occurring within two weeks of the workshop dates will be subject to a $350 fee. If you need to cancel, you can do so through your confirmation email from ‘The LEI Events Team’ or email [email protected] .    

Schedule Overview

The 4 sessions are hosted over 4 weeks.

April 4 – May 2, 2024 Course All sessions hosted 10:00 PM – 12:00 PM ET and instructed by  Josh Howell

• Thursday, April 4
• Thursday, April 11
• SKIP WEEK OF APRIL 19
• Thursday, April 25
• Thursday, May 2

June 4 – June 25, 2024 Course All sessions hosted Tuesdays, 10:00 AM – 12:00 PM ET and instructed by Josh Howell

• Tuesday, June 4
• Tuesday, June 11
• Tuesday, June 18
• Tuesday, June 25
• Introduce Hoshin Kanri    
• Introduce the three types of A3    
• Draft a strategic A3 based on your own business problem   
• Introduce Daily Management   
• Draft a structure of Daily Management that includes PDCA structure, Leader Behaviors   
• Pilot this methodology in the class   

Josh Howell

President and Executive Team Leader Lean Enterprise Institute

Joshua Howell is president and executive team leader at the Lean Enterprise Institute (LEI). For over a decade, he has supported individuals and organizations with lean transformations for improved business performance. As a coach, he helps people become lean thinkers and practitioners through experiential learning, believing such an approach can lead to enterprise-wide improvement. Regular e-letters […]

Senior Coach and Chief Engineer, Strategy Lean Enterprise Institute

During his extensive career, Mark has led lean transformations and coached executives in various companies and business sectors. Clients include GE Appliances and Ingersoll Rand (manufacturers); Michigan Medicine and Mt. Sinai (healthcare systems); Turner Construction; Kroger (retail); Legal Seafood (hospitality); and Microsoft (software).   As LEI’s chief engineer, strategy, Mark leads the development of new learning […]

Bring Our Practical, How-to Training to Your Company

Custom Training

Related events.

April 16, 2024 | Coach-Led Online Course

Improvement Kata/Coaching Kata

May 03, 2024 | Coach-Led Online Course

Hoshin Kanri

May 13, 2024 | Coach-Led Online Course

Key Concepts of Lean Management

Subscribe to get the very best of lean thinking delivered right to your inbox, privacy overview.