How can a team make blocked work visible without another status meeting?
Quick answer
Create a shared board for work that cannot move forward without an action or decision from someone else. For each blocker, show the work item, the obstacle, the specific input needed, who can help, and when to check again. Keep routine progress updates in their usual place, and let teammates respond directly on the board so visibility leads to action rather than another meeting.
The question, the details, the next step.
How do we show blocked work clearly without turning this into another progress report or meeting?
Give blocked work its own small shared view, separate from routine updates. The point is not to narrate everything people have done; it is to show where progress depends on an input, decision, access, or action that has not arrived.
Use one row or card per blocker, with these fields:
- Work item and owner.
- What is blocked, in plain language.
- What is needed to unblock it, stated as a specific question or action.
- Who can provide that input or help.
- When the team will check again.
- Current state: needs help, response underway, or unblocked.
Keep the board somewhere the team already checks. A teammate should be able to understand the request and respond without waiting for a scheduled meeting. If nothing is blocked, show that there are no active blockers rather than filling the board with routine progress.
What makes a useful blocker entry, instead of just saying a task is delayed?
Describe the dependency and the next requested action. “Delayed” tells people the outcome, but not what they can do. “Cannot finalize the launch checklist until the product owner confirms which of the two proposed dates to use” makes the dependency and decision visible.
For example, suppose a team member cannot finish a draft because a reviewer has not chosen between two wording options. A useful entry might read:
“Draft: onboarding guide | Blocked: final wording depends on a choice between option A and option B | Needed: reviewer selects one option or suggests a third | Help from: [reviewer role or name] | Next check: [date] | State: needs help.”
Use role labels or names according to the team’s normal working practice. Avoid vague requests such as “please advise” and long task histories. If the needed action changes, edit the entry so it stays useful.
How can people use the board without creating a daily reporting chore?
Make updating the board part of the moment someone identifies a dependency, rather than a separate daily report. The person closest to the work adds the card and names the next action; the person who can help responds on the card or contacts the owner directly. When the dependency is resolved, mark it unblocked and remove or archive it according to the team’s normal board habits.
For a small team, agree on a simple check-in rule: people scan the board during a shared work-planning moment they already have, and only items needing a decision or intervention get attention. A board entry is an invitation to act, not proof that somebody has failed. If an item sits without a response, the owner can follow the team’s agreed escalation route rather than waiting for a status meeting.
Keep routine progress—such as “drafting continues”—in the usual task tracker or update channel. Put something on the blocker board only when a dependency prevents the next meaningful step.
Can you give me a board outline we can copy and adapt?
Start with this lightweight outline and adjust the labels to match your team’s tools:
Blocked-work board
- Work item:
- Owner:
- Blocked because:
- Needed next (one concrete action or decision):
- Help requested from:
- Next check date:
- State: Needs help / Response underway / Unblocked
- Last update:
Example entry
- Work item: [report section]
- Owner: [person or role]
- Blocked because: [one source or decision is missing]
- Needed next: [confirm which of two approaches to use]
- Help requested from: [reviewer role or name]
- Next check date: [date]
- State: Needs help
- Last update: [brief note]
The bracketed details are placeholders. Keep the board focused on requests someone can answer or act on; it does not need to replace your task tracker. Agree who closes an item and what to do if a request stays unanswered, so the board supports follow-through rather than becoming another place to report.
A practical checklist
Create one shared view specifically for work blocked by a dependency.
State the obstacle and the next action needed.
Name who can provide the input or decision, using team-appropriate labels.
Set a next-check date and a simple state for each active blocker.
Agree how owners follow up and when resolved items leave the active view.
A few more useful answers
Should every unfinished task appear on the blocked-work board?
No. Include work only when a dependency prevents the next meaningful step. Ordinary ongoing progress belongs in the team’s normal task or update system.
What if the person who can unblock the work is not known?
State what input is missing and mark the helper as unidentified or to be assigned. The next action can be finding the appropriate decision-maker, rather than leaving the blocker as a vague delay.
When should an item be removed from the active board?
Once the dependency is resolved, mark it unblocked and archive or remove it according to the team’s agreed practice. Keep the active view centered on requests that still need action.