Task Dependencies Management | Prevent Blockers
Identify and track task dependencies to prevent blockers. GitScrum links blocked-by relationships, shows dependency chains, and surfaces blockers in standups.
8 min read
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
| Type | Example | Risk Level |
|---|---|---|
| Technical | API needed before frontend | High |
| Team | Design from another team | Medium |
| External | Third-party integration | High |
| Resource | Waiting for access/tools | Medium |
| Knowledge | Waiting for requirements | Medium |
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
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