A simple Kanban board has 3 columns: To do, In progress, Done. Tasks in To Do haven’t been picked up yet; In progress shows tasks that are being worked on; Done contains the tasks that have been completed.
If you’re not careful, the “in progress” column can get overwhelming. Here are a few things to watch out for, and some tips to help keep things moving.
1. Set a WIP limit
A WIP (work in progress) limit is a way of setting a maximum number of items that you want to be in progress at the same time. How this is handled varies depending on the tool. Jira displays a red highlight if you go over the WIP limit, but it doesn’t stop you from doing it. Unfortunately, I haven’t found a way to do this in Asana.
The WIP limit is a number, which is often the same as the number of people in the team – sometimes team size plus 1. You can only do one thing at a time, right?
If the In progress column is already full, you could finish the task you’re working on, or help someone else finish theirs.
You don’t get the value from a task until it’s Done, so why not focus on completing things before pulling more into In progress?
2. Identifying blocked tasks
Sometimes a task is picked up that lacks info or starts to become more challenging than expected. If you’ve ever been asked “Any blockers?” then this is the kind of thing I’m talking about.
It’s important to identify blocked tasks on the board. I don’t recommend immediately throwing them back to “To do”, or worse still, a dedicated “Blocked” column. It makes it too easy for them to be forgotten about. Instead, you could use a custom field, you could prefix the title with “BLOCKED”, or you could add a flag to the task (Jira does this nicely).
While it’s not good to hang around waiting for answers when you could be working on something else, switching to another task too quickly could mean you end up having 2 things in progress. When the blocked task becomes unblocked, you’ll need to context-switch and go back to it. So, make sure you mark the task as blocked, and try to unblock it before jumping to another task.
3. Prioritise the things that are closest to being done
Once code has been written and is awaiting review, it’s closer to being done than a brand new task of the same size and complexity.
It might be tempting to get going on the next task, but leaving a lot of things awaiting code review means you’re not seeing the value from the code that’s already been written.
If you keep seeing tasks awaiting code review, or there’s another reason why things are consistently getting “stuck” in the in progress column, there’s another thing you can do.
4. Splitting up the in progress column
Purists will argue that you shouldn’t split up the in progress column. But when it’s getting full and some tasks are sitting there for ages with no movement, it can be helpful to isolate some of the most common sticking points into the own columns.
One way could be to split the column as follows – the four columns in the middle are all a stage within “in progress”:
- (To do)
- Development
- Code review
- Test
- Ready to deploy
- (Done)
The main benefit is you can see much more clearly if a lot of tasks are stacking up in one of these sub-statuses. And if you combine this with a WIP limit, you can steer a team away from picking up a new task as soon as they submit one for code review. The focus becomes more about getting a task fully done and to the end of the process – instead of focusing purely on writing code.
Perhaps you don’t need that level of granularity. However, I’ve seen some teams benefit greatly from this structure – or something similar. You can always adjust it – maybe try adding one more column and see how it goes.
In 2021, Iβm trying to write more regularly on my blog β hopefully one post per week. See my progress so far here: Weekly blogging in 2021
