You’ve probably heard that a blocked column on a board is a bad practice and most of the time that’s true. Let’s see why it’s usually bad and when it might actually be ok.
The way most teams implement a blocked column (or a blocked status) is that “blocked” is a fixed place on the board that cards move in and out of as they become blocked / unblocked. Because it’s a fixed place, we end up moving the card forward and then backward as it becomes blocked / unblocked. Moving cards backwards is problematic for reasons we’ve described before.
The positioning of an item on the board gives us information about it. Items higher in a column should be older and therefore more important than items lower in that same column. Items to the right, should also be older than items to the left. When we move a card to a dedicated blocked column, we lose all that information. We want to find a way to highlight the blocked items without changing their position.
Per-column WIP limits is a very common practice (although not actually required by Kanban). If your team is using these then having a blocked column will cause disruption here. How do you control how many items are blocked at any given time?
We absolutely should have some kind of a visual indicator to show that a card is blocked. On a physical board, we might put something on top to draw attention to it. If you’re using Jira, then we recommend setting the flag on the issue. That will change the background color of that ticket and make it visually different without moving it’s position on the board.
The argument for not having a blocked column is pretty clear. When might it be ok?
It’s ok to have a blocked column if two conditions are true:
- It’s blocked on a very specific reason such as “governance approval”.
- That blockage is a regular part of the workflow that happens at a known time.
For example, we might have columns such as
- Ready
- In dev
- Blocked for governance approval
- Deploy
- Done
In this scenario, governance approval happens at the same time in the workflow, between development and deploy. It’s a normal part of the workflow and we know that we will always be blocked here. The very fact that we’ve entered this column shows that we are now blocked until that approval happens and that there’s nothing that anyone in the team can do until its finished. If the team were able to approve themselves then by definition, they wouldn’t be blocked.
I worked with a team where every second column was one of these dedicated blocked columns. All the even columns were things in the control of the team and all the odd columns were things outside of their control and where they were blocked until another group did their part. This is a reasonable use of a blocked column.
In conclusion, if the “blocking” can happen at almost any point then a blocked column is inappropriate. Find a different way to highlight those tickets. However, if it’s a clear part of the workflow and we’re blocked on a specific known thing then maybe a blocked column is ok.