A LinkedIn post making the rounds this week breaks down the types of sprint dependencies teams should check for before committing to a sprint — and the reaction from Scrum Masters was the same one every time: “dependency” is doing too much work as a single word. Most teams track dependencies as one flat list, which is exactly why the dangerous ones slip through. This pairs with our sprint planning guide and managing dependencies in Scrum.

Why one dependency list isn’t enough

A single “dependencies” field on a ticket treats a two-minute Slack question and a three-week vendor contract renewal as the same risk. They’re not. Each type of dependency shows up at a different point in the sprint, gets caught by a different kind of check, and derails the sprint in a different way. Naming the type is what makes it possible to catch early, instead of during the daily standup where it’s already a blocker.

The five types worth tracking separately

• Sequential (technical) dependencies — Story B genuinely cannot start until Story A’s code merges. These are visible in the work itself if anyone maps it out.
• Resource dependencies — the one engineer who understands the legacy billing service is also the only reviewer for two other stories this sprint.
• Cross-team dependencies — the feature needs an API another team owns, and that team is mid-sprint on something else entirely.
• External or vendor dependencies — a third-party integration, a data feed, or a contract that moves on someone else’s timeline, not yours.
• Decision or approval dependencies — legal sign-off, a design review, or a stakeholder decision that hasn’t actually been made yet, even though the ticket assumes it has.

Most sprint retrospectives that mention “dependencies” as a cause of a missed goal are really describing one of these five — usually the same one or two, repeatedly, for a given team.

A quick example

A story to “add saved payment methods to checkout” can look plannable right up until sprint planning surfaces all five types at once: the UI work is sequential behind a shared component (technical), the one engineer who knows the payment gateway is out for two days (resource), the tokenization endpoint belongs to the platform team (cross-team), the payment processor’s sandbox has a known outage window (external), and legal hasn’t confirmed which card brands are in scope for this release (decision). None of that is unusual — it’s what a real story looks like. The problem isn’t that the dependencies exist; it’s that a single “dependencies: TBD” field would have hidden all five behind one word.

Where each type likes to hide

Sequential and resource dependencies usually hide inside a single team’s backlog, which makes them the easiest to catch during refinement if anyone looks. Cross-team and external dependencies hide in the assumption that “someone else has that handled” — nobody owns confirming it until it’s late. Decision dependencies are the sneakiest: the ticket reads as ready because the acceptance criteria are written, but they describe a decision that was proposed, not confirmed.

A lightweight way to tag them

Teams don’t need a new tool to start separating these — a simple tag or label per dependency type, applied during backlog refinement, is enough to start. The value shows up at sprint planning, when the team can scan for cross-team and external tags specifically and ask “has this actually been confirmed?” instead of assuming a general “dependencies: yes” field means the risk was checked.

Making the check automatic

Once dependencies are typed instead of lumped together, they can be surfaced automatically rather than relying on someone remembering to ask in every refinement session. Dependency Manager for Jira maps dependencies across issues and teams and flags the ones — cross-team and external, most often — that are still unconfirmed as a sprint approaches. Paired with the practices in our sprint planning guide, it turns “we think dependencies are handled” into something the team can actually verify before they commit.

Rob Borges

Rob Borges spent the first half of his career hunting waste as a Lean Six Sigma Master Black Belt and wrangling portfolios as a PMI Portfolio Manager — until he realized the tidiest process on earth still can't out-plan an optimistic human. So he switched sides and became an Agile Coach. These days he helps Kanban, Scrum, and Agile-at-Scale teams trade gut-feel deadlines for flow data, turning "we'll probably ship sometime in Q3" into release dates leaders can actually take to the board. His rule of thumb: hope is not a forecast, but your throughput history usually is.

See Full Bio