Blocked hydrant-mapping stories sit in Dev as if they were still moving. What should the SM/TC coach the team to do?
Select an answer to reveal the explanation.
Short Explanation
A blocked hydrant story in Dev is a stalled car still counted as traffic moving. If the blocker is invisible, nobody swarms it. Mark it so the wait is honest.
Full Explanation
Blocked hydrant, GIS, or similar stories sitting invisibly in Dev should be made explicit on the board instead of buried in an active column. A blocked item in Dev is a stalled car still counted as traffic moving. If the blocker is invisible, nobody swarms, escalates, or stops pulling more work on top of the jam.
Leaving blockers in Dev so the column looks full of productive work fails because fullness is fake progress. Deleting blocked stories until the GIS vendor replies fails because deleting work destroys transparency and history. Moving blocked items to Done with a comment so flow time looks short fails because falsified Done metrics corrupt flow data and citizen forecasts.
Exam caveat: blocked is a first-class visible state or flag, not a comment people must hunt for. Operational check: mark blockers explicitly, age them visibly, escalate vendor or dependency delays, protect WIP by not starting more of the same, and clear or re-plan blocked hydrant work with honest status. Explicit blockers shorten citizen-facing outages by making dependency aging impossible to ignore in daily sync. Explicit blockers shorten citizen-facing outages by making dependency aging impossible to ignore in daily sync.