Azure DevOps Gantt (A-DOG) is a tool used to generate a Mermaid JS Gantt Diagram from an Azure DevOps Feature work item and its child work items.
| Turn Azure DevOps Feature | Into Gantt Diagram | Using Dependency Diagram |
|---|---|---|
 |
(w/ 1 Resource completion date is 2025-07-14) |
 |
 |
(w/ 3 Resources completion date is 2025-06-19) |
This guide assumes that you already have access to an Azure DevOps organization, project and work items and are able to create Personal Access Tokens with a Work Items (Read) scope. If you do not and would like to still use the tool, you can setup a free Azure DevOps Organization, Project and Work Items using the linked docs.
- Create a dependency hierarchy using the Azure DevOps Related Work Links, placing the dependency link type on child work items. By default the dependency link type is Tests but is configurable in the tool. If you are unsure of how to assign work item links, please see the Azure DevOps Work Item Links doc. See also the Configuration Options section Dependency Relation setting for an example.
- Create a new Personal Access Token with a Work Items (Read) scope. If you do not know how to create a Personal Access Token, please see the Azure DevOps Create a PAT doc.
- Navigate to this repository's GitHub Pages.
- If you have never visited the tool, the Control Panel will be automatically opened, enter the context details and update any default settings to fit your Azure DevOps environment.
- Click on the Generate button at the bottom of the Control Panel.
| Setting | Description |
|---|---|
| Context Settings | |
| Organization Name | Name of the Azure DevOps organization the feature to be diagramed is under. |
| Project Name | Name of the Azure DevOps organization project the feature to be diagramed is under. |
| Feature Work Item ID | Identifier of the Azure DevOps Feature work item to be diagramed. |
| User Email | Email address of the Azure DevOps user used to authenticate requests. |
| Personal Access Token | Personal Access Token generated by Azure DevOps used to authenticate requests. |
| Settings | |
| Resource Count | Number of people (resources) to be assigned to the feature. |
| Dependency Relation |
Azure DevOps work item relationship (link) type that identifies the parent work item.
Example: If we have WorkItemA and WorkItemB, and WorkItemB depends on WorkItemA to be completed first; we would expect the dependency link type of Tests to be placed on WorkItemB. |
| Section Tag Prefix |
Azure DevOps work item tag prefix that identifies the work item's domain and the section it is listed under. If no section is specified Default is assigned.
Example: A section tag prefix of Section: with a work item tag of Section:Configuration would result in the work item being listed under the Configuration section. |
| Field Settings | |
| Effort Field | Name of the work item field that contains the estimated amount of time it will take to complete it. |
| Effort Measurement |
Effort Field's unit of measurement.
Supported Units: Days, Hours, Minutes, Weeks |
| Priority Field | Name of the work item field that contains the priority of it. |
Work items are scheduled based on the dependency hierarchy and sorted by priority ascending then by effort descending. Parallel task execution is restricted by the defined Resource Count.
- Extend the gantt diagram functionality to accommodate work items that exceed their estimated effort.
- Introduce "Abstract" as an effort unit option, allowing users to define a custom ratio between days and effort (e.g. 1 day = 1.5 effort or 1:1.5).
- Enable users to integrate an Outlook calendar, allowing blockers to indicate periods where no progress will be made on assigned work items.
- Enable users to add an Azure DevOps backlog instead of a single feature, allowing for seamless navigation through backlog items and providing a clear view of their status and progression.
- Implement caching for Azure DevOps and Microsoft Graph clients to reduce unnecessary calls on each edit. Instead of in-memory caching—given the verbosity of work items and entities—utilize IndexedDB for storage.
- Enable users to modify work item history by adding a JSON payload within a ```adog``` code block in the comments. This allows adjustments for discrepancies between recorded progress and actual work—whether due to an absence, oversight or other unexpected factors.
- Allow users to maintain multiple saved configurations, including context, settings, and other preferences.
- Simulate the projected timeline by utilizing the As Of field to indicate which items should be in progress or completed based on the specified date.
- Apply a background color gradient to work items based on their state durations, visually representing their progression over time. Additionally, provide users with a toggle option to display only the current status, allowing for a clearer, more focused view when needed.
- Explore a method to integrate resource-specific blockers into the Outlook calendar, such as on-call shifts. This data will enable both timelines to accurately reflect periods where no progress can be made on assigned work items for specific resources.
- Introduce a retrospective mode displaying two stacked Gantt diagrams—one illustrating the projected timeline from the feature's start date, and the other reflecting the actual timeline as of today.
- Provide an option for automatic refresh, ensuring the diagram updates in real time as changes occur in the Azure DevOps feature.
- Add customization options for the tool’s primary color and gantt diagram colors, giving users greater control over visual styling.
The code is currently unpolished, a bit repetitive, and likely has room for optimization. However, as with most projects, my priority is to implement the majority of the To Do features first before refining the user interface or optimizing the code. Once the core functionality is complete, I'll shift focus to cleanup, refactoring, and polishing.