The link was there from the start. During PI planning someone opened the mobile checkout story, clicked Link work item, chose “relates to” and typed the key of the identity team’s token-refresh story. It felt like a courtesy, not a gate. The team voted four fingers for 20 November and went back to work.
In week four the checkout story reached code review and stopped. It could not ship without the new token flow, and the token-refresh story was still in To Do, in another team’s Fix Version, behind two higher priorities. The link had not changed. It still said “relates to.” It still said nothing about the date.
What Jira issue links are
Jira issue links are directional relationships between two work items. Each link type has an outward and an inward description. Jira ships with four by default: Blocks (blocks / is blocked by), Relates (relates to), Duplicate (duplicates / is duplicated by) and Cloners (clones / is cloned by). Admins can add more. To link across projects you need Browse Projects permission in both and Link Issues permission in at least one. Jira Cloud now calls issues “work items,” so the button reads Link work item, but the mechanism is the same.
Choosing a link type is expert engineering judgment. “Is blocked by” says the team knows this work cannot start until that work is done. “Relates to” says the team sees a connection but does not expect it to gate anything. Those choices are part of the evidence the team weighs when it casts its confidence vote.
A link records the relationship. Not its cost.
The trouble starts after the vote. A link is a fact about two work items. It carries no date, no age and no number of days. Four things happen to links that the link itself never shows.
Links arrive late. The gate nobody saw at planning gets linked in week three, when a developer hits it. The link is accurate. It is also the first time anyone has looked at what it does to the release.
“Relates to” turns out to be a gate. The soft connection chosen on planning day becomes a hard one when the work gets real. Someone may change the link type. Often nobody does, and the board keeps showing a courtesy where there is now a wall.
Blockers age in someone else’s backlog. The blocking item lives in another team’s Fix Version, ranked by that team’s priorities. Every day it sits in To Do, the link looks exactly the same.
Nobody reads the links as a set. Each link is visible on one work item. The chain of them across a release, and which chain is setting the date, is not visible from any single issue view.
That is a dependency surfacing too late, the second of the three things that erode a committed release date. The other two travel with it: the blocked team picks up unplanned work to stay busy, which is scope, and the one person who could unblock the token flow is out that week, which is capacity.
Keep the links. Read what they do to the date.
The answer is not more link types or a stricter linking policy. It is reading the links where a forecast can see them.
- Link the actual work items in the Fix Version, and mark each dependency link hard (the work cannot start until the blocker is done) or soft (a sequencing preference).
- Reclassify a soft link as hard the moment its owner confirms it is a real gate. Do not wait for the retro.
- For a gate with no Jira work item, such as a vendor deliverable, create a placeholder work item with the promised date and an owner, and hard-link it to the work it gates.
- Record the committed date with the confidence level the team voted at.
- At every sprint boundary or cross-team sync, read the gap in days between the committed date and the forecast at that confidence, and look at which links are dictating the date.
An illustration, not customer data. A release is committed for 20 November at 85% confidence. At the vote the 85% forecast sits at 17 November: three days of margin. In week four the “relates to” link between checkout and token refresh is reclassified as hard, and the token-refresh story, still in the identity team’s Fix Version, lands on the release’s critical path. No issues were added. The 85% forecast is now 26 November, six days past the commitment. The 50% forecast is 19 November, so the release reads amber (attention), not yet red.
Now the cross-team sync has a decision with a number on it. Ask the identity team to pull the token story forward? Ship checkout behind a flag on the old flow? Renegotiate the date while there is still margin to trade? Every option is the teams’ call. What changes is that the call happens in week four, with both teams in the room, not at the release demo.
Where Advanced Release Planning fits
Advanced Release Planning for Jira reads the dependency map from Jira issue links. It does not import or store a separate diagram. Links between the work items in the Fix Version are treated as hard (the dependent item cannot start until the blocker is done, and a hard link on the critical path delays the committed date) or soft (recorded, but it does not drive the path). A blocker in another Fix Version appears in the release’s Critical Path view as a cross-release context node instead of staying invisible until a status meeting. Circular links are detected, flagged and excluded from the path. Items on or near the critical path are ranked by risk in a heatmap. A hard link added or reclassified in Jira enters the analysis the next time the dependency-aware Monte Carlo forecast runs against live Jira state. The app does not attribute a number of days to an individual link; it reports the committed date, today’s forecast at 50%, 85% and 95%, and the gap in days. The team sets the assumptions: which throughput window, whose capacity, what is in scope, which links are gates. The app does the arithmetic at Monte Carlo scale and keeps it live. Green at or above P85, amber between P50 and P85, red below P50.
For the session that produces most of these links, see why dependency mapping draws the map once. For the categories a link stands in for, see how project dependencies get typed at planning. For exactly what the app reads from each link, see the dependency-aware planning reference doc.
Key takeaways
- Jira issue links record which work item blocks, relates to, duplicates or clones another. Choosing the type is engineering judgment and part of the evidence behind the confidence vote.
- A link carries no date, age or cost. Late links, soft links that become gates, and blockers aging in another team’s Fix Version all move the committed date while the link looks the same.
- Mark dependency links hard or soft, reclassify the moment a gate is confirmed, and hard-link a dated placeholder for gates outside Jira.
- Read the gap in days between the committed date and the forecast at the committed confidence at every sprint boundary.
FAQ
What are the default Jira issue link types?
Blocks (blocks / is blocked by), Relates (relates to), Duplicate (duplicates / is duplicated by) and Cloners (clones / is cloned by). Jira admins can add custom link types.
How do I query linked issues in Jira?
Use the JQL function linkedIssues(), for example issue in linkedIssues("PAY-142", "is blocked by"). It returns the work items linked to PAY-142, optionally filtered by link description.
Do Jira issue links affect the release date?
Not in Jira itself. A link stores the relationship, not a date or duration. To see the effect, read the links in a dependency-aware forecast and compare it with the committed date at the confidence level the team voted at.
Keep your links. Add the number they are missing. See the committed date and its live confidence band in Advanced Release Planning, or start a free trial on the Atlassian Marketplace.
Leave a Reply
Your email is safe with us.