The Product Manager’s Role in PI Planning

This is a guide to understand the Product Manager’s role in PI Planning. As such, the article will describe what a Product Manager must do during PI planning. Read our earlier article about PI planning preparation to understand how to get ready for the event PI Planning is often described as the heartbeat of the Agile Release Train.  This event is more than a mere planning event. This is the event where the strategy gets validated against the practicalities of delivering realities.

 Product Managers Role in PI planning : The Value Gurdian

Product Managers act as a keeper of Value for the Agile Release Train- (ART). During the PI planning, a PM helps stakeholders and the teams to align, and decide what matters most, and how we will deliver it. This article will not go in depth about the PI Planning structure. This article in scaled agile website describes PI planning structure well. Here, I will talk about how a PM shows up—before and during the event—to make it actually work. Before PI Planning: What a PM must align before Day 1 Most of your impact as a PM happens before PI Planning starts. If you walk into Day 1 hoping alignment will happen in the room, you’re already late. Here I will share a few things you need to get in place early. First, stakeholder alignment. Business, Architecture, and Engineering should not be debating fundamental priorities during PI Planning. You don’t need perfect agreement—but you need enough clarity to move forward towards the intended objective Second, priority clarity. Your “Top 10” features shouldn’t be a vague wishlist. They should reflect real decisions—what makes it in, what doesn’t, and why. When you decide priorities, it is tempting to focus all your energies on the low-hanging fruit. Do not fall for the trap. Make sure to balance new features with Architecture runway. Third, dependencies. If there are known cross-team dependencies, start conversations early. Don’t wait for teams to discover them during breakouts. And finally, trade-offs. Go in with a point of view. If capacity doesn’t allow everything—and it won’t—what gives? Preparation is less about documents and more about decisions.

The Product Managers Core Role  During PI Planning

Once PI Planning starts, your role becomes very visible. At a high level, you need to

• Set the direction through the vision
• Balance priorities against capacity
• Negotiate scope when capacity, skill or dependency issues arise
• Work with stakeholders to get the Business Value (BV) numbers established
• Participating in risk management (ROAM)

What you’re NOT  responsible for is micromanaging team plans. A common mistake is trying to be everywhere and solve everything. That usually creates more noise than clarity. Your role is to anchor the conversation around value—and step in only when alignment is at risk.

Presenting the Vision: What You Must Bring to the Table

The vision presentation at the start of PI planning sets the tone for everything that follows. And it’s easy to get this wrong. Reading through slides won’t cut it. Teams need to understand:

• What are we trying to achieve this PI?
• Why does it matter?
• What are the few things we really care about?

The “Top 10 Features” matter—but not as a list. As a clear signal of priority. If everything sounds equally important, teams will struggle to make decisions later. Also, give guardrails:

• What does success look like?
• Are there constraints teams should be aware of?

  A good vision presentation helps the team with clarity about what they should focus on.

Supporting Teams During Breakouts

Breakouts are where the real planning happens. I have seen that, during the breakouts, many PMs either overstep or disappear completely. Both do not help. The balance is important. You’re there to:

• Explain focus and priority when teams are not clear
• Help negotiate scope as an when needed – This can be because
• Facilitate alignment across Product Owners

  You’re not there to dictate how teams should plan their work.

Participate in Draft Plan Reviews

Draft plan reviews are where the ART leadership (PM /RTE and system architect) first sit down with the teams to discuss the plan. This is not just a status update—it’s your chance to catch issues early. Look at:

• Team-level PI Objectives: Are the team-level PI objectives outcome-focused, or have the team just listed down the sequence of stories?
• Commitment levels: What’s committed vs uncommitted—and why? Have the teams created their commitment only on capacity basis or have they considered uncertainties like skill issues/technical feasibility and dependencies
• Capacity alignment: Are teams overloading themselves? Have they considered day to day overheads

Also, pay attention to dependencies. The ART planning board is your friend here. It helps you see where things might break before they actually do. It is often helpful to start the rough ART planning board in this segment. Don’t just listen to what teams present—look for what’s missing.

 Management Review & Problem Solving: Where PMs Shine

This is usually the most intense part of PI Planning. Plans don’t fit. They don’t look like what we had hoped for. Capacity is exceeded. Dependencies create friction. This is where a skilled and prepared PM makes a difference A good Product manager should come prepared with:

• Trade-off options, not just problems – Talk about what changes and trade offs can help us go closer to our earlier ambitions – be ready with a view on what can move out if something else must come in
• Ideas on how uncommitted work could become committed – what help you need?
• Stay firm on what can not really be done – do not set unrealistic expectations. It is critical to balance Business Urgency with team capacity and technical feasibility
• Champion the Architecture runway – do not lose focus on maintaining a balance with immediate feature value and being ready for what comes next

Assigning Business Value (BV): More Than a Number

Assigning Business Value often becomes a mechanical exercise. It shouldn’t be. This is where you help stakeholders understand what really matters. Once stakeholders really “see” what your teams will be doing – alignment is easy to follow A few things to keep in mind:

• Not everything can be “high value” – encourage stakeholders to show what matters most to them
• Explain Architectural runway  –  help the stakeholders truly sppericiate the impact they will have if teams ignore the runway completely in favor of only immediate value
• Explain Uncommitted objectives are not low priority and team will not be ignoring those—The uncommitted status reflects uncertainty

Use this moment to create shared understanding, not just assign numbers.

Common Pitfalls in PI planning

Some patterns show up very often. Good PMs take care to avoid these. Overcommitment is the big one. Planning at 100% capacity seems efficient—but it rarely works in reality. Plan adequate but transparent buffers to allow for unexpected Another anti-pattern of is to actually plan feature delivery work in the IP iteration – This will quickly kill both innovation and your planning for the next PI Then there’s the silent PM. Being unavailable or disengaged during PI Planning creates confusion quickly. Another one is ignoring architectural runway. It’s easy to deprioritize it in favor of visible features—but the cost shows up later. And finally, over-controlling. Trying to drive every decision slows teams down and reduces ownership. The goal is not control—it’s clarity.

How to be an effective PM during PI planning

Being effective during PI Planning isn’t just about what you know—it’s about how you interact during PI planning First, presence. You don’t need to be everywhere—but you do need to be accessible. Especially in high-risk discussions. Second, knowing when to step in. — Step in when teams are not clear about priorities. If they’re debating execution details—step back Third, reading the room. — Confusion, hesitation, repeated questions—these are signals that something isn’t clear. Fourth bring clarity to management and stakeholders – help them understand trade-offs —Discuss what can and can not be done — explain the need for innovation and architecture  runway Finally comes decision-making. — you will be asked to make a lot of decisions. You won’t have complete information. That’s normal. Some factors to consider are Value , risk , capacity and technical feasibility. Also consider face trade-offs: Short-term delivery vs long-term architecture or Business pressure vs technical reality Sometimes you push. Sometimes you adapt.

Conclusion: Bring enough clarity start execution

At the end of PI Planning, you’ll have a plan. But more importantly, you’ll have a level of alignment. The confidence vote is not about perfection. It’s about whether teams believe in what they’ve planned. Your role doesn’t end here. The plan needs to translate into a living backlog. Priorities need to hold—or be consciously adjusted. PI Planning is not about getting everything right upfront. It’s about creating enough clarity and alignment so that when things change—and they will—teams know how to respond. That’s what good product leadership looks like.  

The post The Product Manager’s Role in PI Planning appeared first on World Of Agile.

Real-Life Scenarios when multiple Teams are working on the Same Product

In this section, we will look at some real-life scenarios that Scrum Team(s) often face when multiple Teams are working on the Same Product . This article is part of an ongoing series on real-life scenarios that many Scrum Teams face. Adding more teams to a product should increase speed. That’s the expectation. However, in many organisations, the opposite happens. Despite having multiple Scrum Teams working in parallel, delivery slows down, dependencies increase, and alignment becomes harder. Teams stay busy, but product progress feels inconsistent. The problem is not the number of teams—it is the complexity that comes with them. Working with multiple teams on the same product requires a different level of discipline, collaboration, and clarity. Without it, scaling Agile can quickly turn into scaling confusion. Based on my experience working with multi-team environments across Scrum, SAFe, and Kanban setups, here are some real-life scenarios that frequently emerge.

1. “We are done” (But Others cannot use it!!)

Team A completes their work and marks their stories as “Done.” However, when Team B tries to use the same functionality, they run into issues—missing APIs, incomplete validations, and inconsistent behaviour. From Team A’s perspective, the work is complete. From Team B’s perspective, it is not usable.

Snehamayee’s perspective

What’s happening here? Each team delivers their work with their own interpretation of what “Done” means. There is a clear lack of a shared understanding at the product level. Impact: Work appears complete on dashboards, but real progress is not seen. Instead, the teams struggle with rework, delays, and frustration What we can do?

• A shared Definition of Done across teams is critical. It should include integration, usability by other teams, and alignment with product-level quality standards. “Done” should mean usable—not just complete within a team boundary.
• Integrated Solution level or Product level reviews – SAFe (Scaled Agile Framework ) recommends regular System demos. These are integrated demos – These will enable teams to “see” how their work is being used by other teams. These demos also help the teams as they encourage collaboration

2. Dependency Chaos Between Teams

A very common situation in multi-team setups is when one team’s progress depends heavily on another. You often hear statements like: “We can’t start until Team B finishes their part.” Or “We’re blocked waiting for the API from Team C.” Snehamayee’s perspective What’s happening here? Some possible reasons are

• Component Teams -Teams are often structured around components rather than features. This leads to tight coupling between teams.
• Inefficient work slicing – In addition, the work slicing (splitting work across teams) often creates additional dependencies across team boundaries

Impact: Planning becomes uncertain, commitments become unreliable, and teams lose their ability to deliver independently. Instead of enabling speed, multiple teams create bottlenecks. What we can do?  

• Reducing dependencies should be a continuous focus. This may involve rethinking backlog slicing, re-assignment of work, or even restructuring teams toward more feature-oriented ownership.
• Dependency Board – Visually tracking the multi-team dependencies will help the teams identify critical path to monitor, bottlenecks to be aware about and trigger remedial actions in advance to reduce dependencies. Another SAFe technique the ART planning board will help.
• Design Feature Teams –Teams that are designed to deliver end to end value rather than a specific component help with easier coupling

3. Conflicting Priorities Across Teams

In another setup, each team appears busy and productive. However, when viewed from a product perspective, progress is slow and scattered. Different teams work on different priorities—some on new features, others on technical improvements, and some addressing stakeholder requests.

Snehamayee’s perspective

What’s happening here?

There is no clear alignment at the product level. Teams optimize for their own backlog rather than a shared product goal.

Impact: High activity does not translate into meaningful outcomes. Work gets fragmented, and the product evolves in an inconsistent manner. What we can do?

• Clear product-level prioritization is essential. Whether through a single Product Owner, a Chief Product Owner, or a well-aligned Product Management function, teams need a shared understanding of what matters most.
• A cross-domain planning session – A common planning session across teams will help the teams to align their priorities and expectations.

4. Integration Becomes a Nightmare

Integration of work is one of the most common challenges for the multi-team product. Each team develops and tests its work independently. Everything works fine within team boundaries. However, when all components come together, issues start to surface—unexpected defects, incompatible interfaces, and performance problems.

Snehamayee’s perspective

What’s happening here?

Integration happens too late. Teams work in silos with limited visibility into how their work interacts with others.

Impact: Integration risks accumulate over time. On top,  these integration risks will often surface at the worst possible moment—close to release timelines.

What we can do?

• Frequent integration is key. Practices such as continuous integration, shared environments, and automated testing help reduce surprises. Integration should not be treated as a separate phase—it should be part of everyday development.
• A common Sprint Duration – A common Sprint Duration will provide a cadence needed for frequent integration
• Regular Integrated demos Or System demos as defined by SAFe will help. These demos help to enforce regular integration

5. Ownership Confusion – “Who Owns This?”

In multi-team environments, features often span across teams. This creates situations where responsibility is unclear. When an issue arises, the response is often: “This part belongs to Team A.” or “That integration is handled by Team B.” or “This is not our responsibility”

Snehamayee’s perspective

What’s happening here?

Ownership is divided along component or functional lines, rather than end-to-end product outcomes.

Impact: Slow decision-making, blurred accountability and issues that take longer to resolve. In some cases, important items fall through the cracks because no team feels responsible.

What can we do? Clear ownership of outcomes is critical. Even if multiple teams contribute, there should be clarity on who is accountable for delivering the feature end-to-end. Shifting toward feature ownership rather than component ownership can help address this challenge.

Final Thoughts on Real-Life Scenarios Faced by Scrum Teams When Multiple Teams Work on the Same Product

Working with multiple teams on the same product is not just about adding capacity(or people). It is about managing complexity. Many of the challenges discussed above are not caused by a lack of skill or effort. They arise from gaps in alignment, communication, and shared understanding. Some common issues I have seen across many customers are:

• Lack of shared standards – for example, a common integrated Definition of Done or common  quality standards
• High dependencies between teams means a tight coupling and more limitations
• Misaligned priorities lead to effort wastage and rework
• Limited focus on integration and ownership

  It takes conscious effort to address these challenges. Some tips that help are

• Better Alignment among teams by planned multi team events like structured cross-domain planning
• Establishing collaboration forums like dependency boards
• Designing feature teams that deliver end to end value and move away from component teams

Organisations that recognise and actively address these patterns are more likely to realise the true benefits of scaling Agile. Those that do not often find themselves adding more teams—but not necessarily delivering more value.    

The post Real-Life Scenarios Faced when multiple Teams are working on the Same Product appeared first on World Of Agile.