Ageing Items on the Board

I spotted an interesting phenomenon on our Kanban board recently. There where items on the board which have been there for a long time. These items weren’t stopped or blocked, every information was available in order for someone to be able to continue working on them, but no progress, though.

Usually, it is enough just to mention the problem, and the team will start working on it: working on the items and moving them from left to right on the board. This works fine with an advanced team, but if your team is just learning Kanban and agile, you need a bit more controlled solution. The following post may help you if just mentioning the problem does not work.

Let’s have a team, which consists of 3 people (two avatars each). They have the following Kanban board:

At this state, every simple item is handled, nothing to worry about. After a while, the board looks like this:

The team does well: two finished items, two almost finished, and the Queue is quite reduced. Everything seems fine, except that items ‘B’ and ‘C’ are still in Phase 2, although items ‘E’ and ‘G’ are in Done. This is not a major issue at the moment, but it’s worth a closer look. The following scenario may have happened:

Items ‘E’ and ‘G’ bypassed items ‘B’ and ‘C’ in Phase 2. There can be several reasons why items ‘B’ and ‘C’ remained in Phase 2 while everything else was continued:

  • Another item had become more important

  • The previous owner had got sick

  • Someone had just put them there in order to reserve it for themselves

  • The item had been blocked, but the blocking issue had been resolved

All of these reasons are understandable, but items ‘B’ and ‘C’ were important once, and now they are just taking up valuable space from other items. Theoretically, the WIP limit is 5, but in this case it is decreased to 3. If this problem annoys the team, if they think that the problem needs to be solved, or they believe in Kaizen, then something has to be done.

In order to prevent a similar situation from happening again, the team has to be able to identify such items. One good way of doing it is to** indicate how long a particular item has been in a certain column**. You can either make strikes or concentric circles in the corner:

If the team does this properly, it will be visible how long an item has been in a column (for example in days). One can compare these values to other values or can calculate a mean value. This mean value is a good basis for comparison, statistics generation and discussion.

Now the team is aware of the situation and they want to solve it. After a while it is very likely that other items become more important than items ‘B’ and ‘C’, or the team forgets the necessary details in order to close them quickly. One solution is to get rid of items ‘B’ and ‘C’ by putting them back into the Queue. I don’t recommend doing that, though.

  • There can be dependencies. For example, item ‘K’ depends on the completion of ‘B’ and ‘C’, but this dependency is not visible at the moment, because nobody started to work on item ‘K’ yet

  • The team has already put some effort into these items, for example moving from Phase 1 to Phase 2

  • As it was mentioned before, they were important items once

In this situation my proposal to the team would be to change temporarily the WIP limit on Phase 2 column from 5 to 2. With this approach, nothing can be moved from left to right until items ‘B’ and ‘C’ are solved. If you don’t want to change the limit, you can use blocking items to make it impossible to place new items in Phase 2 until ‘B’ and ‘C’ are solved.

Note that in both cases the number of items in Phase 2 will be WIP limit + 1. It looks like one basic principle of Kanban is not applied: there are more items in a column than allowed. The team could go first for the WIP limit 3, *or use only *2 blocks and focus on items ‘C’, ‘B’ and ‘F’, and apply the next change above (WIP limit 2 or an additional block) after one of them is finished. For me, it is too much change. With the approaches above, there is no way to add a new item to Phase 2 and only one change is necessary until the situation is solved.

The WIP limit change on Phase 2 will slow down the flow of items, because the WIP limit on Phase 3 is 2, hence the team should focus on finishing something in Phase 3 to be able to move items from Phase 2 to Phase 3. One can see that one small change on the board has a huge effect on the team’s work. Maybe these ageing items aren’t as minor problems as they seem to be.

After the problem is solved, discuss the situation. Have a retrospective on the spot, or talk about the case during a regular retrospective. The place is less important, the most important is to talk about it, because something isn’t working as well as it could be. This is how the team will implement the Kaizen and be better at what they are doing. Do not forget to change the WIP limit back afterwards.

I have to admit, it could happen that cancelling items ‘B’ and ‘C’ is the right solution. For example, both of them are parts of a feature that has no value to the customer anymore. In this case, finishing them would be a waste, so cancelling them is completely acceptable. If this happens, I also recommend a retrospective where the team can discuss why they started to work on something which became eligible for cancellation this quickly.


comments powered by Disqus