What This Template Is For
Blocked items are the silent killer of sprint commitments. A task sits in "In Progress" for three days before someone mentions in standup that they are waiting on an API key, a design decision, or access to a staging environment. By then the sprint goal is at risk and the team scrambles to recover.
This template gives your team a single place to log blockers, assign owners, track resolution timelines, and escalate when needed. It works alongside a Kanban board or sprint board as a dedicated view for items that cannot move forward. The Product Operations Handbook covers the broader topic of building processes that keep delivery flowing smoothly.
For teams running Scrum, blockers surface during daily standups. For Kanban teams, they appear as aging items on the board. Either way, you need a structured approach to resolve them before they compound.
When to Use This Template
- During daily standups: Log any new blocker immediately with an owner and expected resolution date.
- Sprint planning: Review open blockers before committing to new work. A sprint with unresolved blockers from last cycle is already behind.
- Retrospectives: Analyze blocker patterns. If the same category of blocker keeps recurring, the root cause is systemic.
- Escalation meetings: When a blocker has been open longer than 48 hours, escalate with the data from this tracker.
Step-by-Step Instructions
Step 1: Log the Blocker (2 minutes)
When a team member identifies a blocked item, capture it immediately. Do not wait for the next standup.
- ☐ Identify which work item (story, task, or bug) is blocked
- ☐ Describe the blocker in one sentence: what is preventing progress
- ☐ Categorize the blocker type (dependency, decision, access, technical, external)
- ☐ Assign a resolution owner (not the person who is blocked, but the person who can unblock)
Step 2: Set Resolution Timeline (5 minutes)
Every blocker needs a target resolution date. Without one, blockers sit open indefinitely.
- ☐ Estimate how long resolution should take (hours, days)
- ☐ Set a target resolution date
- ☐ Define the escalation trigger: if unresolved by [date], escalate to [person]
- ☐ Identify any interim workarounds the team can use while waiting
Step 3: Track and Resolve (Ongoing)
Review blockers daily and update status.
- ☐ Update blocker status in daily standup
- ☐ Escalate any blocker past its target date
- ☐ Document the resolution when the blocker is cleared
- ☐ Tag the root cause for retrospective analysis
Step 4: Retrospective Analysis (End of Sprint)
Use the blocker log to identify patterns during your sprint retrospective.
- ☐ Count total blockers this sprint
- ☐ Calculate average time-to-resolution
- ☐ Identify the most common blocker categories
- ☐ Propose one systemic fix for the top recurring blocker type
The Blocked Items Tracker Template
Sprint/Period: [Sprint number or date range]
Team: [Team name]
Last Updated: [Date]
Active Blockers
| ID | Blocked Item | Blocker Description | Type | Raised | Owner | Target Date | Escalation |
|---|---|---|---|---|---|---|---|
| B-001 | [Story/task name] | [What is preventing progress] | [Dependency / Decision / Access / Technical / External] | [Date] | [Name] | [Date] | [Name if escalated] |
| B-002 | [Story/task name] | [What is preventing progress] | [Type] | [Date] | [Name] | [Date] | |
| B-003 | [Story/task name] | [What is preventing progress] | [Type] | [Date] | [Name] | [Date] |
Blocker Type Definitions
| Type | Description | Typical Owner | Example |
|---|---|---|---|
| Dependency | Waiting on another team or service | Tech lead or PM | API endpoint not yet built by Platform team |
| Decision | Waiting on a product or business decision | PM or stakeholder | Pricing model for new feature not finalized |
| Access | Waiting on credentials, permissions, or environments | Engineering manager | Staging environment access for new hire |
| Technical | Blocked by a technical constraint or unknown | Senior engineer | Third-party API returning unexpected errors |
| External | Waiting on a vendor, partner, or customer | PM or account manager | Vendor has not delivered SDK documentation |
Resolved Blockers (This Sprint)
| ID | Blocked Item | Blocker Description | Type | Days Open | Resolution |
|---|---|---|---|---|---|
| B-000 | [Story/task name] | [What was blocking] | [Type] | [X days] | [How it was resolved] |
Sprint Blocker Summary
| Metric | Value |
|---|---|
| Total blockers raised | [X] |
| Currently active | [X] |
| Resolved this sprint | [X] |
| Average days to resolve | [X.X] |
| Most common type | [Type] |
| Blockers escalated | [X] |
Example
Sprint: Sprint 14 | Team: Payments | Last Updated: Mar 5, 2026
Active Blockers
| ID | Blocked Item | Blocker Description | Type | Raised | Owner | Target Date | Escalation |
|---|---|---|---|---|---|---|---|
| B-003 | Stripe webhook handler | Stripe sandbox returning 500 errors intermittently | External | Mar 3 | Raj | Mar 6 | Escalate to Stripe support if no fix by Mar 6 |
| B-004 | User role migration | Product has not decided on admin vs. editor permission model | Decision | Mar 4 | Sarah (PM) | Mar 5 | VP Product if not decided by EOD |
Resolved Blockers
| ID | Blocked Item | Blocker Description | Type | Days Open | Resolution |
|---|---|---|---|---|---|
| B-001 | Invoice PDF generation | Missing access to S3 bucket in production | Access | 1 day | DevOps granted access within 4 hours of escalation |
| B-002 | Payment retry logic | Needed clarification on retry intervals from architecture team | Dependency | 2 days | Architecture team provided retry spec document |
Sprint Blocker Summary
| Metric | Value |
|---|---|
| Total blockers raised | 4 |
| Currently active | 2 |
| Resolved this sprint | 2 |
| Average days to resolve | 1.5 |
| Most common type | Dependency / Access |
| Blockers escalated | 1 |
Tips
- Log blockers the moment they appear. Waiting until standup adds hours or days of delay. Use a Slack channel, Jira flag, or Linear label to surface blockers in real time. The tracker is the system of record, but speed matters more than process.
- Assign an owner who can actually resolve it. The resolution owner should be the person with the authority or access to fix the problem. If the PM needs to make a decision, the PM owns the blocker. If an external team needs to deliver something, the tech lead who has the relationship owns the escalation.
- Set aggressive target dates. Most blockers should resolve within 24-48 hours. If a blocker is expected to take a week, that is a planning failure, not a blocker. Either descope the blocked work, find a workaround, or escalate immediately.
- Track root causes, not just symptoms. "Waiting on API" is a symptom. "Platform team has no SLA for internal API requests" is the root cause. Tag root causes so you can fix systemic issues in retrospectives. The Product Operations Handbook covers building cross-team SLAs.
- Review blockers during retrospectives. Count them, categorize them, and identify the top recurring type. Then commit to one systemic fix. If "access requests" block the team every sprint, automate provisioning. If "decisions" are the top blocker, schedule a weekly decision review with stakeholders.