Backlog Coupling

Backlog coupling occurs when completing one team’s work requires another team to schedule corresponding work in its own queue. Evan Bottcher uses the term to explain how delivery can wait on independently prioritized backlogs. It names a coordination dependency; it is not itself a unit of time or a claim that every dependency is harmful.

How the dependency creates delay

Consider a product change that needs a firewall rule from another team. The implementation may be brief, but the request waits behind that team’s other commitments. More engineers on the product team may not shorten this particular wait. The useful question is which part of elapsed time comes from work, scheduling, unavailable information or rework.

Bottcher reports a study of hundreds of work items at one Australian telecommunications company. Items requiring another team’s scheduled work took 10–12 times as long in elapsed time as independent items. This illustrates a potentially large difference. It is not a universal multiplier or a controlled estimate of the delay caused solely by the dependency: the groups can differ in size, risk and urgency.

Bottcher discusses constraints involving core transactional systems, data and analytics, and shared infrastructure. Each can involve technical design, access decisions and scheduling. Inspect the actual request path before selecting an architectural or organizational remedy.

Reduce repeated handoffs and manage those that remain

Shared planning, aligned priorities, reserved capacity or more frequent handoffs can reduce waiting. They may be the appropriate response to an infrequent dependency or a required specialist decision. They also consume coordination effort, so examine whether a recurring request can become a supported service instead.

Team Topologies distinguishes close collaboration, service consumption and facilitation. Stream alignment aims to reduce blocking handoffs while preserving outcome ownership. It does not remove every service dependency, review or need to develop a new capability together. A routine service relationship can need little coordination even though its creation required substantial collaboration.

• Automate a supported request. self service provisioning can remove repeated manual fulfillment. Capacity limits, approvals outside the preauthorized envelope and failures still need a route.
• Remove or relocate a dependency. Giving a team its own capability can shorten a queue while adding maintenance and duplication. If data is replicated, define synchronization and consistency requirements rather than assuming all consistency must be abandoned.
• Adjust team boundaries. Persistent entanglement can reveal a poor split, but compare reorganization with clearer service contracts and scheduling changes.
• Decouple consumption through a contract. A versioned interface or scheduled extract can let consumers run and deploy independently. Creating or changing that contract may still need work in both backlogs; asynchronous data delivery does not automatically separate organizational planning.

Account for the work that moves

Moving infrastructure choices to each product team can reduce central waiting while increasing implementation and maintenance work. The CNCF platforms white paper describes shared capabilities as a way to absorb some of that burden. Measure cognitive load and user effort alongside provider effort; a faster request path may simply move work to the requester.

The choice is a mixture of autonomy, shared services and coordinated decisions. A platform can make common decisions reusable without eliminating every queue. Preserve explicit support for requirements outside the automated path.

Measure where time is spent

Use the process boundaries emphasized by DORA’s value stream mapping guidance. For a defined request type, record request, queue entry, work start and completion, with a stated clock and observation period. Separate hands-on work, waiting and rework where the evidence allows.

Compare similar task types, sizes and urgency before attributing differences to cross-team dependence. Include the age of unfinished work so a sample of completed items does not hide long-running blockages. An observed gap is a reason to investigate, not automatically time recoverable through self-service.

After changing the path, remeasure comparable work and review service quality and failure rates as well as elapsed time. Golden Paths and the Platform Contract explains how support, changes and alternatives become part of the shared agreement.

References

• Evan Bottcher — What I Talk About When I Talk About Platforms
• Team Topologies — Key Concepts
• CNCF Platforms White Paper
• DORA — Value stream mapping