Dependency management in 60 seconds
- What it is: finding, agreeing, tracking and reducing the points where one team's work waits on another's.
- Where it shows: the ART Planning Board, "a visualization of the PI's feature delivery dates, feature dependencies among teams, and relevant milestones."[1]
- Who coordinates: in SAFe, the Coach Sync "helps coordinate ART dependencies and provides visibility into progress and impediments."[1]
- The real fix: fewer dependencies. DORA finds that loosely coupled teams predict continuous delivery.[2]
- Rule of thumb: every dependency needs an owner, a needed-by date and a status. Without those three it is a hope.
What is a dependency in agile?
A dependency is a relationship in which one piece of work cannot start or finish until another is done. In agile at scale the important ones are between teams: a feature that needs an API from another team, a shared platform, a supplier delivery or a compliance sign-off.
Dependencies are not a sign of failure. Any product bigger than one team has them. The problem is the unmanaged ones: the dependency nobody wrote down, discovered in the third iteration when it is too late to re-plan. Researchers studying large-scale agile put it plainly: "Managing dependencies between teams and within teams is critical when running large-scale agile projects."[3]
What types of dependencies are there?
It helps to classify dependencies two ways: by what you depend on (another team, a shared service, an external party, a decision) and by the scheduling relationship (finish-to-start, start-to-start, finish-to-finish, start-to-finish).
| Relationship | Meaning | Example |
|---|---|---|
| Finish to start | B cannot start until A finishes. The most common. | The payment API must be done before checkout integration starts. |
| Start to start | B cannot start until A starts. | Test automation starts once development starts. |
| Finish to finish | B cannot finish until A finishes. | Documentation cannot be finished until the feature is. |
| Start to finish | B cannot finish until A starts. Rare. | The old system is switched off once the new one starts running. |
These four are the standard types in scheduling practice.[4] Azure DevOps models the first directly with its Predecessor and Successor link: "Use this directional link to track tasks that must finish before others start."[5]
Why do dependencies matter so much at scale?
Because the waiting, not the work, is what makes delivery slow. Each dependency adds a hand-off and a queue, and the delays compound across teams. Evidence from DORA and from field studies points the same way: coupling between teams is a main source of delay.
- DORA finds that "effective organizational and technical structures are predictors for achieving continuous delivery", and describes high performers as able to "complete work without needing fine-grained communication and coordination with people outside the team."[2]
- SAFe traces the problem to structure: organising by function brings "incumbent dependencies, handoffs, waste, and delays."[6]
- A 2025 interview study at two Nordic fintech companies reports, as a preliminary finding, that dependencies "between software teams and support functions, as well as between software teams and external entities, are the primary sources of delays and bottlenecks."[7]
That last point matches what most Release Train Engineers see. The dependencies inside the train get discussed in planning. The ones on security, legal, infrastructure and suppliers are the ones that bite.
How do you map dependencies?
Map dependencies on a board with a row per team and a column per iteration. Place each feature where it finishes, then draw a line from the work that is needed to the work that needs it. A line that points backwards in time is a problem to solve before planning ends.
- Start from the features. For each one, ask the team: what do you need from anyone else to finish this?
- Write it as a request. "Team Payments needs the tokenisation API from Team Platform by iteration 2."
- Get the provider to accept it. A dependency is only real when the giving team has it in their plan.
- Place both ends on the board and join them.
- Check the direction. The provider must finish in an earlier iteration than the consumer needs it. Same iteration is a risk. Later is a conflict.
- Record owner, needed-by date and status on the dependency itself.
- Look for clusters. A team with many incoming lines is a bottleneck, and its capacity sets the pace for everyone.
A dependency wheel shows the same information from another angle: teams around a circle, with a line for every dependency between them. It makes the bottleneck teams obvious at a glance.
How do you manage dependencies through a planning interval?
Agree dependencies during PI Planning, review them at every cross-team sync, and escalate the moment a needed-by date is at risk. The board is only useful if it is kept current after the planning event.
- In PI Planning: the plan review is where teams explain their dependencies. An ART Planning Board that "reflects feature delivery dates and dependencies" is one of the outputs of the event.[8]
- In the Coach Sync: go through open dependencies by needed-by date, not team by team.
- In Nexus: the Nexus Sprint Backlog "is used to highlight dependencies and the flow of work during the Sprint", and cross-team refinement "reduces or eliminates cross-team dependencies."[9]
- When something slips: the provider tells the consumer the same day. Finding out at the demo is the failure mode to design against.
Tip from the fieldTreat a dependency scheduled for the same iteration as its consumer as a risk and ROAM it. There is no slack, so any delay on one side lands on the other. See the ROAM guide.
How do you reduce dependencies instead of just managing them?
Change what causes them. Organise teams around features or value streams, not components. Decouple the architecture so teams can release independently. Give teams the skills and access they keep asking others for.
- Feature teams. LeSS contrasts component teams, where "dependencies between teams leads to additional planning", with feature teams, which minimise "dependencies between teams to increase flexibility."[10]
- Organise around value. "Business Agility demands that enterprises organize around value to deliver more quickly."[6]
- Loosely coupled architecture. So a team can test and deploy without coordinating with others.[2]
- Platform as a service. Team Topologies describes an X-as-a-Service interaction mode, where a platform team offers something others consume without a hand-off.[11]
- Read the signal. LeSS warns that "the desire to hold a Scrum of Scrums can be a sign of unnecessary dependency or coordination problems."[12]
Use your dependency data to choose where to act. If the same two teams are linked every PI, they may need to be one team, or the boundary between them is in the wrong place.
What should you measure?
Measure how many dependencies you have, how many are resolved on time, how often they change after planning, and which teams they concentrate on. Trends across planning intervals matter more than any single number.
| Metric | What it tells you |
|---|---|
| Dependencies per PI | Whether coupling is growing or shrinking over time. |
| Resolved on time | How reliable commitments between teams are. |
| Changed after planning | How good planning was at finding them. |
| Incoming dependencies per team | Where the bottlenecks are. |
| External share | How much of your risk sits outside the train. |
| Features blocked | The delivery impact of open dependencies. |
How do you manage dependencies in Jira and Azure DevOps?
Both tools store dependencies as links between work items. Jira uses link types such as "blocks". Azure DevOps uses Predecessor and Successor. What neither does well on its own is show all of them across teams on one board with dates, owners and alerts.
- Jira: the default "Blocks" link type has "blocks" as its outward description, and each link type has a name with outward and inward descriptions.[13]
- Azure DevOps: "Choose Predecessor when linking to a work item that should complete before the current item."[5] Delivery Plans draw these as lines.[14]
Kendis reads those links and draws them as dependency lines on the program board, and creates the link in Jira or Azure DevOps when you draw one in Kendis. Each dependency carries a due date, owner, conversation and status, with alerts when a date is missed and warnings when the order is wrong. See dependency management in Kendis.
Put this into practice, free for 6 months
Kendis is a PI Planning and tracking platform that sits on top of Jira and Azure DevOps. The free trial runs for six months, long enough to plan and track two full PIs with your real backlog before anyone has to approve a budget.
- 6 months free, no credit card
- Choose EU hosting (OVHcloud, Frankfurt) or US hosting (AWS)
- Planning board, dependencies, PI objectives, ROAM risks, solution boards
- Two-way sync with Jira Cloud, Jira Data Center and Azure DevOps
- ISO/IEC 27001 certified, GDPR compliant, DORA Schedule available
- No user caps and no setup costs during the trial
One trial per organisation that has not used Kendis in the last twelve months. After the trial, Premium Cloud is $14 per user per month billed annually, or $16 monthly, and you license only the people who plan. SSO, Kendis AI and premium support are part of paid plans. See pricing and the free trial terms.
Dependency management: frequently asked questions
What is dependency management in agile?
Dependency management is the practice of identifying, agreeing, visualising and tracking the points where one team's work depends on another team, supplier or system, and reducing those dependencies over time.
What are the four types of dependencies?
In scheduling, the four standard relationships are finish-to-start, start-to-start, finish-to-finish and start-to-finish. Finish-to-start is by far the most common.
What is a dependency map?
A dependency map is a visual of which work depends on which. In agile it is usually a board with a row per team and a column per iteration, with lines between dependent features or stories.
Who is responsible for managing dependencies in SAFe?
The teams own their dependencies. The Release Train Engineer and the Scrum Masters or Team Coaches coordinate them through the Coach Sync, which SAFe describes as an event that helps coordinate ART dependencies.
How do you identify dependencies in PI Planning?
In the team breakouts, each team asks of every feature what it needs from others to finish. Each need is written as a request, accepted by the providing team and drawn on the ART Planning Board.
How do you reduce cross-team dependencies?
Organise teams around features or value streams, decouple the architecture so teams can release independently, and provide shared capabilities as self-service platforms. Use dependency data to see which team boundaries cause the most links.
How are dependencies shown in Jira?
As links between work items, using link types such as blocks and is blocked by. Jira Plans and tools such as Kendis draw those links as lines on a board.
Sources
Every external claim in this guide links to the primary source below. All links were checked on 12 October 2026.
- Scaled Agile, Inc.. SAFe Glossary.
- DORA. Capabilities: Loosely coupled teams (updated 20 October 2025).
- Stray, Moe and Aasheim. Dependency Management in Large-Scale Agile: A Case Study of DevOps Teams (HICSS 2019).
- Wikipedia. Dependency (project management).
- Microsoft Learn. Link types reference guide (Azure Boards).
- Scaled Agile, Inc.. SAFe Lean-Agile Principles.
- Tkalich et al.. Identifying Critical Dependencies in Large-Scale Continuous Software Engineering (preprint, 2025).
- Scaled Agile, Inc.. PI Planning.
- Scrum.org. The Nexus Guide (January 2021).
- The LeSS Company. Feature Teams.
- Team Topologies. Key concepts.
- The LeSS Company. Coordination and Integration.
- Atlassian Support. Configure work item linking.
- Microsoft Learn. Track dependencies in Delivery Plans.
How this guide is maintained: definitions are checked against the framework pages and other primary sources listed above, and the guide is updated when terminology or guidance changes. Examples, checklists and practical advice are Kendis guidance and are not official SAFe material. SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.