8 min read • Guide 863 of 877
Tracking Dependencies and Blockers: Platform Guide for Development Teams
Dependencies and blockers are the hidden killers of development velocity. Without proper tracking, teams waste hours on blocked work while dependencies silently delay critical deliveries. The right platform turns invisible blockers into visible, actionable items that the whole team can address.
Platform Features for Tracking
| Feature | Purpose | GitScrum Implementation |
|---|---|---|
| Blocker Flag | Mark tasks as blocked | Checkbox with user/timestamp tracking |
| Task Relationships | Link dependent work | Parent tasks, subtasks, user stories |
| Labels | Categorize blockers | Custom labels (blocked-by-X) |
| Kanban Visualization | See blocked work | Columns with WIP limits |
| Notifications | Alert when blocked | Slack, Discord, Teams integration |
Blocker Tracking Workflow
IDENTIFYING AND RESOLVING BLOCKERS
══════════════════════════════════
STEP 1: FLAG THE BLOCKER
─────────────────────────────────────
Developer encounters issue:
├── Open task in GitScrum
├── Check "Blocked" checkbox
├── System records:
│ ├── Who: John Developer
│ ├── When: Jan 30, 2026 10:15 AM
│ └── Task: API endpoint implementation
└── Visual indicator appears on Kanban
STEP 2: CATEGORIZE THE BLOCKER
─────────────────────────────────────
Add label to classify:
├── blocked-by-design
├── blocked-by-api
├── blocked-by-review
├── blocked-by-env
├── blocked-by-external
└── blocked-by-decision
This enables:
├── Filtering all blocked tasks
├── Identifying patterns
└── Assigning to right resolver
STEP 3: NOTIFY STAKEHOLDERS
─────────────────────────────────────
Integrations alert the team:
├── Slack: #dev-blockers channel
├── Discord: @team mention
├── Teams: Posted to channel
└── Email: Automatic digest
STEP 4: RESOLVE AND UNBLOCK
─────────────────────────────────────
Once resolved:
├── Uncheck "Blocked" checkbox
├── Add comment with resolution
├── Task returns to normal flow
└── History preserved for retrospectives
Dependency Visualization
DEPENDENCY TYPES IN PROJECTS
════════════════════════════
TASK DEPENDENCIES:
─────────────────────────────────────
┌─────────────────────────────────────────────────┐
│ User Story: Payment Integration │
├─────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Design API │───►│ Implement │ │
│ │ Contract │ │ Endpoints │ │
│ └──────────────┘ └──────┬───────┘ │
│ │ │
│ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Frontend │◄───│ Integration │ │
│ │ Components │ │ Tests │ │
│ └──────────────┘ └──────────────┘ │
│ │
└─────────────────────────────────────────────────┘
CROSS-TEAM DEPENDENCIES:
─────────────────────────────────────
Team A (Frontend) Team B (Backend)
┌─────────────┐ ┌─────────────┐
│ UI Build │ ◄──WAIT── │ API Ready │
│ [BLOCKED] │ │ [In Progress│
└─────────────┘ └─────────────┘
EXTERNAL DEPENDENCIES:
─────────────────────────────────────
Your Project External
┌─────────────┐ ┌─────────────┐
│ Integration │ ◄──WAIT── │ Third-party │
│ [BLOCKED] │ │ API Access │
└─────────────┘ └─────────────┘
Kanban Board for Blockers
KANBAN VISUALIZATION OF BLOCKED WORK
════════════════════════════════════
┌──────────┬────────────┬────────────┬──────────┐
│ BACKLOG │ IN PROGRESS│ BLOCKED │ DONE │
│ │ WIP: 5 │ │ │
├──────────┼────────────┼────────────┼──────────┤
│ │ │ │ │
│ [Task 6] │ [Task 1] │ [Task 3] │ [Task A] │
│ [Task 7] │ [Task 2] │ 🚫 API │ [Task B] │
│ [Task 8] │ [Task 4] │ │ [Task C] │
│ │ [Task 5] │ [Task 9] │ │
│ │ │ 🚫 Design │ │
│ │ │ │ │
└──────────┴────────────┴────────────┴──────────┘
BLOCKER COLUMN BENEFITS:
─────────────────────────────────────
├── Visible: Everyone sees blocked work
├── Separate: Doesn't count against WIP
├── Actionable: Clear resolution needed
└── Measurable: Track time in blocked state
ALTERNATIVE: BLOCKER SWIM LANE
─────────────────────────────────────
┌──────────────────────────────────────────────┐
│ BLOCKED TASKS │
│ [Task 3: Waiting for API] [Task 9: Design] │
├──────────────────────────────────────────────┤
│ NORMAL FLOW │
│ Backlog → In Progress → Review → Done │
└──────────────────────────────────────────────┘
Label System for Dependencies
ORGANIZING DEPENDENCIES WITH LABELS
═══════════════════════════════════
BLOCKER LABELS:
─────────────────────────────────────
Label Color Description
─────────────────────────────────────
blocked-by-design 🟣 Purple Waiting for design
blocked-by-api 🔵 Blue External API issue
blocked-by-review 🟡 Yellow Code review pending
blocked-by-env 🟤 Brown Environment problem
blocked-by-decision 🔴 Red Needs stakeholder input
blocked-by-external ⚫ Gray Third-party dependency
PRIORITY LABELS:
─────────────────────────────────────
Label Color Description
─────────────────────────────────────
urgent-blocker 🔴 Red Blocks release
high-priority-blocker 🟠 Orange Blocks sprint goal
normal-blocker 🟡 Yellow Standard blocked work
USING LABELS FOR TRACKING:
─────────────────────────────────────
1. Filter Kanban by label:
→ See all "blocked-by-api" tasks
→ Assign API team to resolve
2. Reports by label:
→ "20% of blockers are design-related"
→ Action: Add designer to sprint planning
3. Cross-project view:
→ All blocked tasks across workspace
→ Identify systemic issues
GitScrum Implementation
SETTING UP BLOCKER TRACKING
═══════════════════════════
STEP 1: CREATE BLOCKER LABELS
─────────────────────────────────────
Workspace Settings → Labels
├── Create: blocked-by-design
├── Create: blocked-by-api
├── Create: blocked-by-review
├── Create: blocked-by-env
└── Set colors for visibility
STEP 2: CONFIGURE KANBAN BOARD
─────────────────────────────────────
Project Settings → Board
├── Add column: "Blocked"
├── Set WIP limit: No limit
├── Position: After "In Progress"
└── Color: Red background
STEP 3: ENABLE NOTIFICATIONS
─────────────────────────────────────
Project Settings → Integrations
├── Connect Slack/Discord/Teams
├── Configure webhook triggers:
│ ├── Task blocked → Notify #blockers
│ ├── Task unblocked → Notify owner
│ └── Daily digest → Summary to team
└── Test integration
STEP 4: USE BLOCKER FLAG
─────────────────────────────────────
On any task:
├── Open task detail
├── Check "Blocked" checkbox
├── Add blocker label
├── Add comment explaining issue
└── Move to Blocked column
STEP 5: TRACK IN STANDUPS
─────────────────────────────────────
Team Standup → Blockers section
├── Team members report blockers
├── Visible in standup summary
├── Actions assigned for resolution
└── Follow-up in next standup
Common Blocker Patterns
IDENTIFYING SYSTEMIC ISSUES
═══════════════════════════
PATTERN: FREQUENT DESIGN BLOCKERS
─────────────────────────────────────
Symptom: 30% of tasks blocked by design
Cause: Design not ahead of development
Solution:
├── Design sprint runs 1 week ahead
├── Design review before sprint planning
└── Designer embedded in dev team
PATTERN: API DEPENDENCY DELAYS
─────────────────────────────────────
Symptom: Backend delays block frontend
Cause: Sequential development
Solution:
├── Contract-first API design
├── Mock APIs for frontend development
└── Daily cross-team sync
PATTERN: CODE REVIEW BOTTLENECK
─────────────────────────────────────
Symptom: Tasks stuck "In Review"
Cause: Too few reviewers, no SLA
Solution:
├── Define review SLA (e.g., 4 hours)
├── Rotate reviewers
└── Pair programming to reduce reviews
PATTERN: EXTERNAL DEPENDENCY WAIT
─────────────────────────────────────
Symptom: Tasks blocked by third-parties
Cause: No fallback, no buffer
Solution:
├── Build with mock services first
├── Add buffer time for integration
└── Escalation path for delays
Metrics and Reporting
MEASURING BLOCKER IMPACT
════════════════════════
KEY METRICS:
─────────────────────────────────────
Metric Target Alert
─────────────────────────────────────
Blocked Task Count < 3 > 5
Avg Time Blocked < 1 day > 2 days
Blocker Resolution < 4 hours > 8 hours
% Tasks Ever Blocked < 10% > 20%
GITSCRUM REPORTS:
─────────────────────────────────────
Workspace → Reports
├── Project Age Analysis
│ → Shows tasks stuck in columns
│ → Highlights blocked work duration
├── Sprint KPIs
│ → Velocity impact from blockers
│ → Completion rate with blockers
└── Cumulative Flow Diagram
→ Visual bottlenecks
→ Blocked work accumulation
RETROSPECTIVE DATA:
─────────────────────────────────────
Track over sprints:
├── Most common blocker categories
├── Average resolution time
├── Team/project with most blockers
└── Improvement trend over time
Best Practices
- Flag immediately - Don't wait; mark blocked as soon as discovered
- Categorize blockers - Use labels to identify patterns
- Daily blocker review - Address in standups, don't let them age
- Notify stakeholders - Integrate with Slack/Teams for visibility
- Track resolution time - Measure how long blockers persist
- Review in retrospectives - Identify systemic issues
- Separate blocked column - Make blocked work visible on Kanban
- Assign owners - Every blocker needs someone responsible for resolution