We had a hunch that dependencies were the silent killer behind missed deadlines. Not the "we need to hire more people" kind of problem. Not the "estimations are hard" kind. Something more structural. Something hiding in plain sight inside your Jira board.
So we decided to put numbers on it.
The Starting Point: A Coin-Flip Model
A few years ago, Troy Magennis — a well-known figure in the software forecasting world — posed a deceptively simple question: if each dependency has a 50/50 chance of being on time, what are the odds that ALL of them land on time?
The math is straightforward:
- 1 dependency — 50% chance everything's fine
- 2 dependencies — 25%
- 3 dependencies — 12.5%
- 5 dependencies — 3%
- 7 dependencies — less than 1%
It's a coin-flip model. Intentionally simple. A teaching tool designed to make one point crystal clear: dependencies compound risk fast.
But here's what nagged us: is that actually true with real teams, real projects, real delivery data? Or is it just a scary campfire story for engineering managers?
We Tested It Against Real Data
We pulled delivery data from different organizations — different industries, different team sizes, different ways of working. Tens of thousands of work items. We looked at two types of dependencies:
- Explicit blocking links — "I can't start until you finish"
- Parent-child relationships — an epic can't close until all its stories close
For each, we measured a simple thing: as the number of dependencies grows, how quickly do your chances of hitting the deadline drop?
What We Found
The good news: Magennis's coin-flip model is way too pessimistic. Real teams aren't flipping coins. They communicate, they coordinate, they adjust. At three dependencies, where his model predicts a 12.5% chance of being on time, the real number across organizations was closer to 50-80%.
The bad news: the compounding is real, and it's relentless.
Here's the pattern we saw in every single organization we studied:
- At 2 dependencies, on-time rates start slipping — consistently 5-15% lower than a single item working alone.
- At 5 dependencies, you've lost roughly a third of your chances compared to independent work.
- At 10 dependencies, roughly half of those groups miss their target.
- At 30+ dependencies — think a large epic with dozens of child stories — on-time rates drop to single digits in some organizations.
And the critical insight: the drop isn't linear. Going from 1 to 3 dependencies hurts more, proportionally, than going from 10 to 12. The first few dependencies carry the most risk. After that, you're already in trouble — adding more just digs the hole a little deeper.
The Organizational Fingerprint
Here's what surprised us most. The shape of the curve — risk compounding as dependencies pile up — was identical across all studied organizations. But the steepness varied dramatically.
One organization barely noticed the effect at 10 dependencies. Another was already in serious trouble at 5. Same pattern, wildly different severity.
Why? It comes down to how tightly coupled the work is. Teams where the same people touch many related items — where stories under an epic share assignees, share sprints, share context — showed a different profile than teams where work was distributed across many independent contributors.
Neither is inherently better. But you need to know which one you are, because the same dependency count means very different things depending on your team's structure.
The Hidden Killer: Starting Before You're Ready
We also stumbled onto something we didn't expect to find. Across every organization we studied, the majority of blocked items started work before their blockers were resolved. Not sometimes. Not occasionally. The majority.
At one dependency, 60-85% of items had already entered "In Progress" before their blocker was done. At five or more dependencies? It was 100%. Every single time.
This creates what we started calling "zombie work" — items sitting in an active status, burning cycle time, but not actually making progress because they're waiting on something upstream. The board says "In Progress." Reality says "Stuck."
And here's the kicker: most cycle time calculations don't properly account for this. The item looks slow. The real problem is it started too early.
What This Means For How You Plan Work
We're not going to share the full model here (we're still refining it and building it into the product). But the practical takeaways are clear enough:
1. Every dependency you remove matters — especially the first few. The relationship between dependency count and delivery risk isn't linear. Cutting from 5 dependencies to 3 buys you more than cutting from 15 to 13. If you're looking for leverage, reduce the total dependency count on your most critical items.
2. Your organization has its own risk profile. There's no universal formula. An epic with 8 child stories means something different in your organization than in mine. You need to measure your own data to know where you stand. Off-the-shelf rules of thumb will mislead you.
3. Blocking links and parent-child relationships carry different risk. Explicit blockers — "I can't start until Team X finishes" — behave more like independent coin flips. Children under a common parent — "these 8 stories all need to ship for the feature to be done" — are correlated. They tend to succeed or fail together. The risk math is different for each.
4. Watch for premature starts. If an item has blockers and it's already "In Progress," that's a red flag. It's probably not actually progressing. It's accumulating phantom cycle time. This is one of the highest-leverage signals you can monitor.
5. Big epics need scrutiny, not just tracking. An epic with 20+ children isn't just a tracking container. It's a probability machine, and the odds are working against you. The organizations that delivered well at high child counts weren't lucky — they were actively managing the coordination overhead.
The Bottom Line
Troy Magennis was right about the direction: dependencies compound risk, and most teams dramatically underestimate the effect. His coin-flip model overstates the severity, but the core message holds.
What our research across multiple organizations adds is nuance. The compounding is real, but it's sub-linear for related work and organization-specific in severity. It's not a death sentence — it's a measurable, manageable risk. But you have to measure it first.
The teams that ship reliably aren't the ones with no dependencies. They're the ones that know their dependency profile and act on it.
Quantify helps engineering teams measure flow, forecast delivery, and identify hidden risks in their data.
Related reading:
- Troy Magennis, Focused Objective — the original dependency compounding work