Azure Boards stores schedule relationships as Predecessor and Successor links, but it has no built-in critical-path Gantt view. Use Dependency Tracker or a connected scheduler—and verify which links the connector actually imports.
How do Azure DevOps dependencies appear in a Gantt chart?
Azure Boards records delivery dependencies with directional Predecessor and Successor work-item links, but Azure Boards does not provide a built-in critical-path Gantt chart. Microsoft’s Dependency Tracker extension offers lists, risk views, and a beta timeline. A connected scheduler can provide task bars and CPM—but only if it imports or recreates the dependency links.
GanttFather currently imports Azure DevOps work items, dates, assignments, status, and Parent/Child hierarchy into a Gantt project. It does not import Azure Predecessor/Successor links as Gantt dependencies. After the pull, add the scheduling relationships in GanttFather; those local links drive dependency arrows and critical-path analysis and are not overwritten by later pulls.
Behavior verified: August 30, 2026 against Microsoft documentation and GanttFather’s current Azure DevOps feature contract.
Which Azure DevOps link type represents a dependency?
Use Predecessor/Successor for delivery order. A predecessor is the producer that must come first; a successor is the consumer that depends on it. Azure DevOps prevents circular relationships for this dependency topology and supports one-to-many links.
| Azure DevOps relationship | Meaning | Is it a schedule dependency? | Gantt interpretation |
|---|---|---|---|
| Predecessor | Linked item should finish before the current item | Yes | Usually predecessor side of an FS link |
| Successor | Linked item should happen after the current item | Yes | Usually successor side of an FS link |
| Parent / Child | Portfolio or backlog hierarchy | No | Summary row / child row |
| Related | General association | No | Reference only |
| Produces For / Consumes From | Cross-organization directional dependency | Yes, for remote work items | External dependency requiring explicit mapping |
Pipeline dependsOn | Stage or job execution order in YAML | Pipeline-only | Not a work-item link |
Parent/Child and Predecessor/Successor answer different questions. Parent/Child says “Feature 12 contains User Story 34.” Predecessor/Successor says “API contract must finish before mobile integration starts.” Do not infer scheduling order from backlog nesting.
How do you create work-item dependencies in Azure Boards?
- Open the work item that must wait.
- Open the Links section and choose Add link.
- Select Predecessor.
- Find the work item that must happen first and save.
- Open the other work item and confirm the reciprocal Successor link.
- Add meaningful iteration dates or scheduling fields if the relationship will be shown on a timeline.
Microsoft recommends Predecessor/Successor for tasks that must be completed in sequence. These links can cross projects, although Microsoft’s Excel import/export guidance recommends same-project predecessor links when Excel round-tripping matters.
Azure work-item dependency links do not store all classical CPM detail by themselves. A Predecessor/Successor link communicates order, but an external scheduler may still need durations, calendars, lag, and an explicit mapping to FS, SS, FF, or SF.
What can Azure DevOps visualize without another scheduler?
Azure DevOps offers several timeline-like surfaces, but each answers a different question.
| Azure surface | Best use | Shows dependency relationships | Full Gantt scheduling / critical path |
|---|---|---|---|
| Boards and backlogs | Flow, priority, hierarchy | Links visible on each item | No |
| Delivery Plans | Cross-team iterations and roadmap timing | Not a dependency-network scheduler | No |
| Dependency Tracker extension | Consumer/producer dependency risk | Yes; list, graph, and timeline views | No CPM; timeline is documented as beta |
| Direct-links WIQL query | Audit linked work items | Yes, as query results | No timeline |
| External Gantt scheduler | Dates, bars, arrows, schedule analysis | Depends on connector contract | Yes, when links and durations exist |
Microsoft states that Azure Boards has no built-in way to show the critical path. Dependency Tracker can flag correct or incorrect flow based on predecessor and successor timing, but its timeline depends on work items being assigned to iteration paths whose start and end dates are configured.
How do you pull Azure DevOps work into GanttFather?
The current GanttFather workflow is a controlled pull, not a continuous mirror:
- Connection: enter the organization URL and Personal Access Token, then complete Test connection.
- Project: choose the Azure DevOps project available to that token.
- Source: choose a saved query or team board and, for boards, one level or the full tree.
- Types: review the planning work-item types to import.
- Dates & effort: map Start, End, and optional effort fields for each included type.
- Statuses: map discovered Azure states to exact GanttFather project statuses and review the state Push will use.
- Destination: choose the target parent, review the summary, and save. Saving starts the initial pull.
Add Source reuses the saved connection and project, starts at Source, and follows the last five steps. Configure fields uses the same five-step model but opens at Dates & effort (step 3 of 5), with Back able to reach Types and Source. After the initial pull, review imported dates and hierarchy, then add Gantt dependencies between the imported tasks.
For screenshots and field-mapping details, use the Azure DevOps integration documentation and the broader Azure DevOps Gantt setup guide.
Which fields does GanttFather import from Azure DevOps?
| Azure DevOps data | GanttFather result | Important behavior |
|---|---|---|
System.Title | Task name | Falls back to work-item ID when missing |
System.Description | Task description | HTML tags are removed |
System.State | Project status | Uses default or configured state mapping |
| Priority | Task priority | Azure values 1–4 map to High/Medium/Low |
| Configured Start field | Task start | Falls back to created date when absent |
| Configured Target/End field | Task end | Falls back to one day after start when absent |
| Story points / configured estimate | Estimation | Optional |
| Assigned To | Member or virtual resource assignment | Resolved from known identities |
System.Parent | Parent task | Resolved only when the parent is in the same sync source |
| Predecessor / Successor relations | Not imported | Add and maintain Gantt dependencies locally |
A repeat pull updates the existing mapped task rather than duplicating it. If an Azure work item’s revision has not changed, GanttFather skips it. When a mapped work item leaves the query or board, GanttFather closes the local task rather than deleting it, unless another source in the same connection still tracks it.
How should you model dependencies after the import?
Translate the delivery constraint, not merely the Azure link label. Most Azure Predecessor/Successor relationships are finish-to-start, but the real work may require another type.
| Situation | Gantt dependency | Example |
|---|---|---|
| Successor starts after predecessor finishes | FS | Deploy after security review |
| Two tasks may start together | SS | Backend and frontend implementation |
| Two tasks must finish together | FF | Documentation and feature release |
| One task finishes only after another starts | SF | Retire old support after new support begins |
| Waiting period after an event | FS with positive lag | Begin measurement two days after rollout |
| Intentional overlap | Appropriate type with negative lag | Start QA two days before implementation finishes |
GanttFather enforces dependency rules between sibling tasks, rejects cycles and cross-project links, and supports lag from -365 to 365 calendar days. Read the four Gantt dependency types before translating a complex Azure relationship.
Create dependencies only after checking imported dates. A default one-day bar caused by a missing Azure target date can make a technically valid dependency network produce a meaningless critical path.
What happens when Azure DevOps or GanttFather changes later?
Reviewed Pull compares mapped fields before changing the timeline. Azure-only changes are selected, while a conflicting local date or status stays local under the default Keep my changes choice. Opening Pull normally keeps the summary compact with Advanced collapsed; Keep my changes and Restore from Azure appear under Advanced. The project shortcut and Data & sync expose only the two everyday actions, Pull from Azure and Push to Azure. Initial import happens during setup, while the separately named full Sync source operation remains a Settings maintenance action. Local dependencies and task ordering are not overwritten by either flow.
From the shortcut, Settings, or Data & sync, opening Pull or Push after the previous comparison finishes requests a fresh server-authored comparison, so the review includes the latest Azure changes. Only another opening for the same source while that check is still in progress shares the in-flight request.
Push is the separate reviewed publishing workflow. Eligible local dates and statuses—including conflicts—are selected by default; confirmation overwrites those newer mapped Azure values, and pulling first is optional. Review Pull opens Advanced immediately so Keep my changes and Restore from Azure are visible in the same dialog. Successful Pull or Push closes the sync dialog, and Keep my changes · Close closes it without starting an operation. Estimates and local dependency links are never pushed. Publishing requires a PAT with Work Items: Read & write.
If a selected start or finish would form an invalid range with the current companion date in Azure, Push disables Send before publishing and sends no Azure write. Review Pull opens Advanced so you can restore a coherent date range, or you can close the dialog and adjust the local dates.
There is no scheduler or webhook for the integration. If the Azure plan changes daily, assign an Owner or Admin to pull on an agreed cadence and record the last successful sync before schedule reviews.
How do marketplace extensions compare with an external Gantt tool?
Use Dependency Tracker when Azure DevOps should remain the only work-management surface and the team mainly needs cross-team consumer/producer risk. It preserves native links and reduces duplication.
Use an external Gantt tool when the team needs draggable dated bars, dependency types, lag, critical path, stakeholder sharing, or a schedule that includes non-Azure work. Before choosing any connector, verify these exact questions:
- Does it import Predecessor/Successor links or only Parent/Child hierarchy?
- Which date and duration fields are authoritative?
- Is synchronization automatic, scheduled, or manual?
- Which direction can write, and is there a review step?
- What happens when an item leaves the source query?
- Can it round-trip dependency type and lag without loss?
GanttFather is candid on the first point: its current Azure connector imports hierarchy but not Azure dependency links. That makes GanttFather suitable when you want to build the planning network locally; it is not a zero-maintenance replica of Azure’s link graph.
Are YAML dependencies the same as work-item dependencies?
No. Azure Pipelines uses dependsOn, dependencies, and stageDependencies to control stage/job execution and read prior outputs. Those expressions are pipeline runtime concepts. They do not create Predecessor/Successor links between Azure Boards work items and do not appear in a Gantt chart automatically.
For example, $[ dependencies.Build.outputs['setVersion.value'] ] reads a previous job’s output variable. It says nothing about the scheduled dates of a Feature or User Story. Use Microsoft’s pipeline expressions reference for YAML errors and the work-item link reference for planning relationships.
When is GanttFather useful alongside Azure DevOps?
Use GanttFather when Azure DevOps should remain the backlog and delivery-record system while a smaller group owns the cross-team schedule. The connector can pull mapped work-item fields and Parent/Child hierarchy into one Gantt project; after each manual pull, planners can add FS, SS, FF, and SF dependencies with lag, calculate critical path, and share the live result with viewers or guests.
This is not a dependency mirror: Azure Predecessor/Successor links are not imported or written back, and an Owner or Admin must trigger and review integration activity in the app. The free tier covers one owned project with two editor seats and unlimited viewers and guests. If that controlled split fits your process, create a free GanttFather project and validate one Azure query before building the full local network.
What else do people ask about Azure DevOps dependencies?
Does Azure DevOps have a native Gantt chart?
Azure Boards has roadmaps and extension-based timeline surfaces, but Microsoft does not provide a built-in classical Gantt chart with critical-path analysis. Dependency Tracker includes a beta timeline for dependency flow; Delivery Plans focuses on iteration-based cross-team planning.
Does GanttFather import Azure Predecessor/Successor links?
No. The current connector imports work-item fields and same-source Parent/Child hierarchy. Azure Predecessor/Successor links are not converted into Gantt dependencies. Add those schedule relationships in GanttFather after import; repeat pulls preserve the local dependency set.
Can GanttFather push dependencies back to Azure DevOps?
No. Reviewed Push covers explicitly selected mapped work-item fields, not Azure relation links. It does not create, update, or delete Predecessor/Successor relationships. Keep the Azure link graph authoritative when those native links are required by other Azure tools.
Can Azure DevOps show a critical path?
Microsoft states that Azure Boards has no built-in critical-path view. An external scheduler can calculate one after it has valid task dates, durations, and a complete dependency network. A chart based only on Parent/Child hierarchy cannot produce a defensible critical path.
Can an AI agent trigger the Azure DevOps sync through GanttFather MCP?
No. GanttFather’s MCP server has no Azure integration tools. An Owner or Admin must configure the connection, trigger pulls, review comparisons, and confirm Push in the application. After tasks are present, an authorized agent can work with the GanttFather tasks and local dependencies.
Product behavior checked: August 30, 2026.
Sources
