Task dependencies

Project Manager records the task’s work package, assignee, start and due dates, estimate and predecessor references. A dependency explains why another piece of work must finish before this task can begin. Keep that relationship specific enough for the baseline check and for the person deciding what to work on next.

Task status shows the current working situation. Backlog, In Progress, In Review, Blocked and Done help Developer and QA Engineer coordinate the handoff. The dependency still matters when a task looks ready on a board: a predecessor that has not delivered its required outcome can make the planned start unrealistic.

• Task identity. Use stable task keys and the correct work-package reference. The predecessor text must resolve to the intended task rather than a similarly named item from another package or project.
• Date feasibility. Compare predecessor due dates with successor start dates when preparing the task graph. The baseline workflow checks circular relationships, missing references and impossible finish-to-start dates before accepting the schedule.
• Working handoff. Developer updates progress and raises a block when the next action cannot proceed. QA Engineer inspects work in review, and Project Manager uses that outcome when assessing the remaining package schedule.

Agree the exact notation used for predecessor references and how the scheduling page resolves it. Decide how staff handle more than one predecessor, date boundaries and a dependency outside the immediate package. Use the same convention in imports and manual edits so the graph sent for baseline checking represents the intended work.

Choose when assignees update estimates, actual hours and percent complete. A progress percentage does not explain an unresolved predecessor by itself. Decide how the task description or issue evidence records the reason for a block so another person can continue the investigation without guessing from a board column.

Use task A for design, task B for implementation and task C for verification. B depends on A, and C depends on B. Project Manager gives B a start before A can finish. Submit the graph and inspect the rejected baseline result, then correct the dates before preparing another check.

Next, make A depend on C and confirm that the circular chain is rejected. Replace that reference with a task key that does not exist and confirm that the missing predecessor is identified. Finish with a feasible chain, assign the work and move B to Blocked when its required input is unavailable. Record the relevant issue key in the task description so the team can locate the project issue explaining that interruption.

• Tasks In Flight — Tasks in progress or review with dates, assignee, estimates and predecessor references.
• Task Board by Status — Task work grouped by its current status for the delivery handoff.
• Blocked Tasks — Blocked work with its owner, due date and dependency context.

Continue with Plan and authorize a schedule for graph checking and Triage and verify issues when a dependency cannot be satisfied.