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.

[Bevan Williams]

This is a great reflection for anyone reading whose company has fallen into the rut of PI planning. Spot on assessment of the dependencies and being able to track recurring ones.

We're currently running two parallel solutions like a really slow A/B test.

1. Jira Align, Confluence, and Analytics:
   • Custom analytics dashboard and charts built on top of the excellent JA dependency management system.
   • With the dependency tiering in JA, teams can essentially escalate a recurring dependency by tier, i.e. This dependency is Program or Portfolio tier, not directly associated with a Feature.
2. Jira custom work item, Confluence, and Analytics
   • We recently federated businesses so some business units prefer managing their own instance under our enterprise account so don't activate Jira Align.
   • We create a custom Dependency work item with its own workflow, fields, etc (modelled on Jira Aligns)
   • Then using custom analytics dashboards to get some of the visualisations native in JA like the dependency matrix.
   • Similar to above ways of work agreement to use "tier" custom field as an indicator with some Rovo tests running to help identify past solutions/related items.

This data is crucial for continuous improvement, so we recommend (as part of our pattern book) that the broader ART team (POs, RTE, Solution Leads) include this consideration in their regular retros as well as the end of PI inspect & adapt event.

The biggest challenge we've been addressing is around the "business" not prioritizing the resolution of "technical dependencies". Business and IT here are still seen as different (literally funded differently), so bridging that gap through collaborative ideation and non-structural, fluid teaming has been critical. We've had to run some serious upskilling on technical debt, benefit definition & realisation, flow, etc with the most successful conversations landing on flow metrics related to cash.

[Joshua Brock _ Seibert Group_ GmbH]

 
@Bevan Williams 

Thanks for such a thoughtful response! I really appreciate you taking the time to share how your organization is approaching this.

One point that really stood out to me was your observation that recurring dependencies are becoming part of regular retrospectives and the Inspect & Adapt event. That's exactly the kind of shift I was hoping to encourage. Rather than treating dependencies as something to coordinate during a single PI, they become valuable signals for continuous improvement.

I also found your comments about business prioritization of technical dependencies really interesting. I suspect many organizations face that very same challenge. Framing those conversations around flow and business outcomes rather than "technical work" feels like an effective way to bridge that gap.

Thanks again for adding your perspective, I really appreciate it! Continued success!


Joshua