Task Dependencies Management

Dependencies are the hidden rocks in project waters. Ignore them, and work crashes to a halt when blocked. Manage them well, and work flows smoothly with parallel progress. This guide covers identifying, tracking, and resolving dependencies before they become blockers.

Dependency Types

Identifying Dependencies

During Planning

DEPENDENCY IDENTIFICATION
═════════════════════════

IN SPRINT PLANNING:
─────────────────────────────────────
For each story, ask:

"What must exist before this can start?"
├── APIs, endpoints, services
├── Designs, specs
├── Environment, access
├── Data, content
└── Document answers

"Who needs to provide something?"
├── Other teams
├── External vendors
├── Stakeholders (decisions)
├── Subject matter experts
└── Clarify timeline and owner

"What could block this?"
├── Technical unknowns
├── Approval gates
├── Resource availability
├── External factors
└── Plan mitigations

DOCUMENT DEPENDENCIES:
─────────────────────────────────────
Task: Frontend profile page
Dependencies:
├── User API endpoint (Team Backend, Day 3)
├── Profile design (Design team, Done)
├── Avatar upload service (Blocked on S3 setup)
└── Track in GitScrum

Dependency Mapping

VISUAL DEPENDENCY MAP
═════════════════════

CREATE DEPENDENCY DIAGRAM:
─────────────────────────────────────
┌──────────────────────────────────────────────────────┐
│                                                      │
│    [User API]      [Avatar Service]                  │
│        │                │                            │
│        ▼                ▼                            │
│    [Frontend] ←──── [Design]                         │
│        │                                             │
│        ▼                                             │
│    [Integration Tests]                               │
│        │                                             │
│        ▼                                             │
│    [Deploy to Staging]                               │
│                                                      │
└──────────────────────────────────────────────────────┘

CRITICAL PATH:
─────────────────────────────────────
The longest chain of dependencies
determines minimum project duration.

In above:
User API → Frontend → Tests → Deploy
(This is the critical path)

Avatar can parallel with Frontend.
Design must finish before Frontend starts.

IDENTIFY:
├── What's on critical path? (Can't slip)
├── What can parallel? (Opportunity)
├── What has most dependents? (Risk)
└── Focus attention accordingly

Tracking Dependencies

In GitScrum

GITSCRUM DEPENDENCY TRACKING
════════════════════════════

LINKING TASKS:
─────────────────────────────────────
Task → Links → Add Dependency

Types:
├── Blocked by: This task waits on linked task
├── Blocks: This task must finish for linked to start
├── Related: Just associated (no dependency)
└── Parent/child: Hierarchy

EXAMPLE:
─────────────────────────────────────
Task: Frontend Profile Page
├── Blocked by: GS-100 (User API endpoint)
├── Blocked by: GS-101 (Profile design)
└── Blocks: GS-120 (Integration tests)

STATUS VISIBILITY:
─────────────────────────────────────
When dependency incomplete:
├── Indicator shows on blocked task
├── Can filter "Blocked" tasks
├── Dashboard shows blocker count
└── Standup surfaces blockers

DEPENDENCY VIEW:
─────────────────────────────────────
Project → Dependencies

┌─────────────────────────────────────────────────────────┐
│  Dependency Chain                                      │
├─────────────────────────────────────────────────────────┤
│                                                         │
│  GS-100 User API        ▓▓▓▓▓▓▓░░░ In Progress        │
│     ↓                                                   │
│  GS-105 Profile Page    ░░░░░░░░░░ Blocked             │
│     ↓                                                   │
│  GS-120 Integration     ░░░░░░░░░░ Waiting             │
│                                                         │
│  ⚠️ GS-100 delay affects 2 downstream tasks           │
│                                                         │
└─────────────────────────────────────────────────────────┘

Managing Dependencies

Proactive Management

PROACTIVE DEPENDENCY HANDLING
═════════════════════════════

START DEPENDENCIES EARLY:
─────────────────────────────────────
If A depends on B:
├── Start B as early as possible
├── Buffer time between B finish and A start
├── Track B progress actively
└── Escalate early if B slipping

COMMUNICATE ACTIVELY:
─────────────────────────────────────
To dependent team:
"We need the User API by Day 5.
Our frontend work starts then.
Any concerns about that timeline?
How can we help?"

Not:
"Where's the API?" (on Day 5)

DAILY STANDUP:
─────────────────────────────────────
"What's blocking you?"
├── Surface dependencies daily
├── Immediate visibility
├── Action same day
└── Don't let blockers linger

DEPENDENCY REVIEW:
─────────────────────────────────────
Weekly in sprint:
├── Review all open dependencies
├── Status of each
├── ETA still valid?
├── Risk level updated?
└── Action items assigned

When Blocked

HANDLING BLOCKERS
═════════════════

WHEN BLOCKED:
─────────────────────────────────────
Step 1: CONFIRM IT'S REALLY BLOCKED
├── Can you work around it?
├── Can you mock/stub temporarily?
├── Can you work on another task?
└── Only truly blocked = blocker

Step 2: COMMUNICATE IMMEDIATELY
├── Tell the blocking party
├── Make visible in standup
├── Update task status
├── @mention relevant people

Step 3: ESCALATE IF NEEDED
├── If blocker isn't moving
├── Go to PM/lead
├── Involve management if cross-team
└── Don't wait until deadline

Step 4: FIND WORKAROUNDS
├── Can we mock the API?
├── Can we use sample data?
├── Can we skip this for now?
├── Can we parallelize differently?
└── Keep making progress if possible

WORKAROUND EXAMPLES:
─────────────────────────────────────
Waiting for API:
├── Mock the API responses
├── Build frontend against mock
├── Integrate when API ready
└── Parallel development

Waiting for design:
├── Build with placeholder UI
├── Structure and logic first
├── Apply design when ready
└── Don't block completely

Waiting for decision:
├── Document assumptions
├── Build most likely option
├── Plan to adapt if different
├── Proceed with risk noted

Reducing Dependencies

Prevention Strategies

DEPENDENCY REDUCTION
════════════════════

CROSS-FUNCTIONAL TEAMS:
─────────────────────────────────────
Instead of: Frontend team, Backend team
Have: Feature teams with both skills

Result:
├── Most dependencies are internal
├── Team self-sufficient
├── No cross-team waiting
└── Faster delivery

LOOSELY COUPLED SYSTEMS:
─────────────────────────────────────
Design for independence:
├── Clear interfaces/contracts
├── Services can develop in parallel
├── Mocks enable independent testing
├── Changes don't cascade
└── Architecture reduces dependencies

CONTRACT-FIRST DEVELOPMENT:
─────────────────────────────────────
Before building:
├── Agree on API contract
├── Document endpoints, payloads
├── Both teams build to contract
├── Mock enables parallel work
└── Meet in the middle

SMALLER BATCHES:
─────────────────────────────────────
Instead of: One big feature with many dependencies
Have: Small slices with fewer dependencies

Each slice:
├── Minimal dependencies
├── Can complete independently
├── Delivers some value
├── Lower risk
└── Faster feedback

Dependency Anti-Patterns

What to Avoid

DEPENDENCY ANTI-PATTERNS
════════════════════════

HIDDEN DEPENDENCIES:
─────────────────────────────────────
Pattern: Dependencies not documented
Result:
├── Surprise blockers mid-sprint
├── No time to resolve
├── Sprint fails
Fix: Explicit identification in planning

LAST-MINUTE DISCOVERY:
─────────────────────────────────────
Pattern: "Oh, we need X!" (mid-development)
Result:
├── Work stops
├── Scramble to get X
├── Delays everything
Fix: Thorough grooming, ask "what do we need?"

SILENT BLOCKING:
─────────────────────────────────────
Pattern: Blocked but didn't tell anyone
Result:
├── Days lost
├── Late discovery
├── No time to help
Fix: Immediate communication, daily standup

OVER-DEPENDENCY:
─────────────────────────────────────
Pattern: Everything depends on everything
Result:
├── Nothing can move independently
├── Any delay cascades
├── Maximum risk
Fix: Loose coupling, independent slices

GitScrum Features

Dependency Management

GITSCRUM DEPENDENCY FEATURES
════════════════════════════

LINKING:
─────────────────────────────────────
Task detail → Links
├── Blocked by (waits for)
├── Blocks (must finish first)
├── Related (associated)
└── Visual connection

BLOCKER STATUS:
─────────────────────────────────────
Status: Blocked
├── Special status
├── Visible on board
├── Filterable
├── Dashboard widget
└── Standup highlight

DEPENDENCY DASHBOARD:
─────────────────────────────────────
├── All blocked tasks
├── Aging (how long blocked)
├── Cross-team visibility
├── Escalation alerts
└── Unblock tracking

NOTIFICATIONS:
─────────────────────────────────────
├── When dependency completed
├── When task blocked
├── Reminder if stuck
└── Keep everyone informed

Best Practices

For Dependencies

1. Identify early — In grooming and planning
2. Make visible — Track in GitScrum
3. Communicate proactively — Don't wait until blocked
4. Reduce by design — Cross-functional teams
5. Unblock fast — Blockers are top priority

Anti-Patterns

DEPENDENCY MISTAKES:
✗ Not tracking dependencies
✗ Silent blocking
✗ Last-minute discovery
✗ Everything depends on everything
✗ No escalation path
✗ Waiting passively
✗ No workarounds attempted
✗ Ignoring cross-team needs

Related Solutions

• Managing blockers and impediments
• Cross-team collaboration strategies
• Improving sprint planning accuracy