Scrum Scaling Blindspot: Delegating work isn’t the same as delegating thinking

A team I worked with looked “scaled” on paper:

• Multiple Scrum Teams
• One Product Owner
• Backlog work distributed

Teams were writing PBIs. Refinement was happening everywhere.

Still — the system started breaking in quieter ways.

The Product Owner became a bottleneck — busy, unavailable. Decisions came late — or worse, changed mid-Sprint. Dependencies surfaced too late. The wrong things got built first.

Work was moving. Value wasn’t.

Here’s what was actually going on.

The Scrum Guide allows Product Backlog work to be delegated:

• Product Goal
• PBIs
• Ordering
• Transparency

Most teams take that as a scaling strategy.

Delegate the work → remove the bottleneck.

But those activities only deliver value in a complex environment when done empirically:

• Goals evolve with evidence
• PBIs reflect learning
• Ordering responds to feedback

That capability belongs to the Product Owner.

The 2020 Scrum Guide is explicit:

The Scrum Master helps the Product Owner establish empirical product planning for a complex environment.

Here’s the blind spot most scaling efforts never see:

Delegating the four tasks without distributing the empirical thinking those tasks depend on doesn’t scale the Product Owner.

It just moves the queue.

So what actually gets distributed?

Tasks.

What stays centralized?

Judgment.

• Teams write PBIs — but hesitate to reshape them
• Teams suggest priorities — but wait for validation
• Teams deliver increments — but rarely pivot based on what they learn

Every empirical decision still routes back to one person.

Not because the PO is holding on. Because the capability never moved.

In that same team, one shift made the difference.

Instead of asking “Are these PBIs clear?”

the Scrum Master started asking:

“What did we learn last Sprint that should change what we build next?”

At first — silence. Then hesitation. Then disagreement about what to build next.

• PBIs started changing mid-refinement
• Ordering became a discussion, not a decision
• Teams began proposing what not to build

The Product Owner didn’t lose control. The bottleneck disappeared.

Bottom line

You can delegate Product Backlog work. If you don’t distribute empirical product thinking, it all flows back to one person.

The question isn’t who owns the backlog. It’s who owns the learning.

Originally published at https://www.linkedin.com.