Dependency graph project management
Model parallel work, blockers, and critical path on a DAG — not a sorted backlog.
Overview
Real engineering work runs in parallel with real blockers. Frontend, backend, and QA do not take turns in a priority queue — they overlap, hand off, and wait on each other. A dependency graph (directed acyclic graph, or DAG) models that reality: tasks are nodes, dependencies are edges, and the shape of the graph shows what can run now, what is blocked, and where the critical path lies.
Ravel treats the graph as the product model — not a board view layered on top of tickets. When upstream work completes, downstream tasks unlock automatically and owners are notified by email. You spend less time in standup inferring blockers and more time on work that is actually unblocked.
Why a graph, not a backlog
Flat backlogs sort work by priority and hope dependencies stay in everyone's head. That breaks down quickly on multi-team launches: QA starts before the API is ready, design handoffs get lost, and the "critical path" only surfaces when the deadline is already at risk.
A DAG makes structure explicit. Parallel tracks stay visible. Blockers propagate downstream so you see ripple effects before they become fire drills. For dev-first teams shipping across eng, design, and QA, the graph is the plan — not a diagram you maintain separately from execution.
DAG vs linear backlog
| Linear backlog | Dependency graph |
|---|---|
| Sorted by priority | Ordered by real upstream/downstream relationships |
| Manual unblock rituals in standup | Auto-unlock when upstream tasks complete |
| Parallel work hidden in one list | Parallel departments visible on the same graph |
| Critical path inferred verbally | Critical path readable from dependency chains |
| Status columns updated by hand | Completion signals (GitHub, upload, manual) drive state |
| Blocker impact unclear | Dependents stay blocked until upstream work ships |
What the graph shows
| Concept | In Ravel |
|---|---|
| Task node | A unit of work with owner, department, due date, and completion rule |
| Dependency edge | Downstream task cannot start until upstream task completes |
| Parallel tracks | Tasks with no shared blocker can run at the same time |
| Critical path | The longest chain of dependent work — delays here slip the launch |
| Blocked state | Task has incomplete upstream dependencies; owner waits for unlock email |
| Unblocked state | All upstream deps complete; owner can start and receives notification |
Departments add a second dimension: Frontend and Backend can progress in parallel while QA integration testing waits on both. The graph shows merge points — where parallel work must converge before the next phase begins.
Auto-unlock and owner notifications
When a task completes — via merged PR, uploaded deliverable, confirmed link, or manual sign-off — Ravel evaluates the graph and unlocks every downstream task whose dependencies are now satisfied. Owners receive email when work unlocks, completes, slips, or hits risk.
- Upstream task completes (e.g. Auth API merged on GitHub).
- Ravel marks the task done on the graph and evaluates dependents.
- Downstream tasks with all deps satisfied move from blocked to unblocked.
- Newly unblocked owners get an email — no manual status sweep required.
- If a blocker slips, dependents stay blocked; you see exactly which tasks are at risk.
Executing on the graph
- Confirm the plan graph after AI decomposition or manual edits — dependencies and owners are set before execution starts.
- Each owner works on tasks that are unblocked (no incomplete upstream dependencies).
- Completion signals mark tasks done: GitHub merge for code, upload/link/manual for non-code work.
- Dependents unlock automatically; owners receive email as the graph advances.
- Leads review the live graph for critical path, parallel progress, and stall risks — not a static Gantt export.
Reading the graph day to day
During execution, the graph answers questions a backlog cannot:
- What can start today? — Unblocked tasks with satisfied upstream dependencies.
- What is blocking the launch? — Follow the critical path to the longest open chain.
- Which team is waiting on whom? — Trace edges across departments (e.g. QA blocked on Backend API).
- If Backend slips two days, what moves? — See all downstream dependents in one view.
Departments and cross-team handoffs
Departments label which team owns each node. Cross-functional launches become readable: design hands off to frontend, frontend depends on backend API, QA depends on both. Handoffs are edges, not assumptions in a sprint doc.
This pairs naturally with AI decomposition — Ravel proposes departments and dependency edges from your project description, then the same graph drives execution and unlock logic after confirm.
FAQ
Does Ravel replace Gantt charts?
The graph shows dependencies, parallel tracks, and critical path live — without maintaining a separate timeline artifact that goes stale after the first slip.
What happens when a blocker slips?
Downstream tasks stay blocked. You see exactly which dependents are at risk and which owners are waiting — not just a delayed priority score on a flat list.
How is this different from issue links in Jira?
Issue links decorate a flat board. Ravel's graph is the execution model — with live unlock logic, email notifications, and GitHub-backed completion for code tasks.
Can I edit dependencies after the plan is confirmed?
Yes. You can adjust edges, add tasks, and reassign owners on the graph. Unlock rules always reflect current upstream completion state.
What team size fits a dependency graph?
From solo builders to roughly twenty-person engineering teams shipping in parallel across roles. Larger orgs benefit most when multiple departments have real handoff dependencies.