This set builds vocabulary for modeling task ordering and cross-team scheduling constraints.
0 / 5 completed
1 / 5
At standup, a dev mentions marking a task as unable to start until another specific task is completed first. What is this relationship called?
A task dependency marks that one task can't begin until another specific task is completed, encoding the real-world ordering constraint directly into the project management tool rather than relying on someone remembering the correct sequence. This makes the true critical path of a project visible to everyone. Dependencies are especially useful for coordinating work across multiple people or teams with interlocking deliverables.
2 / 5
During a design review, the team wants a visual timeline showing how tasks and their dependencies overlap and connect across a project's schedule. Which view supports this?
A timeline view, often Gantt-style, visualizes tasks along a schedule with connecting lines showing dependencies, making it easy to see at a glance how a delay in one task might cascade into others. This visual representation surfaces scheduling risk far more intuitively than a flat list of individual tasks. It's a standard feature in project management tools built to handle interdependent work.
3 / 5
In a code review, a dev notices moving a blocking task's due date automatically shifts the dates of tasks that depend on it. What does this behavior represent?
Automatic schedule cascading propagates a date change in a blocking task to the dependent tasks that rely on it, keeping the whole project's schedule internally consistent without requiring someone to manually update every affected task by hand. This automation reduces the risk of a stale, inconsistent schedule after a single task slips. It relies on dependencies being accurately defined in the first place.
4 / 5
An incident report style retro shows a project missed its deadline because a hidden dependency between two tasks owned by different teams was never explicitly recorded. What practice would prevent this?
A dependency spanning two different teams is easy to lose track of if it only exists as informal, undocumented awareness rather than being explicitly recorded in the shared project tool. Making cross-team dependencies visible in the tool itself ensures a schedule change on one side properly surfaces its impact on the other. This is a common root cause identified when a project misses a deadline due to an unanticipated blocking relationship.
5 / 5
During a PR review, a teammate asks why the team explicitly models task dependencies instead of just listing tasks in a flat, unordered backlog. What is the reasoning?
A flat, unordered backlog doesn't capture which tasks genuinely block others, leaving that critical scheduling information only in someone's head, while explicit dependencies let the tool compute and surface real ordering constraints and cascading schedule risk automatically. This structure matters most for projects with genuinely interlocking work across people or teams. Simpler, independent task lists may not need this level of modeling.