Product Owners and Dependencies

When you scale Agile, or have more than one Scrum Team working together to deliver value, dependencies can become a major problem.

A dependency exists when a Scrum Team needs work from another team before they can complete their own work. For example, a development team may be waiting on the SQL team to make a database change. Or Human Resources may need software changes before updating the onboarding process.

In short, dependencies are those times when one team is waiting on another.

And waiting slows value delivery.

According to the annual State of Agile Report, 35% of people are dissatisfied with their company’s agile practices due to siloed teams — which create dependencies. Another 14% cite dependencies directly. Combined, that means 49% of people are negatively impacted by silos and the dependencies they create.

That’s not a minor issue.

Long-Term Fix: Product Definition

Sometimes dependencies are ongoing. The same teams repeatedly wait on each other Sprint after Sprint. When that happens, it’s usually structural. Products may be too narrowly defined. Teams may be organized around components instead of value. If a significant portion of your backlog depends on another team, it may be time to rethink your product definition and build more cross-functional teams.

But organizational change takes time.

Short-Term Fix: The Product Owner

Sometimes dependencies are temporary. A feature may require collaboration between teams that don’t normally work together. That’s situational.

So what can we do in the short term?

First, Developers must surface dependencies early — during refinement or Sprint Planning, not when work is already blocked. Transparency comes first.

Once dependencies are visible, the Product Owner can plan for them through the content and ordering of the Product Backlog.

In practice, that means the Product Owner can:

• Work with Developers to reorder work on the Product Backlog to sequence dependencies logically

• Prioritize enabling work before downstream functionality

• Coordinate roadmaps with other Product Owners, if dependencies cross Products

• Work with Developers to discuss whether teams collaborate in the same Sprint or stagger work intentionally

• Adjust the roadmap to reduce wait time and protect flow

The Product Backlog is more than just a "to do" list. It's a plan.

Good plans account for dependencies — sequencing work to minimize impact and reduce delays.

Sometimes that means prioritizing enabling work first. Sometimes it means avoiding tightly coupled work in the same Sprint. Sometimes it means pacing work so one team completes enabling functionality before another begins.

That’s simply good strategy to maximize value delivery.

When dependencies cross into another product, Product Owners should coordinate their roadmaps. If Product A depends on Product B, those Product Owners need alignment. They may collaborate in the same Sprint. Or they may plan so Product B finishes necessary work one or two Sprints ahead.

Dependencies don’t disappear, but Product Owners can plan for them.

Over time, we should reduce dependencies by redefining products and designing teams around value. But in the short term, strong Product Ownership helps manage dependencies before work becomes blocked.

For more on the Product Owner accountability in Scrum, sign-up for Rebel Scrum's Professional Scrum Product Owner class. It's a fun experience where Product Owners practice creating a vision, Product Goal, and Product Backlog for an in-class product.