In my Kanban team we generally work on tickets that flow through the system in a matter of days however we also have 2 guys who work on tickets which are often dependent on external teams.

  1. How does one typically handle tickets on the Kanban board which are 'waiting' for something externally? They are technically blocked, but the block is being actively worked on by someone externally? Should they simply stay there until they unblocked.

  2. Should our WIP limit be adjusted to allow for tickets they take longer i.e. so we assume that there might be tickets which stay in progress for longer then others.

  3. Should tickets only move forward in Kanban

3 Answers 3


You could split the ticket in two. Lets say you have to deploy an application and that means you have to request access. Granting you access can take an amount of time unknown to you.

You could split that into "Requesting access" and "Installing Application" where the second ticket cannot even start before the access is granted. The point is that you have one ticket with a requirement and one ticket that can freely flow. Once you requested access, that ticket is done. The request email is written, nothing more to do. No ticket has to linger in this started-but-not-finished state and block Wip limits.

It's not great, but it works.


If tickets are frequently blocked by external teams, I'd focus on preventing those things from being blocked. Prior to starting work on the items, try to identify things that are needed from external teams and reduce the number of items that your team starts without those dependencies being in place or highly likely to be ready before they are required. If your team and the external team have SLEs, you may be able to forecast how long it would likely take to have dependencies finished and how long it will take before that dependency would block work.

If it's not a frequent occurrence, I'd add a "blocked" swimlane. I'd still want to do everything reasonable to reduce the number of times that this swimlane is used, but if something did get blocked, I'd move it to the swimlane and not count it as WIP. Once it becomes unblocked, it would move out of the swimlane and back to being in progress. As an alternative to the swimlane, your tools may offer other alternatives - labels, color-coding, flags. I'd still count the time as "blocked" toward cycle time and aging measures. I'd also consider putting a limit on the number of "blocked" items.


My understanding is that blocked items should be treated as any other items currently inside your workflow. Your workflow has an entry point and a exit point and you need to keep things flowing between these points and it's best if the rate of output is on average the same as the rate of input. In other words, you should not start new work unless you finish old work first.

So, on that idea, when something gets blocked you have to focus your efforts on getting it unblocked because it otherwise gets stuck into your system and no longer flows. You can't - without an analysis - just dump it in some "Blocked" area and take on new work because now your inputs will be larger than your outputs. More work enters your process than it leaves. Things need to exit at the same rate than how they entered, on average, and not accumulate within your process.

That's ideally though. In real life you might not have control over things. If something gets blocked and you can't do anything about it because it's some external entity that needs to handle it, then you need to do something with the blocked item because you can't just have it sitting there.

With proper WIP limits you might afford to keep one or two blocked items in your workflow but that will reduce throughput as new work can't be started when new capacity is available because of the WIP limits. So what's the knee-jerk reaction now? You increase WIP limits because you actually have capacity and want to reflect that, and you want to take on new work while something is blocked. It makes sense. But what if you do not have anything blocked in your system at some point? Your WIP limit now is above your capacity because you work on everything instead of just on some items while waiting for others to be unblocked by somebody else. So increasing WIP limits might solve the context of blocked things inside the system but it increases work in progress in normal working situations, thus reducing throughput (as Little's law shows).

So I would now mess with the WIP limits. I would keep the blocked tickets in the board to visualize things (which is the other main principle of Kanban, besides limiting WIP) and reason about them and experiment with things:

  • Maybe there is one or two things blocked at some point and I can live with that.
  • Or maybe I see that things start to pile up and don't exit the system as fast as I want them to, at which point maybe I might consider changing my pull policies. Seems from your example that the blockage is caused by external dependencies only. In that case maybe I add a new step in my workflow to analyze things for dependencies and I decide not to pull them if the dependencies are not resolved first. Obviously this is again the ideal case. In real situations maybe I still need to prioritize this potentially blocker over other work.
  • Then perhaps I could split the work in two parts, one is the dependency and one is work I can do without depending on others. Move my half through the system now and deal with the other half when the dependency is resolved.

So it's a matter of trade-offs basically, but trade-offs that I think should be decided based on information gathered from monitoring your flow efficiency and not by trying to apriori think of something to deal with blockages.

As for your last point, you can move things back in Kanban, that's not forbidden. If it's a good idea though is another matter. Going back to the examples I mentioned previously, maybe it's OK to move things back for blocked stuff, but on the other hand maybe it would be better not to pull that kind of work into your work in progress in the first place. So that's an inspection point in itself, which might trigger another trade-off decision.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.