Managing Dependencies in Agile: How to Eliminate Them, Not Just Track Them

Dependencies are handled in three stages, in order of value. Eliminate them by redesigning teams or slicing work differently. Mitigate what remains by substituting a lighter dependency. Manage the rest through mapping, named owners and regular coordination. Most teams skip straight to managing, which is why dependencies never reduce.

Key Highlights

• The hierarchy is eliminate, then mitigate, then manage. Tracking a dependency is the last resort, not the first move.
• The most effective elimination technique is cross functional team design, where a team holds every skill needed to deliver a feature end to end.
• A dependency map is only useful with a named owner, a risk level and a mitigation plan against each entry. A list of arrows on a diagram changes nothing.
• Ad hoc coordination through chat messages does not scale past a handful of teams. Structured check-ins do.
• Dependencies discovered mid Sprint are usually planning failures rather than surprises, and the fix belongs in refinement.
• More coordination is not the goal. A team spending significant time managing dependencies has an organisational design problem, not a process problem.

What a Dependency Actually Costs

A dependency is anything your team needs from outside itself before it can finish work. Another team's API, a specialist's time, a shared environment, a decision from someone unavailable.

The cost is rarely the waiting itself. It is what the waiting does to everything around it.

Work sits partially finished, which ties up capacity without producing anything. The team starts something else to stay busy, so now two things are half done. Context switches multiply. The original item, when it finally unblocks, needs re-understanding because a fortnight has passed.

That is why a single blocked item frequently costs several times its own size in lost flow. It is also why measuring dependencies by count understates their impact badly.

If you are moving into a Scrum Master role, dependency handling is one of the areas where the job is most visible, and it is largely a facilitation and organisational problem rather than a process one. Ourfree CSM practice test covers the framework fundamentals if you want to check where you stand before formal training.

The Types of Dependency

Naming the type matters, because each has a different remedy.

Two of these are worth separating out.

Knowledge dependencies masquerade as technical ones. A team says it cannot proceed without the payments specialist, and the underlying issue is that only one person has ever worked on payments. The remedy is not better scheduling of that person, it is spreading the knowledge, which most teams never prioritise because it is slower in the short term.

Sequential dependencies are frequently not genuinely sequential. Teams assume order because that is how the work was described, not because the second item technically requires the first. Interrogating this often frees more than any coordination tooling.

Step One: Eliminate

This is where the real gains are, and where almost nobody starts.

Redesign team boundaries. The single most effective intervention is building cross functional teams that hold every skill needed to deliver a feature from idea to release without external specialists. Teams organised around a component create dependencies by definition, because no feature lives inside one component. Teams organised around a customer capability can finish work alone.

This is an organisational decision, not a team decision, which is why it gets avoided. It is also why dependency problems persist for years in companies that have tried every coordination technique available. The wider principles ofcrossfunctional Scrum teamsare worth understanding before proposing a restructure.

Slice work differently. Many dependencies exist because of how an item was written rather than anything inherent. An item requiring three teams can often be split into three items each owned by one team, with a thin integration piece at the end. This is a refinement skill and it is backlog breakdown work rather than coordination work.

Bring the skill into the team. If a team repeatedly waits on the same specialist, the question is whether that skill should live inside the team. Sometimes hiring is the answer. More often, pairing over a few months transfers enough capability to remove the bottleneck.

Question whether it is needed at all. A surprising number of dependencies exist because someone wants to review, be informed or approve. Some of that is necessary and some is habit. Each removed approval step removes a queue.

Elimination is slower and more political than tracking, which is exactly why organisations default to tracking. Tracking is available to a team today. Elimination requires someone with authority to change how teams are shaped.

Step Two: Mitigate

When a dependency cannot be removed, the next best move is to make it smaller or less risky.

Agree the interface early. If two teams must integrate, define the contract in the first days rather than at the point of integration. Both teams can then build against an agreed shape and discover mismatches early. This alone removes most integration surprises.

Stub or mock the dependency. A team can often build and test against a fake version of what it needs, then swap in the real thing later. This converts a blocking dependency into a sequencing one, which is far cheaper.

Reorder rather than wait. If item A depends on another team and item B does not, pull item B forward. Obvious in principle and frequently missed because backlogs are ordered by value alone without dependency awareness.

Reduce the size of the dependency. Needing a full service from another team is expensive. Needing one endpoint is much cheaper. Negotiating scope down is often possible where removing the dependency entirely is not.

Build in buffer, honestly. Some dependencies, particularly external ones, will slip. Planning as though they will not is optimism rather than planning. Where slippage is likely, the buffer belongs in the plan explicitly rather than hidden in individual estimates.

Step Three: Manage What Remains

Only now does tracking earn its place, and only for what genuinely could not be eliminated or mitigated.

A dependency map is the standard tool, and it works when each entry carries enough information to act on:

• What the dependency is, in plain terms
• Which teams are involved on both sides
• The type, using the categories above
• A single named owner, a person rather than a team
• A risk level
• A mitigation plan with a date

A map without owners and dates is a diagram. Diagrams do not unblock anything. The named owner is the field that matters most, because dependencies fail precisely when both sides assume the other is handling it.

Keep the map somewhere the teams already look. Dependency information that lives in a separate tool nobody opens will be stale within two Sprints.

For coordination, theScrum of Scrums is the standard mechanism, with representatives from each team giving short updates on progress and blockers. It works when it stays focused on cross team issues and fails when it becomes a status meeting.

Ad hoc coordination through chat messages and corridor conversations works at two or three teams and collapses beyond that. Once coordination is happening informally between five or six teams, information is being lost and nobody can see where.

Why Team Boundaries Create Dependencies

Almost every persistent dependency problem traces back to one decision: how teams were divided in the first place.

There are broadly two ways to draw the lines.

Component teams own a technical layer. A front end team, a back end team, a database team, a mobile team. Each is efficient inside its own area and deeply specialised.

Feature teams own a slice of customer capability end to end. A checkout team, a search team, an onboarding team. Each contains whatever skills that slice requires.

Now consider a single feature such as adding a payment method. In a component structure it needs front end work, back end work, a schema change and mobile support. That is four teams, four backlogs, four sets of priorities and four planning cycles that must align. The dependency was created by the org chart before anyone wrote a line of code.

In a feature structure the checkout team does all four pieces. No cross team dependency exists, because the boundary was drawn around the work rather than across it.

This is why coordination tooling disappoints. A dependency map applied to a component structure documents a problem the structure guarantees. The map is accurate and the situation does not improve.

Component teams are not always wrong. They make sense where a genuine deep specialism exists, where a platform serves many teams, or where regulatory separation is required. The mistake is adopting them by default because that is how engineering departments have traditionally been organised, then treating the resulting dependencies as an unavoidable fact of life.

Two practical signals suggest the boundary is wrong. If most items in your backlog need more than one team, the boundary is cutting across your work. And if the same two teams appear together on dependency after dependency, they are probably one team that has been split.

Changing this is not a team level decision, which is the honest difficulty. What a Scrum Master can do is make the pattern visible with evidence. Six months of dependency data showing which teams repeatedly block each other is a far stronger argument to leadership than a general complaint about silos. Building that case is exactly the kind of organisational work covered in CSM Certification Training.

A Worked Example: Tracing a Dependency to Its Root

Consider a team that reports the same blocker for three Sprints running. They cannot complete reporting features because they need schema changes from the data team, and the data team is always busy.

The default response is coordination. Add the data team to the Scrum of Scrums, put the request in earlier, escalate to the data team's manager. That produces a slightly faster queue and the blocker returns next quarter.

Working through the hierarchy properly looks different.

Can it be eliminated? Ask why schema changes require a separate team. Frequently the answer is a historical rule about who may alter the database, not a technical constraint. If the reporting team could make its own schema changes under review, the dependency disappears entirely. That is a governance conversation rather than a scheduling one.

Can the skill move? If the constraint is genuine expertise, one data engineer pairing with the reporting team for a Sprint may transfer enough capability to handle routine changes, keeping only complex work with the data team. The dependency shrinks from every item to occasional items.

Can the work be sliced? Often a reporting feature needs one small schema change and a large amount of independent work. Splitting the item lets the team request the small change early and proceed with everything else while it is pending.

Can the interface be agreed upfront? If the data team commits to the schema shape in week one, the reporting team can build against it immediately and integrate later, converting a blocking dependency into a sequencing one.

Only then, manage it. Whatever survives all four questions goes on the dependency map with a named owner and a date.

The pattern is that four of the five options were never considered, because coordination is the reflex. Working down the list takes longer and is the only route that reduces the dependency rather than scheduling it more neatly.

Dependency Anti-Patterns

Six behaviours that consistently make things worse.

Treating the dependency map as the solution. The map records the problem. Teams that build elaborate tracking and stop there feel productive while nothing structural changes.

Escalating too late. Politeness costs more than most teams realise. Waiting a week to raise a blocker because the other team seems busy converts a small issue into a lost Sprint.

Filling the gap with new work. When something blocks, teams start something else. Two half finished items are worse than one blocked item and one finished one. Helping complete work already in progress is usually better.

Committing to work with open dependencies. Selecting an item that needs something external, on the assumption it will probably arrive, is the most common source of carryover. If the dependency is not confirmed, the item is not ready.

Building coordination roles instead of fixing structure. Organisations that keep adding coordinators, programme managers and integration leads are paying permanent salary to route around a structural problem. Occasionally that is the right trade. Usually it is avoidance.

Assuming sequential means sequential. Teams accept a stated order without testing it. Asking what specifically breaks if these run in parallel frequently reveals that the order was a description rather than a constraint.

Handling Dependencies in Planning

Most dependency pain traces back to planning rather than execution.

Surface dependencies during refinement, not during Sprint Planning. By the time an item reaches planning it should already be known whether it needs anything external. Items with unresolved dependencies are not ready and should not be selected. This is the single most effective discipline available, and it is why refinement quality determines Sprint quality.

Ask two questions of every substantial item during refinement. What do we need from outside the team to finish this? And what would we do if that arrives late? An item where nobody can answer the second question is a risk that has not been thought through.

At scale, dedicated planning events exist for exactly this. PI planning brings multiple teams together specifically so that cross team dependencies surface while there is still time to sequence around them, rather than mid Sprint when options are limited.

Do not select work that depends on something outside theSprint unless the dependency will demonstrably be met inside it. Taking on such work is optimism dressed as commitment, and it produces the carryover that erodes trust in the team's forecasts.

When a Dependency Blocks You Mid Sprint

Despite good planning, items block. The response matters more than the prevention at that point.

Raise it the same day, in the Daily Scrum. Dependencies that sit unmentioned for three days have cost three days.

Do not start something new to fill the gap without thinking. The instinct is to stay busy, and it creates a second partially finished item. Often the better move is to help finish something already in progress.

Escalate on a clock. Agree in advance how long the team waits before the Scrum Master takes it outside the team. Two days is a reasonable default. Without a threshold, teams wait far too long out of politeness.

Removing impediments of this kind is core Scrum Master work, and doing it well is more about relationships across the organisation than about process. It is one of the areas where theScrum Master skill set matters most, and it is covered in depth in CSM Certification Training.

Record it afterwards. A blocked item that resolves and is never discussed again teaches the team nothing. The retrospective should ask what would have surfaced it earlier.

Measuring Dependencies

Teams rarely measure this, which is why they cannot tell if anything is improving.

Blocked time is the most useful measure. Total days items spent blocked in a Sprint, not the count of dependencies. One item blocked for eight days is worse than four blocked for one.

Dependency count per item shows whether slicing and team design are improving. If the average is falling, elimination is working.

Percentage of carryover caused by dependencies separates a dependency problem from an estimation problem. Teams often assume they are over committing when they are actually waiting.

Time from raised to resolved measures the escalation path rather than the dependency itself. A long time here points at organisational responsiveness.

Track these over a quarter rather than a Sprint. Dependency patterns are structural and move slowly.

One caution on measurement. Publishing dependency metrics between teams invites blame, and blame makes people stop reporting blockers honestly. Present the data as a property of the system rather than a scorecard for individual teams. The useful question is which boundaries generate the most friction, not which team is slowest to respond.

Dependencies at Scale

Everything above holds for one team. Across many teams the problem changes character, because dependencies grow faster than teams do.

Two teams have one possible relationship. Five teams have ten. Ten teams have forty five. Coordination overhead grows quadratically while output grows linearly, which is the mathematical reason large agile transformations stall.

Frameworks exist to handle this, and they take different approaches.LeSS attacks the problem by keeping one Product Backlog and feature teams, aiming to remove dependencies structurally. SAFe accepts them and provides coordination machinery through the Agile Release Train and PI planning.

Neither is a shortcut. Both are attempts to manage a problem created by how the organisation is structured. The common problems in scaling agile are largely dependency problems in different clothing.

The uncomfortable conclusion is that if coordination overhead is high, adding coordination mechanisms treats the symptom. The cause is usually team boundaries drawn around components or technologies rather than around customer value.

Dependencies and the Definition of Done

A connection worth making, because it catches teams repeatedly.

If yourDefinition of Done includes anything performed by someone outside the team, you have a dependency built permanently into every single item. Deployment requiring a separate operations team, security sign off from a central function, or QA performed by a shared testing group all fall into this category.

The consequence is that no item can ever reach done inside a Sprint without external cooperation. Teams in this position often conclude they are bad at estimating, when in fact they have a structural dependency embedded in their own quality standard.

Two responses are available. The better one is bringing the capability into the team, so deployment or security review becomes something the team performs itself under an agreed standard. The alternative, where that is genuinely impossible, is agreeing a standing arrangement with the external function that guarantees turnaround inside a defined window.

What does not work is leaving it unaddressed and treating each occurrence as a fresh surprise. If the same external step blocks every Sprint, it is not an impediment, it is the design of your process.

A related trap is a Definition of Done written aspirationally, including steps the team cannot actually perform. That guarantees either unmet standards or permanent dependency, and neither is a good position. The definition should describe what the team can genuinely complete, then be strengthened as capability grows.

Frequently Asked Questions

1. What is a dependency in agile?

Anything a team needs from outside itself before it can complete work. That includes another team's output, a specialist's availability, a shared environment, or an external approval.

2. How do you manage dependencies between agile teams?

In order of value: eliminate them through cross functional team design and better work slicing, mitigate what remains by agreeing interfaces early and stubbing where possible, then manage the rest with a dependency map carrying named owners and regular coordination.

3. What is dependency mapping?

A living record of cross team dependencies. Each entry names the dependency, the teams involved, the type, a single accountable owner, a risk level and a mitigation plan with a date. Without owners and dates it is a diagram rather than a tool.

4. Should dependencies be identified in Sprint Planning?

They should be identified earlier, during refinement. An item with unresolved dependencies is not ready for a Sprint. Discovering one during planning means refinement did not do its job.

5. Who is responsible for resolving dependencies?

The team handles what it can directly. The Scrum Master removes impediments the team cannot resolve alone, which usually means cross team or organisational blockers. At scale this may be a Release Train Engineer or equivalent.

6. How can you reduce dependencies permanently?

Change team structure. Cross functional teams organised around customer capability rather than technical components have far fewer dependencies by design. This is an organisational decision rather than a team level one.

7. What is the difference between a dependency and an impediment?

A dependency is a known need for something external, usually identifiable in advance. An impediment is anything blocking progress, which includes dependencies but also covers environment failures, unclear requirements and organisational obstacles.

8. Do dependencies mean the team is not truly self organising?

Not necessarily. Self organisation refers to how a team decides its own way of working, not to whether it needs anything external. Even a well designed team will occasionally depend on others. What does undermine self organisation is a structure where the team cannot finish anything without permission or input from elsewhere.

9. Should dependencies be tracked on the team board?

Yes, visibly. A blocked item that looks identical to work in progress hides the problem. Marking blocked items clearly, with who is being waited on and since when, makes the cost obvious to everyone including stakeholders.

10. How long should a team wait before escalating?

Agree a threshold in advance, and two days is a common default. The important part is having a rule, because without one teams wait far longer than they should out of politeness.

Closing Thoughts

Most advice on dependencies is really advice on tracking them, which is the least valuable of the three options available. Tracking makes a problem visible. It does not make it smaller.

The teams that genuinely reduce dependency pain do two unglamorous things. They slice work so that one team can finish it alone, and they push for team boundaries drawn around customer capability rather than technical components. Both are slower than adopting a coordination tool, and both are the only things that produce lasting change.

A useful test for any team is to look at the last quarter and ask how many dependencies were eliminated rather than managed. For most teams the answer is none, and that is the honest starting point.

Start small if the structural conversation feels out of reach. Pick the single dependency that has cost the most this quarter, work it through the eliminate and mitigate questions properly, and see how far it moves. One dependency genuinely removed teaches a team more than a year of tracking, and it gives you evidence for the larger argument later.

If you want to build the facilitation and organisational skills this requires, CSM Certification Training from an accredited Scrum Alliance provider covers impediment removal and cross team working alongside the framework. Request the full course curriculum if you would like to see the agenda and upcoming dates, or check your current understanding with our free CSM practice test.