Issue Dependencies
Track blocking relationships between issues and pull requests to improve project visibility and prevent delays.
Dependencies represent relationships where one piece of work must be completed before another can begin. Tracking these relationships gives teams visibility into task connections, helps identify bottlenecks before they impact deadlines, and prevents planning decisions that could delay releases.
Understanding dependency relationships
Zenhub supports 2 types of dependencies for GitHub issues and pull requests:
Type | What it means | Example |
|---|---|---|
Blocked by | Current issue cannot proceed until another is completed | Issue #45 blocked by Issue #23 (waiting on API endpoint) |
Blocking | Current issue must be completed before others can proceed | Issue #23 blocking Issue #45 (API must be ready first) |
These relationships work bidirectionally. When you mark Issue A as blocked by Issue B, Issue B automatically shows as blocking Issue A — no duplicate data entry needed.
Creating dependencies
Navigate to any GitHub issue or pull request and find the Dependencies section beneath the description and comments.
Click Blocked by or Blocking (use the dropdown to switch between types)
Type the issue title or number in the search field
Select the appropriate issue from the results
Cross-repository dependencies
Dependencies work across repositories within your workspace. You can create blocking relationships between issues in different repositories, providing visibility into cross-team work that spans multiple codebases.
External dependencies
Mark dependencies as External when they represent work outside your GitHub repositories. This provides visibility into third-party blockers or external team commitments that impact your timeline.
Removing dependencies
Click Remove on the right side of any dependency in the list. This removes the connection from both issues involved. All additions and removals are logged in the issue history.
Tracking dependency status
Dependencies update automatically based on issue status changes. The dependency section shows one of 3 states: all blockers resolved and issue isn't blocking other work; blocked by active issues that prevent progress; or currently blocking other work from proceeding. Each blocking issue displays its current status with a direct link for easy navigation. Once blocking issues are closed, the dependency list updates automatically.
Dependencies on the Work Tracker
Issue cards show visual indicators for dependency status. A blocked icon appears when an issue is waiting on other work. A blocking icon appears when an issue is preventing other work from proceeding. Both icons appear when an issue has both types of relationships. You can toggle these icons on or off through the board filtering options without affecting what your teammates see.
Dependencies and sprint planning
Review dependency relationships during sprint planning to identify risks and optimize work sequencing. Issues with many blockers may not be suitable for the current sprint, while blocking issues should be prioritized to unblock downstream work. When blocking issues are scheduled for later sprints, adjust capacity planning accordingly — blocked issues may not contribute to velocity until their blockers are resolved.
FAQ
Q: Can I create dependencies on issues I don't have access to?
A: You can only create dependencies on issues within repositories you have access to. Zenhub respects GitHub's permission model for dependency creation.
Q: Do dependencies affect velocity or burndown calculations?
A: No. Dependencies don't directly impact reporting metrics, but they provide context for understanding why work may be delayed or why sprint goals weren't met.
Q: Can I automate actions based on dependency status?
A: Zenhub doesn't include automated workflows triggered by dependency status changes. Dependencies are primarily for visibility and manual coordination.
Q: Do dependencies work across multiple workspaces?
A: Dependencies work across repositories within your current workspace. Issues must be in repositories connected to the same workspace to establish dependency relationships.