What If the Goal of PI Planning Isn't Managing Dependencies Better?

[#1]

Every PI Planning event seems to have a moment like this.

The ART Planning Board starts filling up. Teams are discussing features, negotiating delivery dates, and identifying cross-team dependencies.

Then someone inevitably says something like:

"Wow...we have a lot more dependencies than we expected."

Most of us treat that moment as a success.

After all, identifying dependencies early is one of the primary goals of PI Planning. Discovering them before implementation begins is certainly better than discovering them halfway through a Planning Interval.

But recently I've been wondering if we're celebrating the wrong thing.

Visibility Is Only the Beginning

One of the greatest strengths of PI Planning is the visibility it creates.

Whether your ART Planning Board lives on a wall covered in sticky notes or inside Jira, it provides a shared view of how work flows across Agile Teams.

That's incredibly valuable.

Without that visibility, teams often discover coordination challenges too late, leading to blocked work, shifting priorities, and unnecessary surprises.

Visibility matters. Learning from that visibility is where continuous improvement begins.

The Question I Don't Hear Very Often

During PI Planning, we spend a lot of time asking questions like:

• Who owns this dependency?
• Which team needs to deliver first?
• What happens if this slips?

Those are important conversations. But there's another question I don't hear nearly as often.

Why does this dependency still exist?

If the same dependency appears every Planning Interval...

If the same team consistently becomes a bottleneck...

If every major initiative depends on the same shared service...

Perhaps the dependency isn't the problem; perhaps it's telling us something about the system.

Dependencies Are Feedback

I don't think dependencies are inherently bad.

Healthy collaboration naturally creates them, but recurring dependencies are different. They provide feedback about how work moves through the organization.

Over time, they can highlight:

• technical debt
• architectural constraints
• unclear ownership
• governance bottlenecks
• opportunities to reorganize around value streams

Instead of viewing recurring dependencies as something to coordinate every quarter, perhaps we should also view them as opportunities for continuous improvement.

A Different Measure of Success

Maybe a successful PI Planning event isn't the one that identifies the most dependencies.

Maybe it's the one that helps us identify which dependencies shouldn't exist by the next Planning Interval. That's a very different way of measuring success.

Instead of simply coordinating work more effectively, we begin improving the system that creates those dependencies in the first place.

I'd Love to Hear How Others Approach This

For those facilitating PI Planning or working with Agile Release Trains:

• Do you actively review recurring dependencies across Planning Intervals?
• Have you found effective ways to eliminate them over time?
• Have dependency patterns ever led you to reorganize teams, improve architecture, or rethink ownership?

I'd be interested to hear what's worked for your organization. Because I have a feeling dependency management isn't just about coordination; it's about organizational learning.