GitScrum / Docs
All Best Practices

Track Dependencies and Blockers | Platform Guide

Track task dependencies and blockers with Kanban columns, labels, and integrations. GitScrum's blocker flag and notifications enable faster issue resolution.

8 min read

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

FeaturePurposeGitScrum Implementation
Blocker FlagMark tasks as blockedCheckbox with user/timestamp tracking
Task RelationshipsLink dependent workParent tasks, subtasks, user stories
LabelsCategorize blockersCustom labels (blocked-by-X)
Kanban VisualizationSee blocked workColumns with WIP limits
NotificationsAlert when blockedSlack, 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

    • Related Solutions