Dependencies and Blockers
Work rarely happens in isolation. One task needs another to finish first. One story can't ship until a third-party integration is ready. One bug can't be fixed until a refactor is done. Dependencies make these relationships explicit — so your team knows what's blocked, what's blocking, and what to do about it.
What Are Dependencies?
A dependency is a relationship between two work items that indicates one cannot proceed until the other is resolved.
Lifecycle supports two directions:
| Relationship | Meaning |
|---|---|
| Blocks | This item must be completed before the linked item can proceed. |
| Blocked by | This item cannot proceed until the linked item is completed. |
These are two sides of the same relationship. If Task A blocks Task B, then Task B is blocked by Task A. Adding either direction creates the link in both places.
Adding Dependencies
- Open the item's detail panel (click the item title)
- Scroll to the Dependencies section
- Click Add dependency
- Search for the item by title or key (e.g.,
KEY-123) - Choose the relationship type: Blocks or Blocked by
- Click Add
The dependency appears in both items' detail panels — the blocker shows "Blocks KEY-456" and the blocked item shows "Blocked by KEY-123".
Tip: Use dependencies to make blockers visible to the whole team. When someone sees an item is blocked, they know to prioritize resolving the blocker first — without any status meeting or Slack thread to figure out why something isn't moving.
Viewing Dependencies
In the Detail Panel
The Dependencies section in an item's detail panel shows:
- Blocking: items this item is preventing from progressing
- Blocked by: items that must be resolved before this item can proceed
Each linked item shows its title, key, status, and a quick link to open it.
In Table Views
A Blocked indicator appears on items that have unresolved blockers. This is visible in table rows so you can spot blocked work without opening every item.
The "Dependency Block" Status
When a task or story has an unresolved dependency, move it to Dependency Block status. This tells the team immediately — in the status field — that the item is waiting on something specific.
Using Dependency Block status instead of (or alongside) the dependency link communicates:
- This item is actively blocked right now
- It's not "On Hold" by choice — it literally cannot proceed
- Someone should look at the blocker
Move the item out of Dependency Block status when the blocking item is resolved.
Tip: Combine the Dependency Block status with an actual dependency link. The status creates visibility in list views; the dependency link shows what it's blocked by and lets the team navigate directly to the blocker.
Removing Dependencies
To remove a dependency:
- Open the detail panel of either item in the relationship
- Find the dependency in the Dependencies section
- Click the remove button (trash icon or X) next to the linked item
The relationship is removed from both items.
Cross-Board Dependencies
Feature Requests Linked to R&D Stories
Feature requests can be linked to R&D stories to track which customer requests are being addressed by which engineering work. This is not a blocking dependency — it's a tracking link.
When a feature request is linked to an R&D story:
- The feature request shows the linked story's status and progress
- Completing the R&D story can trigger customer notifications via the Customer Portal
- The PM can see which customer requests are covered by current engineering work
Linking Feature Requests to Stories
- Open the feature request's detail panel
- Find the Linked Story field
- Search for and select the R&D story
- The link is created in both directions
Customer Notifications via Linked Items
When a Feature Request is linked to an R&D story and the story is marked Done, Lifecycle can automatically notify the customers who submitted the request. This closes the loop with customers without manual follow-up.
Configure customer notifications in Board Settings → Notifications.
Dependency Best Practices
Be specific. Link to the exact blocking item, not a vague category. "Blocked by API authentication story" is more useful than a comment saying "waiting on backend."
Keep blockers fresh. If a blocking item is resolved but the dependent item is still showing Dependency Block status, update it. Stale blocked statuses erode trust in the system.
Don't over-use dependencies. Not every relationship needs a formal dependency link. Use them for genuine blockers — items that truly cannot proceed. For looser relationships ("it would be nice to have this done first"), a comment is enough.
Review blocked items in standups. A daily or weekly scan of items in Dependency Block status is a useful standup ritual. If something has been blocked for three days, the team should know why.