/
Blocker management

Blocker management

1. Introduction

In this platform, a Blocker is a first-class citizen. Unlike a simple Jira comment, a Blocker has its own lifecycle, severity, and resolution path, ensuring that impediments are never "lost in the noise."

2. Raising a Blocker

During your daily standup, if you indicate you are blocked, you must provide:

  1. Description: A short summary of the "stop-block."

  2. Severity Level:

    • 🔴 Critical: Entire sprint goal is at risk; no workaround.

    • 🟠 High: Major task is stopped; workaround is difficult.

    • 🟡 Medium: Progress is slowed; workaround exists.

    • 🔵 Low: Minor annoyance; not impacting immediate delivery.

  3. Linked Issue: (Optional) Link the specific Jira ticket that is being held up.

3. The Blocker Lifecycle

Open

When a blocker is submitted, it appears on the Facilitator Dashboard with a timestamp. It remains "Open" until a Facilitator intervenes.

Resolved

A Facilitator marks a blocker as resolved after providing a Resolution Note. This note is saved in the KVS for future retrospective analysis.

  • Example: "Resolved by granting DB access to the developer."

2026-01-16_09-58-33-20260116-043106.png

4. Facilitator Responsibilities

Facilitators use the Raised Blockers Table to:

  • Filter by Severity: Tackle Critical items first.

  • Identify Bottlenecks: See if multiple team members are blocked by the same issue (e.g., "Environment Down").

  • Track Resolution Time: Monitor how long it takes to move a blocker from Open to Resolved.

5. Impact on Retro Analytics

Blockers are the primary input for the Risk Signal.

  • High Frequency of Blockers = 🔴 Red Risk Level.

  • High Resolution Time = 🟡 Flow Bottleneck.

  • Unlinked Blockers = ⚪ Governance Warning (encouraging users to link Jira issues).