On a flow board, why record why each card was blocked instead of only unblocking it?
answer
- Unblocking fixes today, not tomorrow
- Categories can be counted, anecdotes cannot
- Rank by days lost, not by irritation
- One or two causes usually dominate
- Keep the category list short and stable
basics
~20 sRecording a reason category and the blocked duration on every card turns one-off interruptions into countable data. Summed over weeks, one or two categories usually account for most of the days lost, and that category is what a policy change should target.
solid answer
~50 sUnblocking a card fixes today; recording why it was blocked is what lets a team fix the cause. The practice is small: when work stops, mark the card, tag it with a short reason category - waiting on a shared environment, waiting on an external approval, missing information from the requester, waiting on another team's change - and note when it stops and starts again. Individually these look like bad luck. Summed across two months they usually show a **Pareto shape**, where one or two categories hold most of the blocked days. That is the difference between chasing each blockage harder and changing the arrangement that keeps producing them. Keep the category list short and stable, because a taxonomy that grows a new entry for every incident can never be counted, and read the totals at the service delivery review where a policy or dependency can actually be changed.
code
pseudocode · 8 linesBLOCKED DAYS BY REASON - 8 weeks, wine-cellar inventory service
shared test environment unavailable 38 days 14 cards
waiting on an external approval 11 days 5 cards
missing detail from the requester 7 days 3 cards
waiting on another team's change 5 days 1 card
-------- --------
total 61 days 23 cardsgo deeper
Know that a stopped card should be marked as blocked and tagged with a short reason, and that the reason is recorded so the team can later count which causes cost the most time.
Explain why counting matters: individual blockages are anecdotes, category totals in days lost reveal which cause dominates, and that total is what a policy change should target.
Show you have run the tally and acted on it - the category that turned out to be expensive rather than merely irritating, the arrangement you changed, and whether the days lost actually fell afterwards.
Own the cross-boundary use: blocked-days totals are how a dependency owned by another group stops being an opinion and becomes a number they must answer for, and how you raise that without the record turning into an accusation.
## Recording the reason, not just the fact Most teams already mark blocked work somehow - a coloured marker on the card, a flag in the board tool, a note in the daily meeting. What they usually do not do is record **why**, in a form that can be counted later. The result is a team that is genuinely good at unblocking things and has no idea what keeps blocking them. The practice adds three fields to a blockage and nothing else: - **A reason category**, chosen from a short fixed list. - **The moment it started**, so blocked duration can be computed. - **The moment it cleared**, and optionally what cleared it. That is deliberately cheap. Anything more elaborate gets skipped exactly when the team is busiest, which is when blockages are most informative. ## From individual blockages to categories A single blocked card is an anecdote. Everyone remembers the worst one and nobody remembers the eleven ordinary ones, so unaided memory systematically misreports what is expensive. Categories fix this because they can be **summed**. Two different sums answer two different questions: | Sum | Question it answers | Use it for | |---|---|---| | Count of blockages by category | how often does this happen | spotting a recurring irritation | | Blocked days by category | how much time does this cost | choosing what to change first | The second is usually the one that decides. A category that occurs twice but holds work for three weeks each time costs far more than one that occurs fifteen times and clears in an hour, and only the days-lost sum shows that. ## A worked tally Across eight weeks, a team running a wine-cellar inventory service recorded 23 blockages totalling 61 blocked days. Sorted by days lost, 38 of the 61 - a little over 62% - sat in a single category: the shared test environment was unavailable. Waiting on an external approval accounted for 11 days across 5 cards, missing detail from the requester for 7 days across 3 cards, and another team's change for 5 days on one card. Before the tally, the team's own account of its problems was 'approvals take forever', because approvals were the most annoying blockages to sit through. The days-lost column said otherwise, and the change that followed was about environment access rather than about chasing approvers. ## Turning a category into a change The dominant category is an input to the same single-change discipline used everywhere else on the board: 1. Take the top category by days lost, not by count and not by irritation. 2. Ask what policy or arrangement produces it. A shared environment held by whoever grabbed it first is an arrangement; so is an approval step with no service expectation attached to it. 3. Change one thing - a booking rule for the environment, an entry criterion that says work does not start until the dependency is confirmed available, or a standing agreement with the other team. 4. Keep recording, and read the same category's totals over the next comparable period. If the days lost do not fall, the change addressed the wrong link. The blocked-days record is also what makes a dependency arguable outside the team. 'The environment is a problem' invites a debate; 'this service lost 38 working days in eight weeks waiting for it' is a number the owning group has to answer, and it belongs in the wider operations review where they are present. ## Common mistakes - **A taxonomy that grows without bound.** If every incident invents a new category, nothing can be counted. Five to eight stable categories, with a rarely used 'other' that gets reviewed, is enough. - **Recording the fact and not the duration.** Counts alone rank irritation, not cost. - **Blaming a category on a group.** The record exists to find an arrangement worth changing; the moment it reads as an accusation, people stop tagging honestly. - **Collecting for months and acting on nothing.** The record earns its keep only when a category becomes a change, and teams that log diligently while changing nothing abandon the practice within a quarter. - **Only tagging the dramatic stops.** A day lost quietly, several times a week, outweighs the memorable week-long outage - and it is exactly the kind that never gets recorded unless tagging is habitual. An interviewer asking this is checking for a specific habit of mind: that you treat interruptions as data about the system rather than as bad luck to be absorbed by whoever is nearest.
- Would you rank categories by count of blockages or by days lost?By days lost, when the goal is choosing what to change. Counts rank how often something annoys the team, which correlates poorly with cost: two blockages of three weeks each outweigh fifteen that clear within an hour. Counts are still useful as a secondary view, because a frequent short blockage may point at a policy that is easy to fix.
- How do you stop the reason categories from multiplying until they are useless?Fix a short list - roughly five to eight - and require new entries to be proposed at a review rather than invented on the card. Keep a rarely used other bucket and inspect it periodically: if it grows past a few percent of blocked days, the list genuinely needs a new category. The purpose is countability, and a taxonomy with thirty entries counts nothing.
saying these in an interview costs you the question
- Only unblocks cards, never records the reason
- Ranks causes by how annoying they felt
- Invents a fresh category for every incident
- Uses the record to assign blame to a group
- Collects blocked-time data and never changes anything