Definition
Dependency
A dependency is a relationship where one piece of work cannot proceed or finish until another is done. Dependencies make the order of work matter: a blocked item must wait for its blocker to clear. Tracking them explicitly reveals the true sequence of a project and surfaces the chains that most threaten the timeline.
Key takeaways
- A dependency is a relationship where one piece of work cannot proceed or finish until another is done. Dependencies make the order of work matter: a blocked item must wait for its blocker to clear. Tracking them explicitly reveals the true sequence of a project and surfaces the chains that most threaten the timeline.
- Dependencies are what turn a pile of tasks into a sequence.
- In Planoda, issues can be linked as blocking or blocked-by, and blocked work is surfaced prominently, so dependency chains are visible and stalled items get escalated instead of silently aging.
Dependencies are what turn a pile of tasks into a sequence. An issue might depend on another within the same team (the API must exist before the UI can call it), across teams (platform work before product work), or on something external (a vendor, a legal sign-off). Each dependency is a constraint on order: the dependent work simply cannot finish until the thing it relies on does, no matter how much capacity is thrown at it.
Making dependencies explicit is the whole value. Unmodeled, they show up as mysterious stalls — an issue sits idle and no one remembers why. Linked, they become a graph the team can reason about: you can see what a delay cascades into, which chains are longest, and where to start work early to keep a critical path clear. This is the difference between discovering a blocker at the deadline and seeing it coming weeks out.
The goal is usually to reduce dependencies, not just track them. Tightly coupled work — where everything waits on everything — is fragile and slow. Teams that decouple work so pieces can progress in parallel ship more predictably, reserving explicit dependency links for the genuine sequencing constraints that remain.
In Planoda, issues can be linked as blocking or blocked-by, and blocked work is surfaced prominently, so dependency chains are visible and stalled items get escalated instead of silently aging.
Related terms
- BlockerA blocker is anything that prevents an issue from progressing until it is resolved — a dependency on unfinished work, a pending decision, a missing access, or an external delay. Marking work as blocked makes hidden stalls visible so the team can clear them deliberately, rather than letting issues quietly age in progress.
- Critical PathThe critical path is the longest chain of dependent tasks in a project — the sequence that determines the shortest possible completion time. Any delay to a task on the critical path delays the whole project; tasks off it have slack. Identifying the critical path tells a team exactly where timing is fragile and where to focus to protect the deadline.
- MilestoneA milestone is a significant checkpoint in a project — a meaningful date or deliverable that marks progress, such as a beta launch, a feature freeze, or a public release. Unlike a task, a milestone has no duration; it is a moment that signals a phase is complete, used to coordinate teams and communicate timing to stakeholders.
- Cycle TimeCycle time is how long an issue takes from the moment work actively starts on it to the moment it is done. Measured in hours or days, it captures the team's hands-on flow efficiency. Shorter, more consistent cycle times mean a more predictable system — the core flow metric Kanban teams optimize.