Plan
Dependencies and auto-scheduling
A dependency is a Jira issue link, so it is visible on the issue and in every other Jira tool. YTI Gantt adds what Jira links cannot hold: the type and the lag.
Draw a dependency
Hover a bar: a dot appears at its right end. Drag from the dot to the bar of the issue that must wait for it and let go. The app creates a Jira link, by default Blocks ("A blocks B": A comes first), and draws an arrow.
Which Jira link types count as dependencies, and which side comes first, is set by a Jira admin in the settings. Existing links of those types appear as arrows the first time you open the chart.
Type and lag
Click an arrow to open it. You can change its type and lag, or delete it.
| Type | Means | Example |
|---|---|---|
| Finish → Start | B starts after A finishes (the default) | Testing after the build |
| Start → Start | B starts when A starts, or later | Documentation alongside development |
| Finish → Finish | B finishes when A finishes, or later | Review ends with the writing |
| Start → Finish | B finishes when A starts, or later | The old system runs until the new one starts |
Lag is a number of working days added to the rule: +2 on finish-to-start leaves two working days between the two issues; −1 lets the second start a day before the first ends. Type and lag are stored by the app; the Jira link itself stays a plain link.
To delete a dependency, open it and choose Delete dependency, or select it and press Delete. This removes the Jira link. Undo (or Ctrl+Z) creates it again with the same type and lag, as a link of the first dependency type in the settings.
Dependencies on epics and parents
A dependency to or from a parent (an epic, or a story with subtasks) applies to every scheduled issue under it, the way project tools treat summary tasks: "Payments starts after Checkout" makes every Payments issue wait for the last Checkout issue.
Auto-scheduling
With Auto-schedule on, when an issue moves later or gets longer, every issue that depends on it is pushed just far enough to respect its dependencies, and so on down the chain. The same happens when you add a dependency or change its type or lag.
- Issues are only ever pushed later, never pulled earlier, so slack you planned on purpose is kept.
- The issue you moved stays where you put it.
- All the moved issues are saved to Jira together and one Undo puts them all back.
Turn Auto-schedule off to move issues without touching others. The setting is part of a saved view.
On the issue
Every issue has a Gantt schedule item in its details panel. It shows the issue's dates, what must happen first and what waits for it, each with its type, lag and dates, and warns when the dates break a dependency ("2 working days too early"). Changes are made on the chart.
Broken dependencies
An issue that starts earlier than one of its dependencies allows gets a dashed orange outline, and its arrow turns orange. Plan health lists each with how many working days it is too early, a Move it button, and Move them all to fix every one in one step. Dependencies that are not plain finish-to-start carry a small label at their arrow, for example SS +2d.
Links to issues outside the plan
When the other issue is not in the chart (another project, or filtered out), the link is counted next to the summary (↗) but not drawn or used for scheduling. Widen the filter to include both issues.