A blocker mentioned in a standup is not yet a blocker someone can resolve. “Waiting on access” leaves the next reader to work out which access, who can help, and when to check again. A small blocker log closes that gap without turning the meeting into a troubleshooting session.
This guide offers a working convention for engineering teams, not a product feature or a guarantee of faster delivery. Use it alongside your existing issue tracker rather than creating a competing source of truth.
Separate blockers, risks, and ordinary work
Use blocker for a condition that prevents a specific next step now. Use risk for something that could prevent progress later. Ordinary work still needs doing, but does not belong in the blocker log simply because it is unfinished.
For example, “write the integration test” is work. “The integration test cannot run because the test account is disabled” is a blocker. “The test account expires next week” is a risk. These examples are illustrative; use your own team’s language consistently.
Seven fields that make a blocker actionable
1. Blocked outcome: name the task or milestone that cannot move. Link the relevant issue or document so the record does not become another disconnected description.
2. Blocking condition: state the observable obstacle. Prefer “staging returns access denied for the service account” to “platform is broken.” Separate what was observed from a suspected cause.
3. Impact: explain what cannot happen until the obstacle changes. If delivery impact is unknown, write “impact not assessed” rather than inventing a deadline or severity.
4. Next-action owner: identify the person who has accepted the next coordination step. This may be the person asking another team for help, not whoever will ultimately fix the dependency. Use “owner unconfirmed” when nobody has accepted it.
5. Next action: record a concrete request or check. “Ask the platform contact to confirm the required role” is clearer than “follow up.” Keep the action small enough that completion can be verified.
6. Next review: record an agreed check-in time or review event. A review time is not a promised resolution date. If nobody has agreed a time, leave it explicitly unconfirmed.
7. Resolution evidence: describe what would show the blocked work can resume. A message saying “fixed” may help, but the blocked owner should still confirm the relevant operation works.
Worked example: an unavailable test account
Illustrative example: a developer cannot run a release smoke test because a staging service account lacks access. The blocked outcome is release validation, not the entire release by assumption. Record “validation cannot start; release impact not assessed” until the team checks the plan.
An agreed next action could be: “The validation owner will send the failing request and required operation to the platform contact.” If nobody has accepted that action, the log should say so. Resolution evidence could be a successful smoke-test run with the intended account. Do not close the record merely because somebody updated a permission setting.
Review the log without extending the standup
During the standup, identify new blockers and changes to existing ones. Capture the next action and owner, then move detailed diagnosis to a smaller follow-up. After the meeting, reconcile the record with your issue tracker rather than maintaining contradictory versions in several tools.
At the next review, ask: Did the agreed action happen? Is the outcome still blocked? Does the next step require a different decision-maker? Update the record with what is known. Repeating the same status without a new action is a reason to revisit ownership or escalation.
Escalate a decision, not just a status
An escalation should let someone decide. State the blocked outcome, confirmed impact, what has already been tried, and the decision or help needed. Offer alternatives only when they are real options. Avoid making up a resolution date to make the record look complete.
Teams can agree local escalation triggers, such as a missed review point or a dependency outside the team’s authority. There is no universal number of hours after which every blocker should escalate; the right threshold depends on the work and its consequences.
Where AI assistance fits
AI can help draft a meeting record, but extraction is not ownership. A suggested action should not become a commitment until a person confirms it. When the conversation did not establish an owner, date, or impact, preserve the gap.
Huzlr’s current AI Scrum Master private-beta page describes eligible Google Meet participation and reviewable summaries, decisions, blockers, and proposed action items. The template above is a team practice; it does not imply Huzlr provides a dedicated blocker-log feature or automatically writes these fields into your tracker.
Further reading
For the meeting itself, read our daily-standup guide. For current product behavior and limits, consult the AI Scrum Master and product pages. Recheck those pages before relying on a capability in your workflow.
AI Scrum Master: current beta capabilities
Authoritative sources and how they apply
The official Scrum Guide defines the Daily Scrum as a 15-minute event and says its structure should produce an actionable plan for the next day of work. That supports keeping the meeting focused on next steps; the seven-field blocker log here is our suggested practice, not a prescribed Scrum artifact.
Google’s SRE book chapter on Effective Troubleshooting describes forming hypotheses from observations and testing them against confirming or disconfirming evidence. This supports separating an observed obstacle from a suspected cause and checking evidence before declaring a technical blocker resolved.