Dependency-aware sprint planning

Overview

Dependency-aware sprint planning means building the sprint around what actually blocks what — not a priority-sorted queue. Most sprint tools assume work is independent: pick stories, estimate points, commit to velocity. Real launches do not work that way. Frontend waits on backend API contracts, QA waits on both, and design handoffs sit between parallel eng tracks.

Ravel plans sprints on a dependency graph. Parallel departments (eng, design, QA, ops) run together; edges show merge points and stall risks. When one track slips, you see which downstream tasks are now at risk — before Thursday standup turns into thirty minutes of "wait, is that actually done?"

Traditional sprints vs dependency-aware planning

Planning steps

A dependency-aware sprint starts from outcome, not tickets. You describe what must ship, confirm how your teams are organized, then let Ravel propose structure you can edit before anyone executes.

1. Define the sprint outcome in natural language — launch, milestone, release, or migration with deadline and scope constraints.
2. Confirm department structure and leads (Frontend, Backend, QA, Design, etc.) so work splits across the right owners.
3. Ravel proposes tasks, dependency edges, and completion rules across parallel tracks — review and edit on the graph.
4. Identify the critical path: the longest chain of dependent work that determines whether the sprint outcome lands on time.
5. Assign owners, set completion rules (GitHub for code tasks, upload/link/manual for non-code), and confirm the plan.
6. Ravel emails each department lead their assigned tasks; execution begins on the graph with auto-unlock as blockers clear.

Critical path before standup

The critical path is the longest sequence of dependent tasks from start to sprint outcome. Delays on this chain slip the launch; work off the critical path may have float — parallel tracks can progress without immediately threatening the deadline.

In a flat sprint backlog, critical path is inferred verbally each standup. On Ravel's graph, you read it from dependency chains across departments. If Backend API is on the critical path and slips two days, you immediately see which Frontend and QA tasks are now at risk — not after three Slack threads.

Parallel departments

Departments are multi-team structure at plan time. Frontend, backend, and QA can run in parallel with explicit handoff dependencies — so QA does not start before the API contract is merged, and design does not block eng with an implicit "we'll figure it out in standup."

Each department has a lead and task owners. When the sprint plan is confirmed, Ravel distributes assignments by email — each lead receives the work their team owns, with dependency and due-date context. Parallel tracks stay visible on one graph instead of scattered across team-specific boards.

Running the sprint on the graph

1. Owners work unblocked tasks — no incomplete upstream dependencies.
2. GitHub-backed tasks advance when merged code matches task scope; non-code tasks complete via upload, link, or manual confirm.
3. Upstream completion unlocks downstream tasks automatically; owners receive email when work is ready to start.
4. Leads review the graph for stall risks, parallel progress, and critical-path slips — standup focuses on decisions, not status archaeology.
5. Delay and risk emails surface problems before the sprint review becomes a post-mortem.