A board can look active while risk is quietly accumulating. Work may remain technically unblocked but receive no attention, wait for a scarce specialist, bounce between reviewers, or sit behind a dependency. Aging work in progress exposes these conditions before an item becomes a missed commitment. Blocker clustering then helps the organization see which causes repeat often enough to deserve a system-level response.
Aging and blocking answer different questions
| Signal | Question | Useful response |
|---|---|---|
| Current age | How long has this item been active? | Compare it with similar completed work |
| Age by workflow state | Where has the item spent its current time? | Inspect the policy, queue, or dependency at that state |
| Formal blocker | What currently prevents progress? | Assign resolution ownership and record the cause |
| Recurring blocker cluster | Which cause repeatedly damages flow? | Change capacity, policy, sequencing, architecture, or supplier arrangements |
| Lead-time distribution | What does normal and exceptional completion look like? | Set context-aware review thresholds |
An item does not need a red blocked marker to be at risk. If comparable items usually finish within a particular range and an active item is approaching the slow tail, it deserves a conversation. The purpose is not to predict an exact completion date from age alone. It is to focus attention where the system is behaving unusually.
Build an ageing view in five steps
- Define a consistent start point. Use the moment work enters the committed delivery system, not the date someone first mentioned the idea.
- Group comparable work. Separate work-item types or service classes when they follow materially different paths.
- Plot the completion distribution. Percentile bands or a scatterplot provide more context than one average.
- Overlay active items by age and workflow state. Highlight items approaching or exceeding meaningful historical bands.
- Review the oldest items first, but ask about system conditions rather than demanding individual explanations.
Run an ageing conversation without blame
- What has this item been waiting for during the last several days?
- Is the work larger or less understood than the items used for comparison?
- Did an expedite or priority change displace it?
- Does the workflow policy make ownership unclear at this state?
- Would splitting, swarming, changing sequence, or escalating a dependency reduce risk?
- What should the system learn so the same delay is less likely next time?
Turn blocker records into clusters
A blocker log becomes valuable when the categories lead to action. Avoid categories such as ‘waiting’ or ‘dependency’ that merely rename the symptom. Record the blocked period, affected work type, responsible service, and enough context to distinguish causes. Review the categories periodically and merge or split them when they no longer support decisions.
| Weak category | More decision-useful cluster | Possible system response |
|---|---|---|
| Waiting for approval | Security approval begins after development | Move the trigger earlier or define a risk-based fast path |
| Dependency | Shared data service has one release window | Coordinate replenishment, expose capacity, or decouple technically |
| Requirements | Acceptance evidence missing for regulatory work | Add an entry policy for this work-item type |
| Environment | Performance environment is shared and oversubscribed | Reserve capacity, change sequencing, or invest in another environment |
| Priority change | Expedites repeatedly displace standard work | Review expedite criteria and capacity policy |
Choose the level of response
Resolve the individual item when the cause is exceptional. Change a team policy when the pattern is local and within the team’s authority. Use a Service Delivery Review when a repeated pattern affects service outcomes. Escalate to an Operations or Risk Review when several connected services share the constraint or when the decision requires broader authority.
A four-week improvement experiment
- Week 1: establish the ageing view and improve blocker categories without setting targets.
- Week 2: review the oldest work and identify the two most consequential blocker clusters.
- Week 3: change one explicit policy or coordination mechanism and state the expected signal.
- Week 4: compare active age, blocked time, and service outcomes; continue, adapt, or stop the change.
Avoid turning the metrics into targets
If people are rewarded for reporting fewer blockers, blockers disappear from the data while delays remain. If an ageing threshold becomes a promise, teams may split or reclassify work only to stay green. Use the measures to ask better questions about the system. Pair speed with quality, customer outcomes, and the cost of interruption.
Continue the learning path
The Kanban Method guide explains flow, WIP, policies, and evolutionary change. The 30-day Kanban System Design plan helps teams establish a usable system before optimizing it. Kanban University’s current KSI overview explicitly includes delays, variability, bottlenecks, lead time, run charts, and cumulative flow diagrams as improvement topics.
Use Kanban System Design training when the service and its policies are still unclear. Use the KSI-after-KSD guide and Kanban Systems Improvement training when the need is to improve, scale, and manage an operating system with evidence.
