Excellent playbook, Steve. I appreciate you sharing it.
At my last organization, "aged work" became one of my favorite metrics, introduced later, because it exposed where blockers clustered and which parts of the system repeatedly caused delays. Our visibility platform ingested blocker data and exposed impact and comments from Jira, but using the Jira flag (we didn’t think of this at the time; rather than using labels) is a practical way to preserve that insight without relying on another platform.
The biggest takeaway for me is the explicit blocker policy. Teams knew blockers required attention, but we had not defined clear escalation paths or response expectations. That turns the signal into action. I will adopt this suggestion.
One question: when a blocked item is deprioritized and returned to the backlog, how do you preserve its full cycle-time story? I have generally favored keeping the clock running from original commitment to completion because that reflects the true elapsed cost, even when work is paused or restarted.
Thanks for the feedback Phil! Its a bit clunky in Jira defaults to do it, but for me the useful cycle time is: Time first set to an ‘in progress’ state - which to me is the signal of commitment to completion. That way if it goes backwards, the clock is still effectively running on the cycle time that matters most to the business (we decided to do it and started)
There's imho a minor hole in the answer to 'Is it a block?'.
Imagine a team saying 'Paul is on sick leave today and for the rest of the week. And he's our specialist on the topic.'
The team has - skill-wise and perhaps capacity-wise - no options left, no activity to apply.
Based on your answer, one could argue that this is a block.
Therefore, I phrase it slightly different: A work item is considered blocked, if it could not make progress towards done, even if people were available to work on it.
This is robust to the case of mere absence of someone able to pick it up (which is waiting, not blocked).
And I also intentionally avoid the 'action' framing, because a board (in creative knowledge work) models a state-space of the work and not a action-sequence of the workers (which I argue at length elsewhere).
There are also - without explicitly naming it - phrases that invite to confuse 'waiting' with 'blocked'.
Even a unplanned 'coffee break' (or escalation meeting) of 4 hours doesn't mean that the work was blocked. It was simply waiting. Nothing was blocking it from making progress.
To confuse the two would mean to mark every item nobody is actively working on in the specific moment as blocked. But they are just waiting to be worked on.
This resolves also any 'after X hours' issues. They are simply no longer needed.
Thank you for the feedback on this Bruno, i know you’ve thought a lot about this and have a ton of insight to offer. I would like to know more about the implications. Im not sure how the phrasing “If the team cannot progress the item through their own actions, the item is officially blocked.” invites conflation with waiting, or where the problem to solve actually lies. In my experience, teams go far too long trying to power through blocks and impediments without realizing there’s a systemic problem to solve, or that escalation/intervention is necessary. They also fail to capture these conditions, which means theres little information capture being done leading to a lack of realization and establishing ROI for interventions. The time box is meant to be a service level expectation check (it could be any amount of time) that allows individuals and leaders to ask “did you spend longer than X spinning your wheels?” I’ve seen great results from a timebox. It wouldn’t apply to taking a coffee break because there’s no expectation of progress in that time (though in knowledge work there typically is progress made as a byproduct)
I tried to explain that with the 'sickness' example. Obviously, it was less understandable than I thought.
Allow me to try again: The teams 'own actions' can be interpreted like this: 'We have no own actions at hand right now, therefore the item is blocked.'
But 'no own actions at hand' is also true, if a colleague is out sick or on vacation or the team is simply overloaded (aka too much WIP). They cannot do anything to move the item forward.
But I don't consider this to be a blocker. It's just 'waiting' because the work waits for workers to be available. If workers were available, the item could move. Hence it's not blocked.
Of course excessive waiting is something to tackle. But not by removing a external dependency, a shaky platform or other things caused by something from the outside.
Typically (I tend to say always), waiting and blocked work have different causes even though their effect on Cycle-Time is the same. Therefore it's even more important to keep these separate.
Coming back to my example: A illness is just random stuff that happens. There's no 'issue' to solve as such. It's part of doing the work.
A missed promise by another team is a different thing. That's a true blocker and if blocker clostering reveals that this happens often, then there's for sure something to be done about it.
Hm, damn. It became impossible to read all of your response now in the Substack App on my smartphone.
Need to send this part and then see, whether there's more to respond to.
"Typically (I tend to say always), waiting and blocked work have different causes even though their effect on Cycle-Time is the same. Therefore it's even more important to keep these separate."
I care more about the effect on cycle time than the reason. There are certainly cases that cause waiting that can't be helped, but I find in many cases they can be. If someone goes on vacation it or gets sick shouldn't negatively affect throughput and be waved off as an inconsequential anomaly because it's just waiting. That's a bus factor problem to address. I consider it a constraint to address. Semantically it may be very different, but I care more about the effect on customers than the specific definitions and criteria. I want teams to engage with blockers and see them as problems to solve, even when flow stops because someone is on vacation.
Hmm, the distinction between 'block' and 'wait' is important because it yields other actions to do something about it.
'wait' calls for better flow management (primarily team-internal). 'block' calls for action to prevent blockers in the future (primarily team-external).
I agree that teams often wait too long before flagging a work item as blocked. And valuable information is thereby lost or arrives too late.
I made rather positive experiences with my framing of 'blocked': "Irrespective of whether a worker is available, if the work could not move, it's blocked. In all other cases it's just waiting for a worker.'
The latter is always a (temporary) capacity problem. The former is always a true blocker. Different things.
If the capacity problem is perceived as severe or SLE breaches happen, and typical flow metrics don't provide enough insight, that states on the board can be (temporarily) sub-divided into 'active' and 'waiting' columns to get it - which is what you essentially need to do to track Flow Efficiency.
The trouble is - and therefore I don't recommend to do so permanently - it's a overhead for the workers and they typically resist or forget to do it properly. The data is highly questionable and may lead to wrong conclusions.
You know, I love flow efficiency as a thought model and I always advocate for 'putting the camera on the work and not the workers'. But I've never seen reliable data resulting from an attempt to track it this way.
If you have a link to that thread it would be great to read
I'm not sure I'd advise this: "states on the board can be (temporarily) sub-divided into 'active' and 'waiting' columns to get it - which is what you essentially need to do to track Flow Efficiency." because I think it's more confusing to be moving items back and forth on the board, and granular movement is such an overhead cost (and prone to mistakes that sabotage the metrics). I prefer to just track activity linked to the item, for example if a ticket hasn't had a comment or commit in a day I consider it stalled/waiting - but I also don't care much about flow efficiency aside from supplementary information for diagnostics
Yeah, it's terrible advice; and that's the problem with flow efficiency: If the team not doing activity recording (which has its own problems) already for some other reason, one needs to introduce something to be able to make that split between 'touch time' and 'waiting time'.
And that's always overhead, always a distraction, very unreliable. But IF one REALLY want's to do it, sub-columns are in most tools the least obstrusive approach.
Excellent playbook, Steve. I appreciate you sharing it.
At my last organization, "aged work" became one of my favorite metrics, introduced later, because it exposed where blockers clustered and which parts of the system repeatedly caused delays. Our visibility platform ingested blocker data and exposed impact and comments from Jira, but using the Jira flag (we didn’t think of this at the time; rather than using labels) is a practical way to preserve that insight without relying on another platform.
The biggest takeaway for me is the explicit blocker policy. Teams knew blockers required attention, but we had not defined clear escalation paths or response expectations. That turns the signal into action. I will adopt this suggestion.
One question: when a blocked item is deprioritized and returned to the backlog, how do you preserve its full cycle-time story? I have generally favored keeping the clock running from original commitment to completion because that reflects the true elapsed cost, even when work is paused or restarted.
Thanks for the post and playbook!
Thanks for the feedback Phil! Its a bit clunky in Jira defaults to do it, but for me the useful cycle time is: Time first set to an ‘in progress’ state - which to me is the signal of commitment to completion. That way if it goes backwards, the clock is still effectively running on the cycle time that matters most to the business (we decided to do it and started)
Ah yes, we would still have the first time set to in-progress in the history. 👊
Thanks Steve for the comment - really useful playbook 🙏
There's imho a minor hole in the answer to 'Is it a block?'.
Imagine a team saying 'Paul is on sick leave today and for the rest of the week. And he's our specialist on the topic.'
The team has - skill-wise and perhaps capacity-wise - no options left, no activity to apply.
Based on your answer, one could argue that this is a block.
Therefore, I phrase it slightly different: A work item is considered blocked, if it could not make progress towards done, even if people were available to work on it.
This is robust to the case of mere absence of someone able to pick it up (which is waiting, not blocked).
And I also intentionally avoid the 'action' framing, because a board (in creative knowledge work) models a state-space of the work and not a action-sequence of the workers (which I argue at length elsewhere).
There are also - without explicitly naming it - phrases that invite to confuse 'waiting' with 'blocked'.
Even a unplanned 'coffee break' (or escalation meeting) of 4 hours doesn't mean that the work was blocked. It was simply waiting. Nothing was blocking it from making progress.
To confuse the two would mean to mark every item nobody is actively working on in the specific moment as blocked. But they are just waiting to be worked on.
This resolves also any 'after X hours' issues. They are simply no longer needed.
Thank you for the feedback on this Bruno, i know you’ve thought a lot about this and have a ton of insight to offer. I would like to know more about the implications. Im not sure how the phrasing “If the team cannot progress the item through their own actions, the item is officially blocked.” invites conflation with waiting, or where the problem to solve actually lies. In my experience, teams go far too long trying to power through blocks and impediments without realizing there’s a systemic problem to solve, or that escalation/intervention is necessary. They also fail to capture these conditions, which means theres little information capture being done leading to a lack of realization and establishing ROI for interventions. The time box is meant to be a service level expectation check (it could be any amount of time) that allows individuals and leaders to ask “did you spend longer than X spinning your wheels?” I’ve seen great results from a timebox. It wouldn’t apply to taking a coffee break because there’s no expectation of progress in that time (though in knowledge work there typically is progress made as a byproduct)
I tried to explain that with the 'sickness' example. Obviously, it was less understandable than I thought.
Allow me to try again: The teams 'own actions' can be interpreted like this: 'We have no own actions at hand right now, therefore the item is blocked.'
But 'no own actions at hand' is also true, if a colleague is out sick or on vacation or the team is simply overloaded (aka too much WIP). They cannot do anything to move the item forward.
But I don't consider this to be a blocker. It's just 'waiting' because the work waits for workers to be available. If workers were available, the item could move. Hence it's not blocked.
Of course excessive waiting is something to tackle. But not by removing a external dependency, a shaky platform or other things caused by something from the outside.
Typically (I tend to say always), waiting and blocked work have different causes even though their effect on Cycle-Time is the same. Therefore it's even more important to keep these separate.
Coming back to my example: A illness is just random stuff that happens. There's no 'issue' to solve as such. It's part of doing the work.
A missed promise by another team is a different thing. That's a true blocker and if blocker clostering reveals that this happens often, then there's for sure something to be done about it.
Hm, damn. It became impossible to read all of your response now in the Substack App on my smartphone.
Need to send this part and then see, whether there's more to respond to.
"Typically (I tend to say always), waiting and blocked work have different causes even though their effect on Cycle-Time is the same. Therefore it's even more important to keep these separate."
I care more about the effect on cycle time than the reason. There are certainly cases that cause waiting that can't be helped, but I find in many cases they can be. If someone goes on vacation it or gets sick shouldn't negatively affect throughput and be waved off as an inconsequential anomaly because it's just waiting. That's a bus factor problem to address. I consider it a constraint to address. Semantically it may be very different, but I care more about the effect on customers than the specific definitions and criteria. I want teams to engage with blockers and see them as problems to solve, even when flow stops because someone is on vacation.
Hmm, the distinction between 'block' and 'wait' is important because it yields other actions to do something about it.
'wait' calls for better flow management (primarily team-internal). 'block' calls for action to prevent blockers in the future (primarily team-external).
Sure, and it can be picked apart during blocker clustering if the team really wants to get that specific, right?
I agree that teams often wait too long before flagging a work item as blocked. And valuable information is thereby lost or arrives too late.
I made rather positive experiences with my framing of 'blocked': "Irrespective of whether a worker is available, if the work could not move, it's blocked. In all other cases it's just waiting for a worker.'
The latter is always a (temporary) capacity problem. The former is always a true blocker. Different things.
If the capacity problem is perceived as severe or SLE breaches happen, and typical flow metrics don't provide enough insight, that states on the board can be (temporarily) sub-divided into 'active' and 'waiting' columns to get it - which is what you essentially need to do to track Flow Efficiency.
The trouble is - and therefore I don't recommend to do so permanently - it's a overhead for the workers and they typically resist or forget to do it properly. The data is highly questionable and may lead to wrong conclusions.
You know, I love flow efficiency as a thought model and I always advocate for 'putting the camera on the work and not the workers'. But I've never seen reliable data resulting from an attempt to track it this way.
An already aged treatment of the topic is here:
https://medium.com/@__bbak/you-should-not-track-flow-efficiency-3b84691ed1de
Colleen from ProKanban shared a similar perspective on LinkedIn a while ago. And after a brief interaction, we agreed to agree.
If you have a link to that thread it would be great to read
I'm not sure I'd advise this: "states on the board can be (temporarily) sub-divided into 'active' and 'waiting' columns to get it - which is what you essentially need to do to track Flow Efficiency." because I think it's more confusing to be moving items back and forth on the board, and granular movement is such an overhead cost (and prone to mistakes that sabotage the metrics). I prefer to just track activity linked to the item, for example if a ticket hasn't had a comment or commit in a day I consider it stalled/waiting - but I also don't care much about flow efficiency aside from supplementary information for diagnostics
Sure, here we go: https://www.linkedin.com/posts/colleen-johnson_why-i-love-to-hate-flow-efficiency-activity-7296136114002702336-lod4
Yeah, it's terrible advice; and that's the problem with flow efficiency: If the team not doing activity recording (which has its own problems) already for some other reason, one needs to introduce something to be able to make that split between 'touch time' and 'waiting time'.
And that's always overhead, always a distraction, very unreliable. But IF one REALLY want's to do it, sub-columns are in most tools the least obstrusive approach.