The Silent Killer of Enterprise Velocity
You can optimize individual Scrum teams all day, but if an upstream blocker takes three weeks to resolve, your time-to-market is already dead in the water. Cross-team dependencies are the silent killers of enterprise velocity.
When stepping into a multi-team ecosystem, optimizing isolated squads yields diminishing returns. I see organizations spend thousands of dollars training teams on better story pointing or refinement practices, completely ignoring the fact that those teams spend 40% of their sprints waiting on database administrators, security approvals, or core API updates. Real delivery speed is found in the white space between teams.
If you want to unblock your Agile release trains, one of the most critical flow metrics you need to establish in your first 90 days is Dependency Resolution Time (DRT). Here is a battle-tested roadmap to baseline this metric and start repairing your delivery ecosystem.
What is Dependency Resolution Time (DRT)?
Dependency Resolution Time (DRT) is the exact elapsed time measured from when a team identifies and requests an external dependency to the moment that dependency is delivered and verified. Tracking DRT highlights exactly how long your engineering teams sit idle waiting on outside help. If you want predictability, you must stop looking exclusively at internal team velocity and start looking at systemic wait time.
Most organizations track lead time or cycle time for user stories. But cycle time only tells you how long a team takes to do the work they control. It rarely exposes the exact hours or days wasted waiting on a shared service.
DRT changes the conversation. It shifts leadership focus away from micro-managing developer output and directs it toward macro-level organizational bottlenecks. Establishing DRT gives you a quantifiable metric to prove exactly where the enterprise is choking.
Month 1: Standardize and Make Dependencies Visible
To standardize and make dependencies visible, you must configure your work management tools to explicitly flag and link external blockers. If a dependency is invisible in your backlog, it functionally does not exist for leadership. You cannot fix what you cannot see.
Define the Boundaries of a Blocker
Before you touch Jira, Azure DevOps, or Rally, you need a shared definition of a dependency. Get your Scrum Masters, Product Owners, and Engineering Managers in a room and agree on the triggers.
When does the clock start? DRT should begin the moment a formal request is made to an external team. Not when the team starts talking about it at the water cooler, but when the dependency is officially identified and requested.
When does the clock stop? It stops when the dependency is delivered, integrated, and verified by the requesting team. Dropping an API endpoint into a staging environment does not stop the clock if the endpoint is missing required payloads. Delivery requires verification.
Instrument Your Agile Tooling
Next, you must instrument your tooling to support this workflow. Establish a strict tracking rule. Add a mandatory Blocked By: External Team link type in your software.
Create a visual flag—a red label, a custom field, or a specific dependency ticket type. When a team gets stuck, they create the dependency link. This allows you to build simple dashboards using JQL or Azure queries to show exactly how many active stories are blocked by external dependencies right now. Make it a binary state. The story is either blocked by an external team, or it is not.
Month 2: Measure Flow and Failure Demand
Measuring flow involves tracking the exact lead time of your identified dependencies and categorizing them by domain to find the actual bottlenecks. You cannot clear systemic delays until you know which specific services, teams, or processes generate the most failure demand.
Track the 85th Percentile Lead Time
Once you have a month of data, pull the metrics. Do not look at average wait times. Averages lie.
If a team has four dependencies, and three of them are resolved in a single day, but the fourth takes 20 days because it involves a legacy architecture review, your average resolution time is roughly 5.7 days. Telling a Product Owner to expect a six-day wait is dishonest. The reality is that one out of every four dependencies will stall your sprint for three weeks.
Track the 85th percentile of your DRT. This tells you that 85% of your dependencies are resolved in X days or less. This gives you a realistic, data-backed tail-end risk to share with stakeholders. If your 85th percentile is 18 days, you now know that any dependency identified mid-sprint will almost certainly cause a sprint failure. Plan accordingly.
Categorize the Blockers
Not all dependencies are created equal. You need to group them by type to understand the nature of your bottlenecks. Common categories include:
- Shared Services: Waiting on DevOps pipelines, security scans, or database provisioning.
- Architecture/Governance: Waiting on architectural review boards or compliance sign-offs.
- API/Integration: Waiting on another product team to expose an endpoint or modify a payload.
- Data Access: Waiting on data engineering to move or grant access to required tables.
By categorizing the failure demand, you stop pointing fingers at “slow teams” and start identifying broken systems. If 60% of your wait time is tied to API integrations, you do not have a Scrum problem. You have an architecture and decoupling problem.
Month 3: Establish Baselines and Operating Agreements
Establishing baselines and operating agreements involves openly publishing your wait-time metrics and co-creating internal service level agreements between teams. This ensures every squad understands exactly how to intake, prioritize, and resolve cross-team work.
Publish the Baseline to Create Urgency
Take your 85th percentile DRT and broadcast it. Put it in front of the VP of Engineering. Bring it up in the Scrum of Scrums. State it plainly: “Our 85th percentile Dependency Resolution Time is currently 14 days.”
Transparency creates urgency. When leadership realizes that two weeks of every feature’s lead time is spent sitting in a queue waiting for a database script to be approved, the conversation shifts from “Why are developers so slow?” to “How do we automate database provisioning?” Data removes emotion from the debate.
Co-Create Working Agreements (OLAs)
You cannot demand faster turnarounds without giving teams a mechanism to handle the work. Facilitate cross-team syncs to establish Operating Level Agreements (OLAs). These are simple, working contracts between teams that rely on each other.
A strong OLA includes three core components:
- Clear Intake Criteria: How do we request work from you? Do not just throw a ticket over the wall. Define the exact information required for a dependency ticket to be accepted.
- Response SLAs: Establish a timeline for acknowledgment. For example, an external team must review and accept or reject a dependency request within 48 hours.
- Prioritized Backlog Slots: Component teams and shared services must stop filling 100% of their sprints with their own feature work. Mandate that teams dedicate a set percentage (e.g., 15-20%) of their capacity specifically for cross-cutting enablers and external dependencies.
Predictability Follows Wait-Time Reduction
Scaling Agile has never been about making teams run faster on a treadmill. It is about clearing the track so they can actually run.
When you focus relentlessly on Dependency Resolution Time, you attack the root cause of missed commitments and bloated lead times. Visibility forces accountability, measurement exposes the real bottlenecks, and operating agreements give teams a framework to collaborate rather than collide.
Shrink your dependency resolution time, and delivery predictability will automatically follow. Stop worrying about how fast your developers are coding, and start looking at how long they spend waiting.