I’ve been doing Kanban for a while now, and I get the following question almost on a daily basis: Zsolt, can I move this item back on the board? My answer always starts with “No”, and continues with “why would you like to do that?” In this post, I’m going to describe a couple of cases you may find familiar. A common rule applies in every case: never move an item back, but examine why a particular item is selected, and how to avoid such situations in the future.
In most common cases, the question is asked when a column on the Kanban board is full, and a colleague intends to put a new item in the column, but due to the WIP limit, he can not. After realizing that the column is full, he looks through the current content and finds some items he would like to move back. He finds abandoned items in which the team invested only a small amount of work, and are now just there and taking up valuable space from other items. In the ageing items post, I talked about items which were left on the whiteboard for similar reasons.
Let’s have two different teams. The first team has a 8-10 days long lead time, but their priorities are changing almost on a daily basis, and the second team has a 2-3 days long lead time, and a quite stable priority list. In the case of the first team, the appearance of the abandoned items will be more frequent due to priority changes and resource reallocation. I would recommend them to find a way to shorten the lead time. If an item can leave the system before the priority changes again, it won’t be left on the board. In comparison, this team needs to solve the situation faster than the second team, because the abandoned item was once important for someone, who won’t be happy to get his item quite late or in the worst case, never. However, when it turns out that the item has become obsolete, just throw it away, do not waste effort on finishing it.
The situation of the second team is a bit more interesting for me. How can it happen that with such a short lead time and in such a stable situation, an item is left on the board? It is quite certain that the team uses some parts of the column as a parking lot, where they can store items which nobody intends to work on. In this case, I would recommend the second team to make the WIP limit smaller for the column, where the items usually remain for a longer time. Usually documentation or long, no-brainer tasks end up here.
In both cases, the team shall find these items and solve them - except if an item is found to be obsolete. Handle them as technical debt, which needs to be handled as fast as possible. Also, check the way the team does the prioritization: something can be wrong.
My favourite case is when colleagues act like hamsters. I call it the hamster effect (there is no connection to Terry Gilliam’s directorial style). It happens usually during the daily gathering (daily scrum or stand-up meeting), when they take an item (or a task in scrum) and put it in the next phase, saying: “after I’m finished with my current task, I’m going to continue with this one”. Like a hamster which hoards food in its cheek pouches. Of course, they’ll realize that they won’t be finished as fast as they expected, and they’ll want to put the item back. It is much easier to anticipate this scenario than to handle it afterwards. Since this act happens almost always during the meeting, ask the hamster when he can start working on the item. If the answer contains the word “after”, do not let him take the item. This may result in a conflict, but it will pay off in the future. If the item remains where it is, anybody can start working it, can’t they?
If the hoarding has already happened, it is still possible to save the situation without moving the item back. For example, someone else can start working on the item after having a small discussion with the hamster. With this approach, the hamster won’t feel that his precious item is taken away, because he can join later. Asking the hamster to interrupt his current work and start working on this item may sound like a possibility as well, but I don’t recommend it. It is an unnecessary punishment for him and for the team, because due to the context switch, nothing will be finished.
(I still find it fascinating why this happens only during the daily gatherings :-))
The next case is when an item is blocked by an external impediment. It is tempting to move back the item in this case, but instead, have a parking lot below the column for these items. With this approach, the team will have a clear overview of the impediments and will know where they were stopped. When the impediments are resolved, the items can be put back to their proper column.
The board above has two items blocked by external impediments: items ‘C’ and ‘D’. After the impediments are resolved, they can go back to their columns even if their WIP limit hurts.
Last but not least, sometimes it turns out that there are problems with the item, like bugs, missing feature implementation, architectural issues. This usually happens with items staying in columns Test or Check. The first response is to move the item back to Implementation, fix the problem and do the testing again. This is not a flow, this is a loop. By definition, an item describes a single purpose. If the item were moved back in this case, it would be the enlargement of the item with the fixing. Keep these items separate.
I usually recommend to mark the item as stopped where it is at the moment, leave it there, and start a new highly prioritized item with the single purpose of fixing the problem - somehow it is a guarantee issue for me. The stopped item will block the flow, which will force the team to take the problem seriously. In the worst case, nothing can leave until this issue is fixed. This makes the team very focused. When the fix item leaves the board - it will outrun the problematic item -, the team can go back to the problematic item and continue to work on it. For example, continue the test. It is better to do it like this instead of moving the item back, because nothing guarantees that there won’t be even more problems with it.
Additionally, “fix problem items” can provide nice statistics on how many problems the team has and how much time (lead time) they need to fix these problems. If these numbers reach the threshold of the team, it is worth to have a Fix column after Test. Do not forget to have another Test after the Fix, just to be sure that the problem is solved. If there are several problems with implemented items, the team definitely has quality issues, which need to be solved immediately. Based on my experience this is the most common case.
These are the cases I met so far. If you’ve seen one which is not listed here, do not hesitate to share.
comments powered by Disqus